Backwards Compatibility Issues
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Backwards Compatibility Issues
Apologies for how vague this is, but it needed to be posted.
Back when zscript was being developed, backwards compatibility was promised with old mods. Right now this is under threat and changes need to happen to resolve it.
At some point during zscripts development, because the pitch was originally inverted or something, A_FaceTarget's pitch parameter was completely reversed, no flag, no nothing. Any pre-zscript mod that uses it will be completely reversed in modern versions of the engine. ZDoom 2.8.1/GZDoom 2.1.1 has the pre-alteration version of A_FaceTarget, I don't know when it changed after that.
Another issue is the current VM execution aborts when actors that don't exist anymore have stuff attempted to give or take from them. This turns a completely harmless nothing into a minefield of potential crashes.
While active modders can go and fix such "issues" themselves, any mods that do not have authors working on them will not be able to fix this. If you're playing something with this, there's no telling whether or not your fun game will suddenly just decide to stop. That's immensely inconvenient when it happens, and paranoia inducing when it isn't.
As I don't work with newer versions, I usually encounter issues second hand through other people playing stuff.
Back when zscript was being developed, backwards compatibility was promised with old mods. Right now this is under threat and changes need to happen to resolve it.
At some point during zscripts development, because the pitch was originally inverted or something, A_FaceTarget's pitch parameter was completely reversed, no flag, no nothing. Any pre-zscript mod that uses it will be completely reversed in modern versions of the engine. ZDoom 2.8.1/GZDoom 2.1.1 has the pre-alteration version of A_FaceTarget, I don't know when it changed after that.
Another issue is the current VM execution aborts when actors that don't exist anymore have stuff attempted to give or take from them. This turns a completely harmless nothing into a minefield of potential crashes.
While active modders can go and fix such "issues" themselves, any mods that do not have authors working on them will not be able to fix this. If you're playing something with this, there's no telling whether or not your fun game will suddenly just decide to stop. That's immensely inconvenient when it happens, and paranoia inducing when it isn't.
As I don't work with newer versions, I usually encounter issues second hand through other people playing stuff.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Backwards Compatibility Issues
Just because some bugs slipped through in older versions cannot mean that said bugs may not be fixed or at least guarded against, especially if they may result in crashes.
If we go for backwards compatibility at all costs the engine will become unmaintainable in a very short time because nothing may be changed. It'd be like demo compatibility, only ten times worse.
See it that way: I had absolutely zero chance to get ZScript to a stable version 1.0 before people started using it left and right - and now expect that their code continues to work. The result: The engine is in a really shitty state, there's countless design problems in the scripting layer that cannot be fixed anymore because people have been using this stuff extensively, Still I draw the line when I see mods just working by pure happenstance, the abort you mention is such a case. It is compietely unpredictable what will happen internally, it can be everything from writing data to invalid memory to trashing important data that then leads to crashes in completely unrelated code.
With a scripting interface it is an inevitable truth that badly written code can break more easily. Sadly, a lot of ZScript and even more DECORATE is VERY badly written. Fix one bug and ten mods pop up that fall victim to the fix.
If we go for backwards compatibility at all costs the engine will become unmaintainable in a very short time because nothing may be changed. It'd be like demo compatibility, only ten times worse.
See it that way: I had absolutely zero chance to get ZScript to a stable version 1.0 before people started using it left and right - and now expect that their code continues to work. The result: The engine is in a really shitty state, there's countless design problems in the scripting layer that cannot be fixed anymore because people have been using this stuff extensively, Still I draw the line when I see mods just working by pure happenstance, the abort you mention is such a case. It is compietely unpredictable what will happen internally, it can be everything from writing data to invalid memory to trashing important data that then leads to crashes in completely unrelated code.
With a scripting interface it is an inevitable truth that badly written code can break more easily. Sadly, a lot of ZScript and even more DECORATE is VERY badly written. Fix one bug and ten mods pop up that fall victim to the fix.
I think that's the real problem here. If you insist in targeting an older version you are very much at risk of creating something broken - because the users of the stuff you create will not be that conservative.Yholl wrote: As I don't work with newer versions, I usually encounter issues second hand through other people playing stuff.
- Kinsie
- Posts: 7399
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
- Contact:
Re: Backwards Compatibility Issues
Actual repro steps:Yholl wrote:At some point during zscripts development, because the pitch was originally inverted or something, A_FaceTarget's pitch parameter was completely reversed, no flag, no nothing. Any pre-zscript mod that uses it will be completely reversed in modern versions of the engine. ZDoom 2.8.1/GZDoom 2.1.1 has the pre-alteration version of A_FaceTarget, I don't know when it changed after that.
1.) Start the current public version of DoomRL Arsenal in the latest stable GZDoom.
2.) Find a decent outdoor area - the courtyards in E1M1 or MAP01 works fine.
3.) Go to one end of the courtyard.
4.) Jump in the air, and at the peak of your jump, open the console.
5.) Type "freeze" and "summon RLCyberneticLostSoul".
6.) Go to the other end of the courtyard, and turn off freeze mode.
The skull actor will appear, and with a little coaxing will start blasting towards you, but for some reason its pitch correction will be off and it'll end up hovering threateningly in the ceiling above your head.
You can view a video of this happening here.
- Kinsie
- Posts: 7399
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
- Contact:
Re: Backwards Compatibility Issues
I feel like ZScript is still young enough, and the issues in it apparent enough, that the majority of people using it would be, perhaps not happy, but at least reasonably receptive to script-breaking design fixes if they improved the overall state of the engine's health, and that enough of the people dabbling in it are still active enough to fix their mods to taste.Graf Zahl wrote:See it that way: I had absolutely zero chance to get ZScript to a stable version 1.0 before people started using it left and right - and now expect that their code continues to work. The result: The engine is in a really shitty state, there's countless design problems in the scripting layer that cannot be fixed anymore because people have been using this stuff extensively,
Might be something for QZDoom to dabble with at some point...
Re: Backwards Compatibility Issues
While it still disturbs me slightly, what you say about the vm thing does make sense, I'll accept that.
However, pitch has been very much destructively altered since the versions I aim for, with no regard for backwards compatibility. Multiple projects of mine have been affected by this, with things like the player staring at the floor in cutscenes, mines flying off into the sky, and who knows what else. Would likely be even more if people hadn't reported it to me.
Backwards compat with old decorate was promised when zscript started, and if stuff like this keeps happening I won't really have any choice other than to tell players to not use modern GZDoom to play my stuff.
However, pitch has been very much destructively altered since the versions I aim for, with no regard for backwards compatibility. Multiple projects of mine have been affected by this, with things like the player staring at the floor in cutscenes, mines flying off into the sky, and who knows what else. Would likely be even more if people hadn't reported it to me.
Backwards compat with old decorate was promised when zscript started, and if stuff like this keeps happening I won't really have any choice other than to tell players to not use modern GZDoom to play my stuff.
Targeting a fast-running, stable, guaranteed multiplayer working, able to run on a large amount of computers version is the problem?Graf Zahl wrote:I think that's the real problem here.
- Kinsie
- Posts: 7399
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
- Contact:
Re: Backwards Compatibility Issues
Can Zandro's horrifying bounty of Carncode really be called either of these?Yholl wrote:stable, guaranteed multiplayer working
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Backwards Compatibility Issues
Why are you aiming for old versions? This is entirely a problem of your own making if you insist that your mod works with old versions.Yholl wrote: However, pitch has been very much destructively altered since the versions I aim for, with no regard for backwards compatibility.
Let me make one thing very clear: I will entertain the idea of making some old mod work, but a modder coming in here essentially saying "Hey, I want to make a mod that's compatible with 2.4 and current versions and some bugfix prevents me from doing so." will normally fall on deaf ears. If you think this is more important to you, feel free to make a mod targeting that old versions - but let me state right away that you'll be unlikely to get any support here. The resources at our disposal are limited and cannot be spent on such endeavours.
Also, the pitch issue was a mistake, I explicitly deprecated the incorrect DECORATE version of the function, IIRC, but mistakenly did not apply a proper fix to the replacement.
Kinsie wrote:Can Zandro's horrifying bounty of Carncode really be called either of these?Yholl wrote:stable, guaranteed multiplayer working
In fact, that "horrifying bounty of Carncode" (I have to remember that... ) is pretty much what prevents Zandronum from moving forward with scripting features.
- Zhs2
- Posts: 1269
- Joined: Fri Nov 07, 2008 3:29 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Location: Maryland, USA, but probably also in someone's mod somewhere
- Contact:
Re: Backwards Compatibility Issues
I don't believe these pitch alterations started around the time of ZScript. A_SpawnProjectile and A_FireProjectile were introduced a while before ZScript (before GZDoom 2.4.0!) to clear up very nasty assumptions about how pitching worked when all along positive values of pitch were meant to aim downward, not upward. The pitch fixes snowballed from there, and now pitch values are consistent for all actors and non-deprecated functions across the board.
With some investigation, Kinsie's example looks like a mod bug. Line 89 of doomrl_monsters_beta_6.2.wad/D_CSOUL:Should be "-Sin(Pitch) * 15" for the z parameter. The TRANSFER_PITCH flag entry on the [wiki]A_SpawnItemEx[/wiki] page suggests as much for consistent pitch aiming behavior.
With some investigation, Kinsie's example looks like a mod bug. Line 89 of doomrl_monsters_beta_6.2.wad/D_CSOUL:
Code: Select all
TNT1 A 0 A_ChangeVelocity (Cos(Pitch) * 15, 0, Sin(Pitch) * 15, CVF_RELATIVE | CVF_REPLACE)
- Kinsie
- Posts: 7399
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
- Contact:
Re: Backwards Compatibility Issues
This seems to make things behave as-intended on 3.7.1. I don't have any old versions of GZDoom on-hand to check for back-compat, though.Zhs2 wrote:With some investigation, Kinsie's example looks like a mod bug. Line 89 of doomrl_monsters_beta_6.2.wad/D_CSOUL:Should be "-Sin(Pitch) * 15" for the z parameter. The TRANSFER_PITCH flag entry on the [wiki]A_SpawnItemEx[/wiki] page suggests as much for consistent pitch aiming behavior.Code: Select all
TNT1 A 0 A_ChangeVelocity (Cos(Pitch) * 15, 0, Sin(Pitch) * 15, CVF_RELATIVE | CVF_REPLACE)
Re: Backwards Compatibility Issues
As I just said, I mod for GZDoom 2.1.1, as it is the last stable version before ZScript.Graf Zahl wrote:Why are you aiming for old versions? This is entirely a problem of your own making if you insist that your mod works with old versions.
It can be run by pretty much anyone, thanks to being on par with ZDoom 2.8.1. I'm making mods for a 20+ year old game, they shouldn't need to have super hardware to play my stuff.
I don't need to worry about any new features that I don't need or want to use, and it runs faster because of it.
It is also the only version I know of that's pretty much guaranteed to run multiplayer correctly, which is the main reason I target it. All my mods are based around coop.
And while it isn't there quite yet, eventually maybe even Zandronum will be able to run them, although I'm not holding out hope at this point.
That's not a mod bug, that's literally how it used to work. Now that pitch is altered in new versions, obviously it's broken in them. That's what this is all about, the pitch changes that broke anything old that used them.Zhs2 wrote:With some investigation, Kinsie's example looks like a mod bug. Line 89 of doomrl_monsters_beta_6.2.wad/D_CSOUL:Should be "-Sin(Pitch) * 15" for the z parameter. The TRANSFER_PITCH flag entry on the [wiki]A_SpawnItemEx[/wiki] page suggests as much for consistent pitch aiming behavior.Code: Select all
TNT1 A 0 A_ChangeVelocity (Cos(Pitch) * 15, 0, Sin(Pitch) * 15, CVF_RELATIVE | CVF_REPLACE)
- Kinsie
- Posts: 7399
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
- Contact:
Re: Backwards Compatibility Issues
Grabbed an old version of GZDoom, confirming that this more or less just reverses the problem, making the pitch bug appear on old versions instead of new ones.Kinsie wrote:This seems to make things behave as-intended on 3.7.1. I don't have any old versions of GZDoom on-hand to check for back-compat, though.
Re: Backwards Compatibility Issues
This line in Laundry 3 makes you face forwards in a cutscene in 2.1.1, as intended.ChangeActorPitch (0, 350.0, 1);
In modern stuff, it makes you stare at the floor.
There's a bunch of different pitch problems like this in my mods when used in modern versions.
In any case, if modern gzdoom had something, like a new actor I could just spawn and check for, I could fix all this stuff myself and not have to bother anyone.
As it is right now, in most cases there is nothing I can do to solve this myself.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: Backwards Compatibility Issues
I've just checked and at least it works properly with ZDoom LE.
Re: Backwards Compatibility Issues
Sorry to be someone who rains on your parade, but that still remains the case, today. It seems like people running on legacy systems unable to handle it have got themselves caught in a shrinking minority. About 10 to 1, to be approximate.Yholl wrote:Targeting a fast-running, stable, guaranteed multiplayer working, able to run on a large amount of computers version is the problem?
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Backwards Compatibility Issues
It was broken in old versions because some external contributor messed up the pitch in several functions and it only got discovered extremely late in the game. This actually originated from Skulltag's model code and got made worse because people tried to make the broken model pitching work correctly. There was a horrendous amount of fudging code by other people to compensate for that bug in other code, each thing addressing one aspect of this design flaw - but since the math was not correct to begin with, the end result was that it was nearly impossible to use this stuff correctly, at some point the bug would come back biting you in the ass. The only remedy was to fix it - screw the handful of mods falling victim to it. It cannot be reverted without breaking even more stuff out there. The fact that we got near zero reports about this issue speaks a very clear language that the number of affected mods must have been small.Yholl wrote:That's not a mod bug, that's literally how it used to work. Now that pitch is altered in new versions, obviously it's broken in them. That's what this is all about, the pitch changes that broke anything old that used them.
The version you are talking about is 3 years old by now, there have been one major new release, 9 minor ones and just as many point releases for bugfixing.
So if that's what you want to target, feel free to target it, but like I said: You are on your own there. The thing is just that your USERS will ask YOU why you make stuff that doesn't work in more recent engine versions.
Behold that gem of a modding bug that just went unnoticed due to value wraparounds. You are aware that the valid range for pitches is -90 .. 90, right? 350 is outside that range and apparently at some point gets clamped to 90. Why didn't you use -10 as anybody else would have done?Yholl wrote:This line in Laundry 3 makes you face forwards in a cutscene in 2.1.1, as intended.ChangeActorPitch (0, 350.0, 1);
And this has nothing to do with the pitch change we were talking about, this was a side effect of using floats in the engine. Even better, this can be addressed without breaking anything.