Backwards Compatibility Issues

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.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Backwards Compatibility Issues

Re: Backwards Compatibility Issues

by Matt » Fri Jan 18, 2019 2:05 pm

Kinsie wrote: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.
This.

That's why I'd posted that thing about globalfreeze as a feature suggestion for more graceful deprecation rather than a bug report.

Graf Zahl wrote:It's again that old fallacy of overestimating the number of users of such systems, and then investing countless hours of work (or money) in supporting this stuff.
It's not even something that is limited to hobbyists, I already mentioned one story of a former job of mine here where a certain product had to be maintained for approx. 200 incompatible mobile handsets. The amount of work invested here was utterly insane and burned a significant portion of the budget. Worse, because these were "important" all assets were stripped down to work on that old hardware. The one thing nobody did until I really put pressure on them was to run an analysis tool on which SKUs really were important. What surprised everybody (except me) was that of the 200 SKUs we supported, maybe 20 were important and made up roughly 95% of all traffic.

And now take one guess which ones were on that list. I don't think anyone should be surprised that it was the high end stuff. All that "important" low end, for which the software got stripped down to a point where it remained a shell of its former self were utterly irrelevant!

And very much the same applies here.
I feel like this should be reposted as a sticky so people have a better understanding of where Graf (and presumably the rest of the GZD dev team) is coming from when it comes to this issue.

Re: Backwards Compatibility Issues

by Graf Zahl » Fri Jan 18, 2019 1:38 pm

To be more precise, ACS uses a weird scale where 1.0 is 360° (and by extrapolation and factoring in wraparound, 350.0 is also 360° (or what it really comes down to, 0°, i.e. perfectly horizontal pitch.) Please do not ask me why Randi chose such a value range, except for easy conversion to the old internal angle format.

Re: Backwards Compatibility Issues

by Zhs2 » Fri Jan 18, 2019 1:14 pm

ACS uses those values. [wiki=A_SetPitch]DECORATE/ZScript's range is from [-90.0, 90.0][/wiki] - negative up, positive down, at least in recent versions. A_LogInt wouldn't have returned a usable value because pitch is double precision in DECORATE/ZScript, not an int.

Re: Backwards Compatibility Issues

by Yholl » Fri Jan 18, 2019 1:02 pm

Graf Zahl wrote: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?
I used A_LogInt(pitch) to find out the values I needed for things by looking around. The number it gave me was 350 for what I wanted.
Zhs2 wrote:From the history of the [wiki]GetActorPitch[/wiki] page, I'm surprised this value actually worked. 0 seems to be the proper value for looking straight ahead in all cases, and the fixed point value range for pitch seems to be very, very small otherwise - from [-0.25, 0.25] in GL, less for software!
I recall ACS and Decorate are also different values at least in 2.1.1, with ACS using those ones and Decorate using 0-360 for some reason. I'm actually not sure why that one works at this point either.

Re: Backwards Compatibility Issues

by Graf Zahl » Fri Jan 18, 2019 12:58 pm

Rachael wrote:
Yholl wrote:Targeting a fast-running, stable, guaranteed multiplayer working, able to run on a large amount of computers version is the problem?
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.

It's again that old fallacy of overestimating the number of users of such systems, and then investing countless hours of work (or money) in supporting this stuff.
It's not even something that is limited to hobbyists, I already mentioned one story of a former job of mine here where a certain product had to be maintained for approx. 200 incompatible mobile handsets. The amount of work invested here was utterly insane and burned a significant portion of the budget. Worse, because these were "important" all assets were stripped down to work on that old hardware. The one thing nobody did until I really put pressure on them was to run an analysis tool on which SKUs really were important. What surprised everybody (except me) was that of the 200 SKUs we supported, maybe 20 were important and made up roughly 95% of all traffic.

And now take one guess which ones were on that list. I don't think anyone should be surprised that it was the high end stuff. All that "important" low end, for which the software got stripped down to a point where it remained a shell of its former self were utterly irrelevant!

And very much the same applies here.

Re: Backwards Compatibility Issues

by Zhs2 » Fri Jan 18, 2019 12:49 pm

Yholl wrote:
ChangeActorPitch (0, 350.0, 1);
This line in Laundry 3 makes you face forwards in a cutscene in 2.1.1, as intended.
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.
From the history of the [wiki]GetActorPitch[/wiki] page, I'm surprised this value actually worked. 0 seems to be the proper value for looking straight ahead in all cases, and the fixed point value range for pitch seems to be very, very small otherwise - from [-0.25, 0.25] in GL, less for software!

Edit: oops, page 2 sniped Graf

Re: Backwards Compatibility Issues

by Graf Zahl » Fri Jan 18, 2019 12:46 pm

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.
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.

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.
Yholl wrote:
ChangeActorPitch (0, 350.0, 1);
This line in Laundry 3 makes you face forwards in a cutscene in 2.1.1, as intended.
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?

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.

Re: Backwards Compatibility Issues

by Rachael » Fri Jan 18, 2019 12:43 pm

Yholl wrote:Targeting a fast-running, stable, guaranteed multiplayer working, able to run on a large amount of computers version is the problem?
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.

Re: Backwards Compatibility Issues

by drfrag » Fri Jan 18, 2019 12:40 pm

I've just checked and at least it works properly with ZDoom LE.

Re: Backwards Compatibility Issues

by Yholl » Fri Jan 18, 2019 12:38 pm

ChangeActorPitch (0, 350.0, 1);
This line in Laundry 3 makes you face forwards in a cutscene in 2.1.1, as intended.
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.

Re: Backwards Compatibility Issues

by Kinsie » Fri Jan 18, 2019 12:27 pm

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.
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.

Re: Backwards Compatibility Issues

by Yholl » Fri Jan 18, 2019 12:18 pm

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.
As I just said, I mod for GZDoom 2.1.1, as it is the last stable version before ZScript.
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.
Zhs2 wrote: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)
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.
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.

Re: Backwards Compatibility Issues

by Kinsie » Fri Jan 18, 2019 12:16 pm

Zhs2 wrote: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)
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.
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

by Zhs2 » Fri Jan 18, 2019 12:06 pm

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:

Code: Select all

TNT1 A 0 A_ChangeVelocity (Cos(Pitch) * 15, 0, Sin(Pitch) * 15, CVF_RELATIVE | CVF_REPLACE)
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.

Re: Backwards Compatibility Issues

by Graf Zahl » Fri Jan 18, 2019 11:58 am

Yholl wrote: However, pitch has been very much destructively altered since the versions I aim for, with no regard for backwards compatibility.
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.
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:
Yholl wrote:stable, guaranteed multiplayer working
Can Zandro's horrifying bounty of Carncode really be called either of these?

In fact, that "horrifying bounty of Carncode" (I have to remember that... :mrgreen:) is pretty much what prevents Zandronum from moving forward with scripting features.

Top