Zandronum Chat on our Discord Server Get the latest version: 3.2
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002061Zandronum[All Projects] Bugpublic2015-01-10 16:502015-01-10 19:52
ReporterTorr Samaho 
Assigned ToBlzut3 
PriorityhighSeverityblockReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version2.0-beta 
Target Version2.0Fixed in Version 
Summary0002061: DECORATE parser of 2.0 rejects code that was allowed in 1.x
Description'http://www.mediafire.com/download/cdin9ijgn8i0qbe/Doom2TowerDefense%282%29.rar [^]'

can be loaded with 1.x (if you load skulltag_actors.pk3 skulltag_data_126.pk3), but not with 2.0. Apparently, this is caused by the ZDoom updates to the DECORATE parser.

Did ZDoom intentionally break backwards compatibility here or is this a Zandronum bug (merge error, ZDoom error that has been fixed by now in ZDoom, 1.X allowed DECORATE code ZDoom never accepted, etc.)?
Attached Files

- Relationships

-  Notes
User avatar (0011360)
Edward-san (developer)
2015-01-10 19:13
edited on: 2015-01-10 19:14

 From what I could see, it's sufficient this:


actor FatShot replaces Fatshot
{
}


Apparently zdoom lost (intentionally?) the case sensitive checking on name collisions. I can reproduce this on latest zdoom.
User avatar (0011361)
Torr Samaho (administrator)
2015-01-10 19:25

 You are right. GZDoom 323 / Zandronum 1.x accepts this code snippet, GZDoom 900 / Zandronum 2.0 does not. ZDoom 2.7.1 still doesn't accept it. Now the question is, whether ZDoom intentionally broke backwards compatibility with existing code.
User avatar (0011362)
Blzut3 (administrator)
2015-01-10 19:49

 It's not somehow related to this is it?'http://zdoom.org/wiki/RTC-3057#Pistol_bug [^]'

The one thing I can say for sure is yes, that piece of code is ill-formed. Names in ZDoom were intended to be case insensitive. From my understanding of the change, the actor header was the only place where it was checked case sensitive so it resulted in some quirks.

I think it should be triggering Zandronum's actor renaming though shouldn't it? I know we've been warning people forever that doing "actor Demon : Demon replaces Demon" is ill-formed. If they chose not to listen, that's their problem imo.

Actually with some testing it looks like at some point ZDoom introduced similar renaming code, but decided to properly check that the construct I mentioned produces an error (inheriting from itself or replacing itself).
User avatar (0011363)
Dusk (developer)
2015-01-10 19:52

 edward-san isolated the changeset'http://zdoom.org/Changelog/6ec3076/files [^]'

ZDoom fixed this as a bug which in turn causes the parser to reject ill-formed DECORATE like this.


<@Blzut3> yeah, definitely a wad error
<@Blzut3> "not listening to developer warnings"


Nothing to do here.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2015-01-10 16:50 Torr Samaho New Issue
2015-01-10 16:50 Torr Samaho Status new => assigned
2015-01-10 16:50 Torr Samaho Assigned To => Blzut3
2015-01-10 19:13 Edward-san Note Added: 0011360
2015-01-10 19:14 Edward-san Note Edited: 0011360 View Revisions
2015-01-10 19:14 Edward-san Note Edited: 0011360 View Revisions
2015-01-10 19:25 Torr Samaho Note Added: 0011361
2015-01-10 19:49 Blzut3 Note Added: 0011362
2015-01-10 19:52 Dusk Note Added: 0011363
2015-01-10 19:52 Dusk Status assigned => closed
2015-01-10 19:52 Dusk Resolution open => no change required




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker