Map default boxes

[Satirik]

If you want to add your own boxes to your maps, you can add a "maps/boxes.tdf" :

Code: Select all

[LAYOUT0]
{
	Name=2v2 duel;
	NbTeam=2;

	[BOX0]
	{
		Left=0;
		Top=0;
		Right=0.26;
		Bottom=1;
	}
	[BOX1]
	{
		Left=0.74;
		Top=0;
		Right=1;
		Bottom=1;
	}
}
[LAYOUT1]
{
	Name=2v2v2 duel;
	NbTeam=3;

	[BOX0]
	{
		Left=0;
		Top=0;
		Right=0.26;
		Bottom=1;
	}
	[BOX1]
	{
		Left=0.74;
		Top=0;
		Right=1;
		Bottom=1;
	}
	[BOX2]
	{
		Left=0.4;
		Top=0;
		Right=0.6;
		Bottom=1;
	}
}

The lobby will choose the default boxes depending on the number of team in the battle. If you have any suggestion ...

[trepan]

Nice addition, Satirik

For the most part, TDF has been pulled out of the Spring
engine as the native configuration format (in favour of lua).
The main remaining file to be converted is "script.txt", the
game configuration file (and that too shall fall, and the
villagers shall rejoice).

If you do decide to switch to that-other-format (or even
if you don't I guess), it might be nice to move the parsing
for that feature into unitsync.

P.S. Using a lua config file might make it easier to pump
out loads of layouts for low to high player counts.

[FLOZi]

Argh, zombie TDFs

[AF]

I would not like to rely on unitsync to parse these boxes as I have had this feature in AFLobby/battlehub for months now. I would very much like the ability to save to a file and load it back up, if not for sharing purposes, but to make it easier for map makers to write the box file to begin with.

A lua version would nonetheless be preferable, regardless of wether it is unitsync or the lobby that parses it.

[trepan]

Having a unitsync interface for the start boxes would
enforce a standard access method to the information
provided by map archives. You could still have a custom
system using any format you like for local layouts. That
being said, it would be nice to export the LuaParser
interface through unitsync.

I spoke with Satirik, and the following was discussed
as being a possible unitsync interface for map start
box layouts:

Code: Select all

DLL_EXPORT int         __stdcall GetStartLayoutCount();
DLL_EXPORT const char* __stdcall GetStartLayoutName(int layout);
DLL_EXPORT int         __stdcall GetStartLayoutTeamCount(int layout);
DLL_EXPORT float       __stdcall GetStartLayoutBoxLeft(int layout, int team);
DLL_EXPORT float       __stdcall GetStartLayoutBoxTop(int layout, int team);
DLL_EXPORT float       __stdcall GetStartLayoutBoxBottom(int layout, int team);
DLL_EXPORT float       __stdcall GetStartLayoutBoxRight(int layout, int team);

[aegis]

can't return a struct of floats with the corners?

[trepan]

P.S. the LuaParser interface might look something like this:

Code: Select all

DLL_EXPORT int         __stdcall LuaParserOpen(const char* filename);    
DLL_EXPORT const char* __stdcall LuaParserError();
DLL_EXPORT int         __stdcall LuaParserKeyExists(const char* expr);
DLL_EXPORT int         __stdcall LuaParserGetInt(const char* expr, int def);  
DLL_EXPORT int         __stdcall LuaParserGetBool(const char* expr, int def); 
DLL_EXPORT float       __stdcall LuaParserGetFloat(const char* expr, float def); 
DLL_EXPORT const char* __stdcall LuaParserGetString(const char* expr, const char* def);
DLL_EXPORT void        __stdcall LuaParserClose();

The 'expr' parameters would look like standard lua access
expressions (already written into the parser as SubTableExpr()).
A bogus example:

Code: Select all

if (LuaParserOpen("citydata.lua")) {
  float v = LuaParserGetFloat("city.buildings[12].rooms[3].volume");
  LuaParserClose();
} else {
  printf("%s\n", LuaParserError());
}

[AF]

Interesting but what if ones lobby already has a lua parser?

[trepan]

Then one wouldn't necessarily need to use the lua parser
provided by unitsync, now would one? But, if you're doing
anything that requires that all clients read the same data,
you might consider using the unitsync lua parser anyways.
There are modifications made to the spring lua library (and
some additions to the LuaParser environment), that might
change the output on clients that use an alternate parser.

[Tobi]

For that reason I recommend that floating point values in lobby clients are always stored as strings and passed along in that format from what is received from host to script.txt

If they are converted in between to float and then back to string all kind of platform/framework dependent rounding/formatting issues may happen and a slightly different value may end up in script.txt of the client then on the host, resulting in desyncs of the game.

Actually I'd say using integers (and strings) only would be better but we have floating point values already anyway, so recommendation still applies.

[el_matarife]

You should add tagging start boxes by suggested teams as well, so maps with defined "sides" for two teams could tag a bunch of spots "team 1" and a bunch of spots "team 2" so we wouldn't have to deal with making our player IDs perfect anymore.

[hoijui]

+1