Transport Tycoon Forums

OzTransLtd wrote:Would it be possible to allow those string codes (e.g. \94) found in ttdpttxt.txt to be placed in plain text strings in action-4 and then have them converted to hex by GRFCodec. That would make it simpler to define those F8xx texts in a .grf.

Csaboka wrote:I agree with Michael. Decrypting something like \2+ isn't much better than decrypting a hex byte.

Personally, I always need to use the wiki when I want to code something, because I can't remember the format of the actions.

Csaboka wrote:This, of course, may be too much work for too little benefit, but I think it would make more sense than making cryptic shortcuts for cryptic originals.

Csaboka wrote:If we want to make NFOs more readable, I think we should make them more like a high level language instead, making it more verbose, but more human-readable at the same time.

CapacityCallback(){
 switch_byte(var47&FF){
  case 00:fail;//Passengers
  case 01:return d132; //tourists
  default:return (d112*d16)/(var47[1]&FF);
 }
}

CallbackCheck(){
 switch_byte(var0C){
  case 19:CapacityCallback();
  case 15:LiveryCallback();
  default:GetGraphics();
 }
}

Korenn wrote:what Csaboka proposed is not really a compiler but more a translator, it has a 1-1 relation to the hex codes,

02 00 00 85 0A 00 FF FF 03
00 FF 00 00 10 00 
//...

action2 word trains id 0 var(0a) shift 0 mask FFFF
// 02    85    00    00    0A      00      FF FF       03
   case 00 .. 10:   FF05
//     00 00 10 00  05 FF

Korenn wrote:though having to install a c compiler to use grfcodec doesn't sound very accessable.

SpComb wrote:As well, there isn't really any need to make it create .grf files directly from the format. I would imagine that that isn't exactly easy. If it's easier, a translator between NFO and this language would probably be simpler to make (could be wrong), and work just as well.

SpComb wrote:Dunno about comments...

Csaboka wrote:I was just saying what I would like;

1. Actions 0..4 require a feature (eg "trains", "rvs", "ships", ...)
2. Action 2 requires "word" or "dword", and may optionally specify "byte"
3. Action 3 requires a list of vIDs, as "vid(x,y,z,...)", or "vid()" for generics
4. Action 2 may specify either a CargoID, as "id(##)", or a name, as "id(foo)". ## must be exactly two hex characters in the 00..7F range, else it is a name. The CargoID associated with a name is undefined, but will be in the 80..FF range.
5. After all necessary specifiers, Actions 2 and 3 take the following format:

   Code: Select all

   switch(expr){ // "(expr)" is only valid for Action 2, and may be any valid C expression, using the operators +, -, /, %, *, &, |, ^, and the functions min, max, umin, and umax.
   // The four functions take two or more arguments. Where relevant, the operators are the unsigned versions.
   // In action 3, (expr) is implicitly the translated cargo type.
   // RPN expression instead? -- Far easier for me to implement.
   case foo[..bar]: cid(cid); // "[..bar]" is only valid in Action 2.
   case baz[..quz]: return expr; // the stated callback return 
   // any number of case expressions is permitted.
   // foo, &c. may be expressed in decimal or hex (0x prefix).
   default: id(vid); // exactly one of these is required.
   default: return expr; // exactly one of these is required. This format is only valid in Action 2.
   }

   Alternatively, the above may be simply be replaced with either "id(vid);" or "return expr;