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