Quote Originally Posted by ZoriaRPG View Post
Of course I did not add it to master. You explicitly told me not to make any internal changes for master until you were done with your own. I can't set up rules changes in ZDefs.h or in FFRules until you finish what you are doing, but I was planning to forward this to master, and to 2.54, later, as that is still an interim goal.
You are right, however this kind of change is not a major change to internal quest data structures and the branches cannot be allowed to lose backward-compatibility with respect to each other ("we'll remember to fix it some time in the future" is a dangerous game). If you ask for help I can make sure that changes are properly synched in both branches.

The change to COMBOSDM is critical, as the old code causes ZC to crash if it is used on layers higher than 1. It is not merely there to support 2.50.3RC1 quests, but to address a critical bug.
As I see it there are two separate issues: (i) ZC crashes when passed an invalid layer; (ii) the indexing is off-by-one from the ideal numbering system.

Fixing (i) poses no compatibility issues and requires no quest rule, and can be safely applied to 2.50.x (and master, why not?) Fixing (ii) is the more tricky issue but, as far as I can tell, far from urgent. If you think there really must be a renumbering in 2.50.x, the options are (a) apply the fix in master (based on ZASM versioning) to 2.50.x; (b) remove the fix in master based on ZASM versioning, and add a quest rule (with consistently-placed bits in both branches!!) to both branches. Changing 2.05.x (only) to do its own thing is not a possibility as it breaks quest compatibility.

We also need a bit for bitmap positioning. That was another debacle intended as a silent 'fix' for an old 'bug', that instead became its own huge bug/mistake, introduced in 2.50.2 that fragmented the community by making some very popular quests [U]unplayable[U] in 2.50.2.
I do not know the details about this issue. My preferences, in descending order, are (i) restore 2.50.2 behavior and drop whatever was incorrectly changed in 2.50.3 completely. If this breaks 2.50.3 quests in a non-moot way (somebody's work will actually be affected by the rollback), add compatibility logic to master so that 2.50.3 quests will play correctly on master. (ii) carefully add logic to both 2.50.x and master that preserves behavior of 2.50.3 quests while fixing the 2.50.2 compatibility bug.

I did not handle the change in this manner, on a whim.
I understand, yet regardless of the intent with which it was made, the status quo is unacceptably broken code, for the reasons I explained above and in my original post. The current state of the repository (quest rule completely rolled back) is acceptable in my mind provided that nobody steps forward with concrete evidence that a real-world quest will be affected. If you are worried, you may send a new patch request that fixes the 2.50.3 solidity command and addresses the three concerns in my original post.