Crystal Space
Welcome, Guest. Please login or register.
September 18, 2014, 12:51:15 pm

Login with username, password and session length
Search:     Advanced search
9018 Posts in 2051 Topics by 8478 Members
Latest Member: Annaatkinson
* Home Help Search Login Register
  Show Posts
Pages: [1]
1  Crystal Space Project Development / Bug Reports / Re: Possible Map2cs Bug on: December 18, 2005, 01:52:41 pm
Thanks for fixing this issue so quickly, sunshine smiley

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...
2  Crystal Space Project Development / Bug Reports / Possible Map2cs Bug on: December 17, 2005, 11:17:04 am
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...
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Page created in 3.232 seconds with 17 queries.