Possible Map2cs Bug

[LagxLaggor]

Hi there!

I'm currently toying around with the Crystal Space sources, and have found a possible bug in the map2cs map conversion utility. After creating a Quake3 map using GtkRadiant 1.4 (following this tutorial), I tried to run map2cs on the resulting map file, but was presented the following error message:

...
Reading map 'mystuff/foo_world69.map'...
Missing `=' on line 3 of data/config/map2cs.cfg (This warning can be fixed by removing the comment lines from the referenced cfg file, BTW, and is probably the result of another parsing bug)
Error in line 4: Format error. Keys and values for entities mustalways come in pairs. Found no match for key "classname"
...

Now this is what the beginning of the input map file looks like:

// entity 0
{
"classname" "worldspawn"
// brush 0
{
( 320 448 16 ) ( 320 -192 16 ) ( 320 -192 0 ) srtex/ground1-2 0 0 0 0.500000 0.500000 0 0 0
( 336 448 16 ) ( 320 448 16 ) ( 320 448 0 ) srtex/ground1-2 0 0 0 0.500000 0.500000 0 0 0
( 336 -192 16 ) ( 336 448 16 ) ( 336 448 0 ) srtex/ground1-2 0 0 0 0.500000 0.500000 0 0 0
( 320 -192 16 ) ( 336 -192 16 ) ( 336 -192 0 ) srtex/ground1-2 0 0 0 0.500000 0.500000 0 0 0
( 320 -192 352 ) ( 320 448 352 ) ( 336 448 352 ) srtex/ground1-2 0 0 0 0.500000 0.500000 0 0 0
( 336 448 0 ) ( 320 448 0 ) ( 320 -192 0 ) srtex/ground1-2 0 0 0 0.500000 0.500000 0 0 0
}

This didn't really make sense to me, because the Quake map format hasn't really changed since the days it was used for Quake1. I investigated and stumbled upon the following code in the map2cs source code (in "apps/import/map2cs/entity.cpp"):

...
bool CMapEntity::Read(CMapParser* pParser, CMapFile* pMap)
{
...
if ((bufferLine != bufferLine2) || !pParser->GetNextToken(Buffer))
{
        pParser->ReportError("Format error. Keys and values for entities must"
                             "always come in pairs. Found no match for key \"%s\"",
                             Key.GetData());
        return false;
}
...
}

Once you change

((bufferLine != bufferLine2) || !pParser->GetNextToken(Buffer))

to

(!pParser->GetNextToken(Buffer))

the problem disappears and the resulting map file works like a charm (in walktest, for example). The bufferline comparison seems to check if the the two tokens (in this case "classname" and "worldspawn") are on the same line - which they are, BTW. This shouldn't be checked because Quake maps (like most id Software text based file formats) can be formatted in many different ways - just like C/C++ code, for example.

Maybe I'm doing something wrong here.

I am talking about a very recent CVS snapshot here, but this problem also exists in the latest pseudo stable release of CS version 0.99...

[sunshine]

That test was indeed bogus because the parser may have already validly incremented the line number before bufferLine2 was snagged. I fixed the code in CVS. It should reflect to anonymous CVS within six hours.

[LagxLaggor]

Thanks for fixing this issue so quickly, sunshine

I'm a bit surprised that this bug had existed for so long, and that it is not mentioned anywhere else on this board or in the bugtracker (as far as i can tell). This problem rendered the map2cs utility useless - it wouldn't even compile the example map files that ship with CS. Who would even write such code without briefly testing the resulting binary? Don't people use map2cs anymore? As much as I love Blender (I've been using it for numerous years myself), I wouldn't want to create any large scale game level using that 3D app. It's a really fine prog for character modeling, animation, etc. but nowhere near as fast as say, GtkRadiant, when it comes to creating textured architecture and game level geometry...

[NicholasFox]

FINALLY, someone that is not insane
You read my mind man.

[muffinpeddler]

Yea, and I think most people use blender, so those ones have fewer problems (but still a few!).