Talk:Plan for merging DT6 and ATTACK.BIN

The Mad Cacti: Not saying this is a bad idea, but I'm not totally happy with the implications of the proposed implementation plan, so immediately ran out and wrote Plan for faster game loading and upgrading (finally posted weeks later).

TMC (talk) 05:59, 3 June 2019 (PDT)

I might have preferred the QuarkRPG plan: Each .TBL lump starts with the record length, and is followed by a fixed number of records of that length (the number of records is not stored). If the record length is zero for some reason, then the the number of records is stored after the record length (since otherwise you would have to divide zero by zero to determine the number of records). The .NAM lump stores names and reference counts, as well as whether or not the record is deleted; this information is used in the editor only. --24.207.15.213 10:38, 19 May 2019 (PDT)

Hi! What's QuarkRPG?

I agree that it would have been better to store the record length in a header instead of in binsize.bin. However we're not going to start doing it now, since we already have code to deal with our current style of fixed-length records. Better to be consistent.

Anyway, this plan is DEAD. We will never merge DT6 and attack.bin, there's no reason to do so. We'll move straight to a RELOAD-based attack data lump. --TMC (talk) 04:22, 22 May 2019 (PDT)TMC (talk) 04:22, 22 May 2019 (PDT)

I agree, it won't work to start doing it now, since that will cause problems. (And it is fine if this plan is now dead.) However, I will mention what QuarkRPG is, since you may be wondering: It is a set of plans of ideas how to make a better system (not compatible with OHRRPGCE), which is not currently implemented (or even completely designed), and even so the plans may change before it is implemented (if it ever is). In addition to the .TBL and .NAM lumps I mentioned above, there is also the ENGINE.VER and USER.VER lumps, which is used for checking for compatible versions (both of them must match in a save game file to be valid; this results in the restrictions on save games that MegaZeux has, but I consider the alternative to be worse), and the program includes a table mapping the identifiers that can be listed in ENGINE.VER to internal version numbers; the version numbers can be the same if the file format is backward compatible, and this also allows forked versions without much problem (since it stores names rather than numbers; the numbers are only internal). There are also some lump names that are reserved for use by the user and will never be used by the game engine (such as READ.ME and HINT.UHS; alternatively, the runtime could include the ability to display these files too), and battles can include "background programs" and "defense programs", as well as otherwise more versatile battle system (some of the plans for OHRRPGCE will implement some of these features, but not all of them). In addition, other programs (used only when compiling the program; they aren't needed to run the QuarkRPG editor or runtime engine) would be used to automatically generate the code to load/save the contents of .TBL lumps into structs, and keep track of where everything should be in the file even if the internal representations are changed, and so on. However, it is unknown if QuarkRPG will ever actually be implemented, since it is just some ideas for now. --24.207.15.213 22:28, 31 May 2019 (PDT)

Oh, interesting. And this is starting to sound familiar. zzo38, is that you? A change in topic (though still on-topic): we did finally add many of your additions to attack data to the attack editor, but the new aim math settings are still missing. I'm wondering whether you ever used those settings (e.g. "Custom: Extra + AccMult * AccStat vs DogMult * DogStat" and everything after it). Well, I don't remember whether I wanted to make any changes to any them anymore. --TMC (talk) 05:59, 3 June 2019 (PDT)