This may be due to the fact that the script uses the Collision function from stdfunctions, which has been known to be less than 100 percent accurate.
Yeah, I didn't suspect that it was your script causing the difference, in case you thought that's what I was implying. It was simply the only script I knew of that called that function.
On the difference on fade-in, did you have the flag "Run Script at Screen Init" checked? That should make it where that everything is changed the instant you enter the room no matter the method.
The flag was checked, yes. Before I duplicated the room into two separate examples for the demo quest, I only had a single room in which I was trying the tile warp variations. I went through each one without ever changing the FFC, so the difference is definitely inherent to the fade-in code.
That being said, do these behaviors occur both in the original script as compiled in 2.50.2 and the newer version of ZC or only one of them?
The thing's outright nonfunctional when compiled in 2.53.0 B2, which was the secondary purpose of my report beyond the compile corruptions and crashes, so 2.50.2 is my only reference.
But I doubt it's your script, since others have gone nonfunctional, but more on that later since I'm only beginning to explore those for real. I wanted to wrap up this one before moving on.
Also, glad to see that you're still getting so much mileage out of that script !
Yeah, you know, it's a significantly different way of going about screen design. It's not so much a thing I use to redesign previous screens from earlier quests, but rather, heading toward new designs with the possibilities in mind sometimes shapes those designs considerably, as well as the areas that might lead up to them.
The only more significant change that totally changed the way I design maps was when linked portals were added to the Doom/Heretic/Hexen engine (the Eternity port anyway), and suddenly my favorite single-floored game could now have multiple floors and other non-euclidean designs. That was a total overhaul in thought process.
There is clearly something wrong with that test file. I cannot find a problem created by that script, though, in my tests. I created a blank quest in 2.53.0, and compiled that script, using both the old and new versions of ZQuest (2.50.2, and 2.53.0) and both appropriate versions of std.zh.
Saving and opening in crossed versions, and recompiling, using that script, did not cause any corruption. Is it possible that your test quest file itself was corrupted at some point, and you simply suspected this script to be the culprit?
I don't believe that to be the case.
For what it's worth, I took this opportunity to do a lot of system maintenance - malware scan, rootkit scan, temp removal, chkdsk /r, defrag & optimize, etc. - everything's working fine.
What you say about crossed versions led me to try different quests with different scripts. I already corrupted my first quest a few times, but I wanted to try another. Unfortunately, people are always passwording their stuff, but I remembered one quest that didn't have a password:
FleckQuest - download this.
Moosh Pits - paste this.
Open fleckquest.qst in ZQ 2.53 B2, import mooshpits.z, compile, add global, save. 3 tries, 3 identical corruptions. Worked perfectly fine in 2.50.2.
At this point, I'm fairly certain it has to do with loading quest files made in 2.50.x versions of ZQ into 2.53 versions of ZQ. Either I can't have so many corrupt quests from so many different sources, or 2.50.x consistently wrote corruptions that only 2.53 is finally reacting to. So I'm leaning toward a 2.53 issue, but of course it's only a quasi-educated guess.
I wish there were more quests that weren't of my own making to test with, but... password password password!
Regardless, I think this is the path worth exploring for now.
I would like to see all of the scripts that you were compiling with this, at one time, to see if any of them are doing things that are simply wrong, bad, and could have memory leaks.
Those were for something totally different. The example I gave in the previous post is an isolated incident - nothing other than what I posted was involved, so that other pack is irrelevant to that example.
That said, yes I have that separate file for the other quest, which I am still testing, and will probably post findings and an example of in a day or three. I want to try constructing the same example from scratch in 2.50.2 and 2.53.0 B2, then cross-checking them. I already determined that the scripts compiled in 2.50.2 worked fine in that version and in 2.53, and that there were some malfunctions/nonfunctions when compiled in 2.53, but it was only a cursory glance that I will have to look at for real in the coming days.
This script in fact, does something rather terrible, by declaring a user array of ComboD[176]-- never make a user declaration using an identifier that is already reserved by ZScript internally, it is just a bad idea-- but that s not the cause of any of these issues.
...well... OK, but... Works For Me™.
I don't suppose you have a recommended alternative?
Perhaps these differences are required for NES compatibility (with lake secrets, etc?)
In any case this probably needs a quest rule if changed.
I'm afraid I can only guess in regards to NES compatibility, but I don't believe lake secrets would require a difference like that since all whistle secrets reset by default during/after exiting the screen and you need a script to keep any of them permanent, so re-entering the screen would always use the reset (original) version anyway, which should make it irrelevant to those. And even if not, it would still mean certain screens may have potentially different renderings based on how they're approached.
To be clear, the example quest I made doesn't actually use the Whistle -> Dry Lake screen data option, or any screen data options for Whistle at all. It's strictly a combo cycling/animation trick. I added my (sloppy test) gradient shades to CSet 2, and made a 10-frame animation using mass tile recolor to cycle the lake from filled to empty. I noted the animation speed from the original effect to mimic it seamlessly, but it's not the original effect.
I suppose a quest rule is as good as any - I for one would use it, and be grateful for it - but if I understand correctly, you're running quite low on those for this version, and I'm not sure how you'd clearly word a rule like that in a way that people understand what different behavior it's changing. I can't think of any screens that would be dependent on using the original Item Cellar/Passageway fade-in compared to the Scrolling Warp fade-in, and again, you'd already have a conflicting rendering method if there was something dependent on it and they were approached with a Scrolling Warp instead.
Anyway, I get that it's a small issue, and sorry if I'm sounding pushy. It just ended up being personally relevant to me, and I was hoping it could simply be quick tweak, that's all.