Parsing bsp entity list. Small problem. Help with fixing?

[Malgodur]

Hello guys, i have strange problem with q3 entity list loader..
The code looks for specified classname (in example info_player_deathmatch) and load angles/origins after it.. the problem appears when our subject origin its before its classname declaration(then code loads NEXT ENTITY origin/angle.

Code: Select all

		quake3::SEntity search;
		search.name = "info_player_deathmatch";



		s32 index = entityList.binary_search_const ( search );
		spawnNum = (rand() % index);
		if ( index >= 0 )
		{
			const SVarGroup *group;
			do
			{



				group = entityList[ spawns ].getGroup(1);

				u32 parsepos = 0;
				core::vector3df pos = quake3::getAsVector3df ( group->get ( "origin" ), parsepos );

				parsepos = 0;
				f32 angle = quake3::getAsFloat ( group->get ( "angle"), parsepos );


				core::vector3df target ( 0.f, 0.f, 1.f );
				target.rotateXZBy ( angle, core::vector3df () );
				if (spawns == spawnNum)
				{
				camera->setPosition ( pos );
				camera->setTarget ( pos + target );
				}

				spawns++;

			} while ( spawns != index );
		}
	}

and the problem...
1. This is loaded properly, code find classname a reading origin next to it..

{
"classname" "info_player_deathmatch" <- our classname, code first look for it
"angle" "360"
"origin" "-448 320 12" <- our origin, code loaded next or. to classname
}
{
"classname" "item_quad"
"origin" "-380 320 4"
}



2. And heres example of problem-causing bsp entity list... i took it from q3dm13

"origin" "100 336 24" <- origin of info_pla,, before its classname,
"angle" "0"
"classname" "info_player_deathmatch" <-this is reconized by code
"spawnflags" "4"
}
{
"origin" "-776 236 336" <- code always look for origin after found class. So its load item_health origin and "attach" it to info_player,,!!
"classname" "item_health"

I looked in svn, code there is a bit difrrent but i dindt found solution.
So im writing here, maybe somebody know how fix it?

[Katsankat]

Hi. If you can get a pointer to the entity list as a char* you can write a small parser for it, and use it instead of the Q3 namespace entity parser.

Well if the code has changed that means someone knows exactly what buttons to push.

The other idea is to process the bsp just to sort the properties (by key) for each ent. would be the easyest and fatest way, but very not practical and not standard at all because editors are given the liberty to export without constraints. A good parser will do the job.

[christianclavet]

Hi, guys!

Can we retrieve this already from BSP's?