The online racing simulator
Request to Scawen: specifications of cmx, lyt & other files
I don't ask just for specifications, I know they are here. My request is to release a C header file, like InSim.txt, so that other programmers could include them or parse.

I have a PHP parser of InSim.txt that imports all the consants and structures into PHP. I could use it for file formats if there were a file of the same format.
I know that. Those in the wiki repeat the descriptions from the official site. But I want a different thing. Look into InSim.txt for the example. That file effectively is a C header file, you can include it into code and have all the structures defined. You don't have to rewrite them in your code as I'm doing right now with CMX files.

See the difference.

CMX specification. Just a text.

LIGHTSCHEME BLOCK :

16 char 0 lightscheme name : name
16 char 16 sky texture name : texture
16 char 32 environment texture : texture
1 col 48 sky colour : rgb0 - average sky colour
1 col 52 sun colour : rgb0 - artist defined
1 float 56 sun intensity : sun colour multiplier
1 float 60 sky boost : sky colour multiplier
1 float 64 sun heading : radians, CCW from forward(Y)
1 float 68 sun pitch : radians, up from ground

InSim: an includable header.
struct IS_ISI // InSim Init - packet to initialise the InSim system
{
byte Size; // 44
byte Type; // ISP_ISI
byte ReqI; // If non-zero LFS will send an IS_VER packet
byte Zero; // 0

word UDPPort; // Port for UDP replies from LFS (0 to 65535)
word Flags; // Bit flags for options (see below)

byte Sp0; // 0
byte Prefix; // Special host message prefix character
word Interval; // Time in ms between NLP or MCI (0 = none)

char Admin[16]; // Admin password (if set in LFS)
char IName[16]; // A short name for your program
};

I'd like, for example, the CMX specs to be presented like the latter. (Actually, I already don't need that since I've made the parser I needed).

If somebody has made those structures for other projects, please, share them.
#4 - Ian.H
Silly question detail, wouldn't it have been quicker to have written a parser for the current format than wait for such a request to be answered (assuming it was done)?

Not having a dig.. but you obviously know PHP well enough to parse the C header and port it to PHP automagically.. I wouldn't have thought parsing the current format of those files much more difficult.

Just a thought



Regards,

Ian
Quote from Ian.H :Silly question


Quote from detail :(Actually, I already don't need that since I've made the parser I needed).



It could be useful if someone shares this stuff. BTW, I have published a PHP parser for InSim (it's not yet able to make dynamic structures, like CMX where an int defines the number of blocks, but it won't be hard to implement).
Quote from detail :



It could be useful if someone shares this stuff. BTW, I have published a PHP parser for InSim (it's not yet able to make dynamic structures, like CMX where an int defines the number of blocks, but it won't be hard to implement).

Fell free to take some code from they LFSWorldSDK Lib, I handle dynamic structures there.
#7 - Ian.H
Quote from detail :



It could be useful if someone shares this stuff. BTW, I have published a PHP parser for InSim (it's not yet able to make dynamic structures, like CMX where an int defines the number of blocks, but it won't be hard to implement).

Ahhh.. didn't think it'd be difficult

Sounds like you have something planned judging by your interest in the CMX files



Regards,

Ian
#8 - Stuff
Yeah! I've been meaning to do some digging and maybe contact Scawen about the revision change in the .lyt format. Somewhere between the X->Y update it changed from 250 to 251 and not sure why. The wiki version says 247 so no help there..
Ray, Most of the setups are workable between versions for the exception of BL1+2 (the objects are misplaced, and on AutoX lot, they are compressed somehow, all of them are closer together). I went through a ton of setups for CTRA, and that's the only issues I had were at BL1 and 2, and the AutoX objects became closer together at BL, but no issues became of it (if anything, made the tracks look better somehow, due to smaller gaps between objects).
The setup format changed from 250 to 251 as well. I think that's just the internal LFS version number that we can ignore. In the set format at least, the setup format version number immediately follows that, and that has not changed, and indeed, there is no difference between the X and Y files.
If anyone considers this post unreasonable, then I'll happily retract it. I have had 3 days where I've only been "home" for a few hours. The rest have been out for work, either on the road or in front of shitty customers. As such I maybe a bit more irritable than usual.

However.
Quote from detail :CMX specification. Just a text.

The time that has been taken by yourself typing various responses could've easily accounted for manually converting those "text" descriptions to C structures. They're not exactly difficult to do. All the information you require is in the description that various people have taken the trouble to write.

I'll happily rework/rewrite some of them, if you wish, but considering you only want them to run them through your C struct parser for PHP anyway leads me to wonder what the point is and what you gain by requesting them in the "original" format.

Had the development team felt that these were files that should be officially supported then I'm sure we would've seen them published in the same manner as other file formats. The fact that they're not gives the team more flexibility as they can plainly argue that they're not adversely affecting any publically documented formats that people may rely on.

FGED GREDG RDFGDR GSFDG