View previous topic :: View next topic |
Author |
Message |
rhinoduck Potatoes
Joined: 22 Oct 2012
|
Posted: Fri Sep 25, 2015 11:39 am Post subject: ZD bombs out on malformed MAPINFO |
|
|
Both the client and the server bomb out on malformed MAPINFO. Would it be possible to just stop parsing and print a warning instead as it happens in case of unknown keywords? Then it would be possible to load an additional wad with just the fixed MAPINFO and not alter the original one.
Here is a real life example:
Code: | map MAP01 lookup "Hangar 14"
next MAP02
secretnext MAP02
sky1 SKY1
cluster 5
sucktime 1
music D_RUNNIN |
You may have noticed the extraneous lookup keyword on the first line, but that is not the real issue. The real issue is that the sky entry is missing its second numerical argument which makes ZD take a nosedive. The wad is Five Rooms of Doom if you want to test with it.
EDIT: Added a screenshot of the error the client produces.
Last edited by rhinoduck on Mon Sep 28, 2015 6:45 pm; edited 1 time in total |
|
Back to top |
|
|
Evolution Wicked Sick!
Joined: 06 Sep 2005
|
Posted: Sat Sep 26, 2015 7:43 pm Post subject: |
|
|
That's a low sucktime |
|
Back to top |
|
|
Aeyesx Dominating!
Joined: 13 Oct 2012
|
Posted: Mon Sep 28, 2015 11:33 am Post subject: |
|
|
I am kinda of against,
Some idea:
Instead i'd go for ZMAPINFO, which is newer ZDoom format and while it is present MAPINFO would be ignored. Which would allow us to easily patch those shitty wads
Some hate:
Actually someone asked me year ago to fix this wad, another boom crap with corrupted MAPINFO, This is endless...
This is clear response on why obsolete boom sucks and causes only incompatibility... and yet still a lot of mappers decides to create their wad in boom map format!
Which most of the time has :
a) Zero online optimalizations (aka 999 999 monsters activated on shot)
b) Missing or corrupted NODES
c) Or just wasting with 999 999 linedefs. (which is certainly not mean of quality map but more likely lower FPS and overall HW wasting) |
|
Back to top |
|
|
Empyre Unstoppable!
Joined: 13 Dec 2006 Location: Texas, USA
|
Posted: Mon Sep 28, 2015 5:29 pm Post subject: |
|
|
My suggestion would be a compromise. Instead of implementing all the keywords that ZDoom has and ZDaemon doesn't, just make a list of them and skip them when they're encountered in MAPINFO. You might have to parse them just enough to recognize and skip, for example, a section that defines episodes. I had to work around this specific problem by defining the episodes at the very end of MAPINFO, so all the stuff that dealt with maps had already been processed.
However, I don't think that would solve the problem with the missing numerical argument. It would be nicer to handle such errors more gracefully. Either have a default value for that number if it's not specified, or skip that line, or stop executing MAPINFO. Any of these options would be better than crashing, and it would make it possible to have a fixed MAPINFO in another wad, like rhinoduck wants. |
|
Back to top |
|
|
Aeyesx Dominating!
Joined: 13 Oct 2012
|
Posted: Mon Sep 28, 2015 5:59 pm Post subject: |
|
|
Why to bother? ZMAPINFO would overwrite anything if found...it would be more flexible and makes more sence.. then just mixing mapinfo. |
|
Back to top |
|
|
rhinoduck Potatoes
Joined: 22 Oct 2012
|
Posted: Mon Sep 28, 2015 6:43 pm Post subject: |
|
|
All I am asking for here is a small change to the current MAPINFO parser that would stop the whole ZD process from unnecessarily throwing in the towel when the MAPINFO parser does not get the value type it expects (and in other possible cases which cause unnecessary termination). That is why I posted it as a "bug", and why I suggested the simplest solution in hope for a quick resolution.
So, unless the devs decide to quickly kill a fly with a sledgehammer, I'd like to see this "fixed" without the delay of adding new things, and I consider a separate comprehensive feature request a better place to discuss other changes (ZMAPINFO is definitely out of scope here). |
|
Back to top |
|
|
Kilgore Air Cavalry
Joined: 17 Jun 2003 Location: Up the river
|
Posted: Mon Sep 28, 2015 6:46 pm Post subject: |
|
|
Well... users may find it inconvenient, but the given mapinfo *is* bad and zdaemon is right in rejecting it. Calling it "bombing out" implies that it's somehow zdaemon's fault, and well... (a) an error message is NOT a bomb (do you see any GPF there? I don't), and (2) zdaemon's parser is correct in pointing out that there is something missing. If you want to blame someone, why don't you talk to wrote that mapinfo?
Anyway... this is a feature request rather than a bug report; and it's just implemented; it will show up on the next release. |
|
Back to top |
|
|
rhinoduck Potatoes
Joined: 22 Oct 2012
|
Posted: Mon Sep 28, 2015 7:48 pm Post subject: |
|
|
ad (a): I intentionally used 'bomb out' as in calling I_Error (not sure where I saw it anymore and why it stick in my head) and avoided using 'crash'. I hope we're on the same boat now.
ad (2): I'm not throwing blame around and I never complained about ZD rejecting the MAPINFO, all I complained about is how this is done.
---after your edit
Thanks. |
|
Back to top |
|
|
|