We are considering killing 2.50.3 in entirety, and we need to know if anyone is actually using 2.50.3RC1 to develop a quest.
Our present plan is to pull it, and put up a final update to the 2.50 line, based on 2.50.2 with a number of bugfixes and improvements, minus some changes that were introduced in 2.50.3RC1 that did not work as intended, and introduced more bugs; tentatively 2.50.2.1. No, this is not a joke.
This would be the final update to 2.50.x, not to ZC: We are still working every day on the next major release, but it is taking longer than anticipated to form a stable build for all of you, and we need to know if cutting support for the 2.50.3 gamma is going to cause havoc for any of you.
2.50.3 RC1 fixed several bugs in 2.50.2, but also introduced a new bug that causes scripts written in old quests to malfunction. 2.50.2.1 will roll back that change while keeping the other bugfixes, so that 2.50.2.1 can be the "definitive" 2.50 stable build with as few compatibility problems as possible.
But we don't want to proceed without making sure that nobody is relying on 2.50.3 for a significant work-in-progress.
This would be the final update to 2.50.x, not to ZC:
*breath of relief* (and additional emphasis for anybody about to panic.)
I personally am not constructing anything dependent on the 2.50.3 RC1 build, nor am I familiar with anybody exclusively relying on it for anything more than general updates and bug fixes (for what that's worth).
However, for people who are simply using 2.50.3 RC1 for the sake of using the latest version and nothing else, what should they be aware of, in terms of 2.50.3 RC1 features that won't work if they roll their projects back to 2.50.2? Is it only the issue regarding a script's relation to solid combos?
Because, if most people are like me, they'll just grab the latest version and start using what's available without researching the program's revision history. In fact, I don't believe I've ever started any project in any program with the consideration of supporting both current and prior releases. Generally you give/get a "minimum version" number for a project and go from there.
As for me, I'll convert to whichever branch adds the most aliases
But if I may make a suggestion - consider having a number 2.50.3 final release. v.2.50.2.1 is bordering on comically long, especially given this particular program. I might expect a version number like that for a major software development kit's public beta phase or something out of an MSDN subscription, but if you follow the Major.Minor.Patch numbering system, 2.50.3 is a given. Divisions beyond that are typically indicative of unstable changes, or RCs in this case, and it's also a given that not everything from an RC will make it into a final version. So I'd like to recommend 2.50.3 for the final release, with a note of whatever feature(s) from the current RC1 will be carried to the new branch rather than completed in this one.
The problem with 2.50.3 is that there already exists a version with that name and people will become confused (and expect 2.50.3 RC1 to interoperate with the new-2.50.3). We could skip to 2.50.4 I suppose.
What exactly was the change that broke things? If I'm reading the other thread correctly, it was something to do with solid combos that was intended as a fix for SetComboSolid. You want to undo this change, but keep absolutely everything else?
Well, first of all, it would appear that nobody is using 2.50.3 in a way that necessitates this change, so I don't see the problem with your plan. If you wanted to be absolutely sure that nobody's stuff is broken in any possible way, I'd assume something along the lines of "If made in 2.50.3 -> Do THIS. Else -> Do THAT" as far as the broken feature goes would work, but I'd imagine that nobody would want to have to add such a band-aid fix into the code for simplicity's sake. Unless you can turn the broken feature into a quest rule? Something like "Use New Solid Combo System (May break existing quests using scripts!)".
I know TRIFORCE is being built on 2.50.2 thankfully, but I am unsure of HR. I'm pretty sure I was reluctant to make the jump after discovering 2.50.3 had problems and felt at the time I didn't need to update.
The only thing that we are pulling is the change to SetCoboSolid(). All the other 2.50.3 bugfixes, and improvements are retained, and additional things that we fixed, are also being included int his new build. We could call it 2.50.LAST, or 2..50.SHEEP. I don't care much at this point. No-matter what we do, some number of people will be confused by it.
Here is the change history, since 2,50.2:
ChangeLog for 2.50.2.1 Gamma-1
Fixed 3rd quest with zero deaths not going to 5th quest. ( ZoriaRPG, 20th June, 2017 )
Reverted COMBOSDM change made by Saffith, as it caused different bugs with older players.
This is properly fixed in 2.51+. ( ZoriaRPG, 20th June 2017 )
Fixed long-standing bug where setting Link->Item every frame causes lag. ( ZoriaRPG, May 2017 )
Fixed lweapon->Behind not working. ( ZoriaRPG, May 2017 )
Fixed ffc->Link being unable to be cleared, or otherwise set to 0 ( ZoriaRPG, May 2017 )
Fixed scale args for DrawChar() and DrawInteger(): Both of these now scale per zscript.txt documentation. ( ZoriaRPG, Jan 2017 )
Zelda Classic Menus: Added Etc->Show Debug Console. This opens the Allegro debug console or closes it if it is open. ( ZoriaRPG, Jan 2017 )
ZScript Variables in scope are destroyed when their scope exits. ( DarkDragon, Jan 2017 )
Added a checkbox to disable analog stick movement.
Changed joystick config dialogues to match keyboard config dialogues.
Added more joystick options to ag.cfg.
Small fixes to joystick input.
Fixed minor issues in key config dialogues. ( Saffith, 18-Dec-2016 )
Additional fixes with Link exiting water. ( Saffith, 15-Dec-2016 )
Fixed an invalid read in draw_wavy(). ( Saffith, 14-Dec-2016 )
Fixed Link's position being offset improperly on continue when quakeclk > 0.
Ensure overscane rectangle is black while the screen is shaking.
Fixed an issue with Limk exiting water.
Fixed Stone of Agony sensitivity. ( Saffith, 11-Dec-2016 )
Fixed incorrect screen calculation and possible crash in warp with combos that carry over. ( Saffith, 6-Dec-2016 )
Global script OnExit now works. In prior versions, this script did not run.
Fixed a crash when loading a sfx file with more than 35 chars or without any extension. ( Gleeok, 2015-12-30 01:05:05 )
Fixed negative constants being read incorrectly.
Fixed incorrect screen calculation and possible crash in Game->SetComboSolid(). ( Saffith, 2015-12-19 19:41:38 )
Fixed a crash when importing combos. ( Saffith, 2015-11-27 09:30:31 )
Replaced the built-in MIDIs with versions edited by zaphod77 to sound more like the NES game. ( Saffith, 2015-10-14 10:41:20 )
As you can see, the number of improvements, and bugfixes far outweighs one inconvenience. Quests made in 2.50.3 that do not use Game->SetComboSolid() are completely unaffected by this, as the base is identical to 2.50.3, less that one ZScript change, plus some other fixes. I could add a quest rule for it, if that is ultimately what everyone wants.
The real issue is that the version in which scripts are compiled, and the version in which a quest was last saved, can report different and conflicting results without a more sophisticated system to determine ZScript version. Wedo have that in 2.54/2.55.
My original proposal was to just revert the rule change and use 3.50.3RC2, moving to 2.50.3 final, because the only release was a gamma, and subject to change. I don't know how many of you are using 2.50.3, and how many of those on 2.50.3 are also using Game->SetComboSolid() in their scripts.
This latter concern is of equal, if not greater consequence. If Evan is using 2.50.3, but he is not using SetComboSolid(), then he can move onto 2.50.2.1.SHEEP and not fret. If he is using SetComboSolid(), then that poses a different problem. Adding a QR is a potential fix, but not an absolute fix.
If any of you have developed scripted quests using 2.50.3, and are unsure if any of your scripts use this (e.g., perhaps a header did, and you were not aware; or perhaps you did not write the scripts), I am willing to perform a check on them.It is a painstaking process that requires me to examine the ZASM for COMBOSDM instructions, but if it comes down to it, I'll check them for you, or show some of you how to do this using 2.54/5 main.
So I updated my quest to 2.50.3 RC1, and worked on it a bit (just editing items and strings). Can I just open it up in the previous version (2.50.2) or whatever you replace 2.50.3 with, save it and be good to go?
I mean, if I still have the last save I made in 2.50.2 then I won't lose much work. Just wondering if I can bring it back to the previous version and save without creating problems.
The only thing that we are pulling is the change to SetCoboSolid(). All the other 2.50.3 bugfixes, and improvements are retained, and additional things that we fixed, are also being included int his new build. We could call it 2.50.LAST, or 2..50.SHEEP. I don't care much at this point. No-matter what we do, some number of people will be confused by it.
That's the only change? What necessitates going back to 2.50.2 then? If you ask me, this is way more confusing than continuing to go forward with the current numbering and call it 2.50.3.1 or even 2.50.4. As long as there's a 2.50.3 out there, someone's going to use it over 2.50.2.1 even if it's unsupported. People just aren't good at keeping up with the latest versions. Half the people I troubleshoot for seem to think they're using ZC 2.5.6 because of the launcher version.
But none of that's super important. As long as it's something as minor as a change to a rarely used function like SetComboSolid() the change should be fine. You made it sound like it was something much worse.
Edit: For the record, I'm certain Evan's quest was not using SetComboSolid(). So no worries there.
I've screwed around with, and contemplated using the 2.50.3 betas, but haven't saved any files in it yet, so I could just as easily not ever use it. :tard:
What is Evan's username? Can we check and make sure he will not be affected?
Hi.
I didn't use SetSolidCombo. The biggest selling point in 2.53 for me was the ability to detect what version the player was playing the quest on and adjust the layered bitmap "bug" offsets appropriately. The other bugfixes were also nice, but as long as nothing is catastrophically broken, I can live. Past that, it should just be as simple as recompiling in 2.521 (That's a mouthful), right?
Mod Note: I'll pin this for a few days so it doesn't get buried.