Page 1 of 1

[PSA]Modders: things that worked in Zandronum 1.3 may break in 2.0, please check here

Posted: Mon Feb 23, 2015 11:25 pm
by Hypnotoad
Since Zandronum 2.0 will feature a major upgrade to its Zdoom codebase, certain things modders do that relied on undefined yet consistent behavior in 1.3 may no longer work in 2.0. Modders must check if their projects are relying on this undefined behavior, and update their projects by using the correct methods instead. I will detail what has changed below and I will update this OP if I hear about any more:

Using the == operator with strings

This should be avoided. While in 1.3, doing something like ' if ( stringvariable == "this" ) ' often worked for static strings, it is undefined and not correct to use the == operator this way with strings in Zandronum. In 2.0 as has been recently found out, you cannot rely on this to always work now, even with static strings. Authors should update their wads if they are relying on this behavior.

Authors should store important data as integers for comparison, not as strings. However, if it is absolutely necessary, it may be possible to construct a string compare function, I'll update this thread with one if I find a good one or someone submits one.

Update: these functions should work in 2.0

http://zdoom.org/wiki/StrCmp
http://zdoom.org/wiki/StrIcmp

Using or hosting wads with multiple actors that might share the same actor name, spawn id or doomed number.

Obviously, you shouldn't be doing this anyway, nonetheless you may be in charge of a project that has considerable community involvement that all submit their own addons with their own decorate actors such that you may have missed these conflicts. Before, in 1.3 and older versions, Zandronum would overwrite or load actors with conflicting spawn ids, actor names or doomed numbers in a certain consistent way and order, so you may not have experienced any problems. Now in 2.0, the way Zandronum handles this undefined behavior has changed, which means the aforementioned project authors might experience the wrong actors spawning unexpectedly. Therefore, project authors should carefully examine all actor definitions in their projects and addons to ensure there are no unintentionally conflicting spawn ids, actor names or doomed numbers. Addon authors should check the zdoom wiki to learn how to correctly replace actors if they rely on this undefined behavior.

The fog rendering has changed in Zandronum 2.0 for OpenGL

The main change is how it handles fog for high or maximum brightness sectors. Before in openGL, fog would still render in very bright sectors. Some authors utilized this in order to have fog show in OpenGL but not in software (since fog generally looks like garbage in software). Unfortunately, GL fog rendering in 2.0 has changed and is now more similar to software in terms of its intensity at certain brightness levels, and wont render at all for very bright sectors. We've found many maps have been affected, authors should check their maps in 2.0 beta if they have made extensive use of fog, and may need to lower sector brightness if fog is not being rendered when it should be in openGL.

update: a good rule of thumb according to blzut3: "If OpenGL renders a software supported feature differently from Software it's probably a bug."

A notable exception here is for 3d floor lighting, as the 3d floor implementation in software is known to be a little buggy.

(Hexen format) Using line specials (e.g. Teleport_Line) with line id 0.

This is something we've found to cause major issues in certain maps; if you use for instance Teleport_Line on a pair of lines in Hexen format, be sure to make the 'thisid' parameter greater than 0 for each line, as in 2.0 this can interfere with lines using Plane_Align which might also use line id 0, and cause serious issues with malfunctioning slopes as we have seen in various maps.

In general, for line actions that require you to set a lineid parameter, use a value greater than 0, or your map may run into serious problems in Zandronum 2.0.

Be wary of using Consolecommand()

I'm unsure if this is being removed in 2.0 (update: it hasn't). Still, this would be a good time for authors to phase out their usage of this function. Some of the same useful behavior of consolecommand can now be replicated with functions like requestScriptPuke, SetCVAR and CVARINFO.


Update: Actor Hits Floor now activates when teleporting to the sector

This has caused major problems, for instance with megaman, actor hits floor specials are now triggered simply by teleporting to that sector. This can break two way teleports that use actor hits floor triggers on both sides, by causing an infinite recursion error. You must make sure to update any maps that rely on actor hits floor specials not being triggered on teleporting to the sector.


Update 2: Using script numbers higher than 999

This was already a bad idea in 1.3 and could result in fatal errors, but if you were lucky your mod may have been using them without causing too many problems. No longer however, it appears all scripts higher than 999 will now produce an error.

RE: [PSA]Modders: things that worked in Zandronum 1.3 may break in 2.0, please check here

Posted: Mon Feb 23, 2015 11:46 pm
by ZzZombo

RE: [PSA]Modders: things that worked in Zandronum 1.3 may break in 2.0, please check here

Posted: Mon Feb 23, 2015 11:54 pm
by Cruduxy
Knowing a lot of the modders don't be surprised when they start complaining when their wads break regardless of how many PSA's are done :P.

Especially the second point. Bet it breaks a hilarious number of wads!

RE: [PSA]Modders: things that worked in Zandronum 1.3 may break in 2.0, please check here

Posted: Tue Feb 24, 2015 12:00 am
by Hypnotoad
Unfortunately those aren't in Zandronum yet (unless they were backported?).

RE: [PSA]Modders: things that worked in Zandronum 1.3 may break in 2.0, please check here

Posted: Tue Feb 24, 2015 12:22 am
by ZzZombo
The accounts branch has that.

RE: [PSA]Modders: things that worked in Zandronum 1.3 may break in 2.0, please check here

Posted: Tue Feb 24, 2015 4:06 am
by NachtIntellect
Looks like I'll have to rewrite alot of the code for NZ:DE then, thanks for the heads up.

RE: [PSA]Modders: things that worked in Zandronum 1.3 may break in 2.0, please check here

Posted: Wed Feb 25, 2015 1:21 pm
by Vincent(PDP)
Hypnotoad wrote:However, if it is absolutely necessary, it may be possible to construct a string compare function, I'll update this thread with one if I find a good one or someone submits one.

Update: these functions should work in 2.0

http://zdoom.org/wiki/StrCmp
http://zdoom.org/wiki/StrIcmp
Otherwise I have made one in my ACS.NET library: http://zandronum.com/forum/showthread.php?tid=5666

Note that it is case sensitive though...

RE: [PSA]Modders: things that worked in Zandronum 1.3 may break in 2.0, please check here

Posted: Wed Apr 01, 2015 1:33 am
by Thomas
I have another point to add. Since 2.0 ACS scripts that have numbers higher than 999 will crash the game with an error. I see in the changelog that this was changed, because it is not supported. So if people are using script numbers over 999 the map won't work and you have to change it. Can anyone maybe enlighten me why it is restricted now? Because it worked just fine in 1.3 and also in the latest release of GZDoom.

RE: [PSA]Modders: things that worked in Zandronum 1.3 may break in 2.0, please check here

Posted: Wed Apr 01, 2015 4:06 am
by TerminusEst13
Thomas wrote:Because it worked just fine in 1.3
It didn't. It caused crashes.

RE: [PSA]Modders: things that worked in Zandronum 1.3 may break in 2.0, please check here

Posted: Wed Apr 01, 2015 8:38 am
by Thomas
TerminusEst13 wrote:
Thomas wrote:Because it worked just fine in 1.3
It didn't. It caused crashes.
Weird, I have several maps with script numbers over 999, never had any problem and they executed just fine. I guess it's just undefined behaviour then and I was (un)lucky?

RE: [PSA]Modders: things that worked in Zandronum 1.3 may break in 2.0, please check here

Posted: Wed Apr 01, 2015 11:53 am
by ZZYZX
Hypnotoad wrote:Using or hosting wads with multiple actors that might share the same actor name, spawn id or doomed number.
So this is going to break?
(if anything, the point below is distinguishing things that are placed on the map statically from things that were spawned in any other way)
#zamapping wrote:<Siferah> look
<Siferah> There are two ways to replace an actor
<Siferah> One way works almost always, the other works only for things placed on the map (and the second way generates a warning, too, but nevertheless works as intended)
<Siferah> Now, for example, you take class Shotgun
<Siferah> and do this
<Siferah> actor ShotgunThatWontDisappear : Shotgun 2001 {} // 2001 = doomednum for shotgun
<Siferah> actor ShotgunThatWillDisappear : Shotgun replaces Shotgun { /* code here */ }
<Siferah> The point here is that 2001 replacement will most likely be processed first, AND the actor that will be in place of Shotgun will NOT be a Shotgun already, so it won't get replaced by the replaces thing
<Siferah> So that things that are put on the map by the map creator, will be replaced with ShotgunThatWontDisappear actor (not replaced, in fact, ZDoom will just find the new actor instead of previous one by doomednum)
<Siferah> And everything else will be replaced with ShotgunThatWillDisappear actor
Thomas wrote:
TerminusEst13 wrote:
Thomas wrote:Because it worked just fine in 1.3
It didn't. It caused crashes.
Weird, I have several maps with script numbers over 999, never had any problem and they executed just fine. I guess it's just undefined behaviour then and I was (un)lucky?
yeah yeah script numbers over 999 work just fine except they sometimes cause the very fatal error: http://zandronum.com/tracker/view.php?id=1714

RE: [PSA]Modders: things that worked in Zandronum 1.3 may break in 2.0, please check here

Posted: Wed Apr 01, 2015 12:57 pm
by Untitled
I've found the "multiple monsters with the same name" between files hasn't caused problems - at least in single player samsarahold, which uses modified versions of every single monster in the stronghold beastiary, seems to spawn the right ones, despite the fact it's coded via replacement.

RE: [PSA]Modders: things that worked in Zandronum 1.3 may break in 2.0, please check here

Posted: Wed Apr 01, 2015 6:58 pm
by Hypnotoad
Updated to include a new important issue.

RE: [PSA]Modders: things that worked in Zandronum 1.3 may break in 2.0, please check here

Posted: Wed Apr 01, 2015 8:01 pm
by Torr Samaho
Thomas wrote: Weird, I have several maps with script numbers over 999, never had any problem and they executed just fine. I guess it's just undefined behaviour then and I was (un)lucky?
If script numbers bigger than 999 worked for you in 1.3, you were just lucky.