OTTD Unlimited?

[PikkaBird]

Example:

Okay, now make it so that;

*top speed is increased by 10mph for vehicles built after the 5th of June 1967.
*it has another vehicle permenently attached behind it.
*it cannot haul any wagons except passenger carriages.
*it is orange on wednesdays.
*it can be refit so that it isn't orange on wednesdays, but weighs three tons more and has 100 more horsepower.
*it plays a particular sound effect every 32 game ticks, when moving between 60 and 89 miles per hour.

and tell me that your xml is not going to be more complicated than well-commented and formatted NFO.

And if someone is unhappy because he can't specify that his engine is a transformer that morphs between coal-truck and maglev-engine, he can add a morphing-engine-type to ottd and update the scripting-version to 1.6 and it's done.

Wow, as easy as that huh?

[Haukinger]

Okay, now make it so that;

*top speed is increased by 10mph for vehicles built after the 5th of June 1967.

Code: Select all

<!-- The Topspeed-element specifies the maximum speed of the vehicle.
There's a built in function AlterAfterDate that modifies the topspeed by a
specific amount when a specific date is reached.
Remember that you can always give a script in a Modifier-element -->
<Topspeed default="150mph">
<AlterAfterDate date="6.5.1967" amount="10mph" />
</Topspeed>

*it has another vehicle permenently attached behind it.

Code: Select all

<!-- The Multicar-element allows for different actual vehicles to be
seen a logically one vehicle. This way steam engines can have a trailing
tender. Possible elements:
AppendAlways: upon creation of vehicle, always immediately create the given vehicle and append it.
AppendConditional: upon creation of vehicle, create and append the given vehicle if the condition-script returns true.-->
<Multicar>
<AppendAlways name="small diesel powerstation on wheels" />
</Multicar>

*it cannot haul any wagons except passenger carriages.

Code: Select all

<!-- Whatever matches first counts -->
<AllowedCars>
<Car Cargo="Passengers" />
</AllowedCars>
<DisallowedCars>
<All />
</DisallowedCars>

*it is orange on wednesdays.

Code: Select all

<!-- Colour can be either an int value of a specific colour or a script that returns an int as colour. -->
<Colour script="weirdWednesdayOrange.lua" />

*it can be refit so that it isn't orange on wednesdays, but weighs three tons more and has 100 more horsepower.

Code: Select all

<RefitableTo name="otherEngineWithoutWeirdOrangeButHeavier" />

*it plays a particular sound effect every 32 game ticks, when moving between 60 and 89 miles per hour.

Code: Select all

<!-- The tickcallback is called every tick -->
<Tickcallback script="beep_between_60_and_89.lua" />

Assume that scripts are passed a handle to the entity (vehicle, station, tree...) that calls the sript and can access the world-state.

and tell me that your xml is not going to be more complicated than well-commented and formatted NFO.

I'd like to see a well-commented and formatted NFO that does the above things.

[brupje]

Why write a parser if good parsers exist (timyXML for example) ?

Well, maybe because you need a second parser to parse the DOM to translate it into useable in-game information?

Secondly, how would you incorporate sprites? Adding binary data would defy the reason why you choose for XML as it will (probly) not work right in a text editor. The nice thing of the current (New)GRF format is that all sprites can be read directly from the files into the memory when needed. No parsing whatsoever, no opening files (as the GRF is already opened). To avoid opening lots of files during the game with XML, you have to load all of them into memory (and keeping them there). This will use quite some memory when it is totally unneccessary.

Putting it all in one TAR file would solve that problem I guess and refer from the XML to the binary data. Would make it better maintainable also, because you can easily replace a graphic with another using a simple archive program.

[Haukinger]

Why write a parser if good parsers exist (tinyXML for example) ?

Well, maybe because you need a second parser to parse the DOM to translate it into useable in-game information?

Have a look at tinyxml. You can get all data out of the dom using simple stl-like iterators, that even filter types. Parsing needn't be done in one large parser but can be with each datatype. Then use this
and pass the xml-element that defines the entity to the creator-function.
voila, there's the struct, completely initialised. OOD has it's benefits, too, not only drawbacks

Secondly, how would you incorporate sprites? Adding binary data would defy the reason why you choose for XML as it will (probly) not work right in a text editor. The nice thing of the current (New)GRF format is that all sprites can be read directly from the files into the memory when needed. No parsing whatsoever, no opening files (as the GRF is already opened). To avoid opening lots of files during the game with XML, you have to load all of them into memory (and keeping them there). This will use quite some memory when it is totally unneccessary.

Putting it all in one TAR file would solve that problem I guess and refer from the XML to the binary data. Would make it better maintainable also, because you can easily replace a graphic with another using a simple archive program.

And it makes name clashes impossible, because each trainset can only see what's inside it's archive.

[willisterman]

I have to say that games that are easily modable, last a lot longer than games that are not. For example, the full Command and Conquer series, Neverwinter Nights, Morrowind, Civilization.

The benifit being that any average Joe can say, this game would be better for me if so and so happened. But the average Joe can then go into the data files and after a quick read understand enough to play around. The number of mods available for these games attest to that.

At the moment, anyone can modify the sorcecode, but actually adding the mod isnt a easy process, you have to manually fix errors between different mods, correct them as the source changes.

Having a way that allowed the average Joe to pick up a data file, and fiddle would go a long way. An average Joe readable XML schematic would be great.

I would recomend voting for it, just to get an idea of how many would welcome the change.

I'm not saying this for point (b) either. I am a sufficiently good programmer to get my head around the NFO structure, if I chose to do so, but all I really want to do is change the odd train speed and fiddle, and learning that much code just doesnt seem worth it, wearas if I want to change something with the game itself, I can just dive into the sourcecode, read for a bit and then work out what to do.

It says a lot that the addon modules are more user unfriendly and harder to learn that the sourcecode itself.

[DaleStan]

Replies-To: DaleStan, Haukinger, and willisterman

and a language that can perform almost any non-looping combination of C's +, -, /, *, %, ^, |, and & operators, as well as the min and max functions, on up to, and beyond, 10K of input data.
That still holds even if we restrict ourselves to the non-advanced action 2s. The math becomes somewhat more restricted, but I still can't find a reasonable construct that can't be encoded.

Oops. I lied there. I meant "still holds even if we do not use the 1K of explicit read/write memory, and restrict ourselves to the 1 dword of implicitly written memory."

*it is orange on wednesdays.

Code: Select all

<!-- Colour can be either an int value of a specific colour or a script that returns an int as colour. -->
<Colour script="weirdWednesdayOrange.lua" />

*it plays a particular sound effect every 32 game ticks, when moving between 60 and 89 miles per hour.

Code: Select all

<!-- The tickcallback is called every tick -->
<Tickcallback script="beep_between_60_and_89.lua" />

Major cop out alert! You haven't done these until you write the script too.

*it can be refit so that it isn't orange on wednesdays, but weighs three tons more and has 100 more horsepower.

Code: Select all

<RefitableTo name="otherEngineWithoutWeirdOrangeButHeavier" />

Not quite as much of a cop out, but you still haven't done this until you code otherEngineWithoutWeirdOrangeButHeavier.

And you still haven't done variational and random properly.
Take the following, for a single vehicle, and a two GRF parameters. Parameter 1 is one of 0, 1, or 2, and parameter 2 is either 0 or 1.

1) If displaying sprites for the purchase list, goto 2, otherwise goto 3.
2) Show the sprite set whose ID matches parameter 1. (0, 1, or 2).
3) If parameter 1 is 0, randomly select between 4 and 5; if parameter 1 is 1, goto 4; otherwise goto 5.
4) If carrying a passenger-class cargo, go to 6; if carrying goods, goto 7; if carrying a liquid-class cargo, goto 8, else goto 9.
5) If carrying a passenger-class cargo, goto 11; if carrying goods, goto 12; if carrying a liquid-class cargo, goto 13, else goto 14.
6) Show sprite set for unnamed passenger livery.
7) If the user has refit this vehicle to "liquid" goods, goto 8, else goto 9.
8) Show the in-motion sprite set corresponding to the unnamed cargo-carriage livery.
9) If loading or unloading at a station, go to 10, else goto 8.
15) Show the loading sprite set corresponding to the unnamed cargo-carriage livery.
11) Show the sprite set that corresponds to the users requested passenger-carriage livery.
12) If the user has refit this vehicle to "liquid" goods, goto 13, else goto 14.
13) Show the in-motion sprite set corresponding to the users requested cargo-carriage livery.
14) If loading or unloading at a station, go to 15, else goto 13.
15) Show the loading sprite set corresponding to the users requested cargo-carriage livery.

Also:

1) Up to 255 liveries of each type are possible, so code for three named passenger-carriage liveries and two named cargo-carriage liveries, and make sure it is clear how to extend to more and/or limit it to fewer. These numbers do not include the unnamed liveries.
2) The last cargo-carriage livery changes its name and its corresponding sprites if the vehicle was built in 1980 or later.
3a) If parameter 2 is 0, the second passenger-carriage livery changes its sprites if the vehicle was last serviced on or after 1/1/1985, and again if the vehicle was last serviced on or after 1/1/1998
3b) If parameter 2 is 1, as above, except the vehicle's purchase date is used instead of the vehicle's last-service date.
4) Make sure things are arranged so that the available liveries can be clearly displayed to the user, assuming that the user has a choice (ie #3 went to 5, not 4), and are properly associated with their corresponding cargos, so that it is clear that "Passenger livery 1" may not be selected without also refitting to one of the passenger-class cargos. This does not include the unnamed liveries, which may not be selected by the user, and are only shown if #3 chains to #4.
5) Make sure that the liquid vs solid distinction is available for all cargo-carriage liveries, including the unnamed livery referenced by 8/10, but only if goods are being carried.
6) This is NOT an invented scenario. The description you see above is basically the functionality of the Boeing 747s that appear in the PlaneSet, except that there are seven or eight passenger carriage liveries, not counting the unnamed one, and the two parameters are bit-packed into one.

At the moment, anyone can modify the sorcecode, but actually adding the mod isnt a easy process, you have to manually fix errors between different mods, correct them as the source changes.

Not true. Every newgrf that conforms to the current version of the documentation will conform to ALL FUTURE VERSIONS of the documentation.

The reason newgrf files change (baring the obvious "there was a bug") is because things get added to the spec that the coder wants to use. All the other programs you name have static addon specs, so the comparison is hardly fair.

I would recommend voting for it, just to get an idea of how many would welcome the change.

Heck. I'd vote for it, if I thought it would do any good. But there's a major difference between "Somebody ought to go write an XML spec", and "I will go write an XML spec". To my no one even said the latter, much less followed through.

I'm not saying this for point (b) either. I am a sufficiently good programmer to get my head around the NFO structure, if I chose to do so, but all I really want to do is change the odd train speed and fiddle, and learning that much code just doesnt seem worth it,

Then it most certainly is point B. Changing the speed of any number of trains takes four header lines and two lines of code.
NFORenum will generate the first three header lines automatically, and will update the fourth as necessary, provided that it exists.
That leaves typing one stub header line and two lines of code.

Doesn't seem like "that much code" to me.

It says a lot that the addon modules are more user unfriendly and harder to learn that the sourcecode itself.

That's your fault, for picking an add-on format that was designed by an assembly programmer, to be used by a program that's written mostly in assembly, except for a few bits that are in machine code.

[willisterman]

At the moment, anyone can modify the sorcecode, but actually adding the mod isnt a easy process, you have to manually fix errors between different mods, correct them as the source changes.

Not true. Every newgrf that conforms to the current version of the documentation will conform to ALL FUTURE VERSIONS of the documentation.

That was my mistake, I switched between two ideas mid sentance, I was actually talking about the patches, and the amount of trouble I had merging more than a few patches to the latest source, and updating them I was wasn't actually talking about new grfs in that sentance. Confusing, I know, sorry.

But the 4 headers and 2 lines of code is not as easy as modifing something that should really just be a value in a array. Max Speed = 200 to Max Speed = 100 should be just as easy as typing it in the correct place.

I'd never complain this in a normal game, as what you get is what you are given, but here people are willing to change the game if they think it is better, and really, loading all vechical data from a file at startup cannot be that CPU intensive.

I think it would mean that more graphics would be available, more changes available, which can only be a good thing for the game.

I would look into changing the game myself to allow it to do that, but it feels like it would be wasted effort, when you look at the number of patches in the devopment forum that have little chance of getting added, but are really good, like the copy paste patch. I would hate to put all that work into it, and then just have the patch vanish because very few people could use it, or it wouldn't be offically supported, only on a intergrated build.

And I dont remember picking a addon format at all really, dont think I ever had a choice.

If a addition was coded, that could read from a XML schematic and newGRFs, and modify the game data, would it actually ever get in the trunk? As I wouldnt mind attempting it, if I knew it had even the slightest chance to get in.

[Haukinger]

Well, this doesn't lead us anywhere. It's a matter of fact that a high-level scripting language is easier to read, write and learn than assembler-like bytecode as it is a matter of fact that the nfo-interpreter is implemented in ottd and works. On the other hand, the ottd-code is over 100 KLOC of a hell of a mess... not likely that anyone will implement an easy-modding-system, because the developers happen to be nfo-experts and don't recognize the benefits of having a more user-friendly scripting engine.

[DaleStan]

But the 4 headers and 2 lines of code is not as easy as modifing something that should really just be a value in a array. Max Speed = 200 to Max Speed = 100 should be just as easy as typing it in the correct place.

It is a value in an array (I'll call it an array of structures, for convienience sake). The first line of code is bookkeeping -- You have specify the GRF version and your file's unique ID, and it is recommended that you specify a name and description.
Patch files and manual source changes require basically the same bookkeeping. The only difference is that they don't enforce it.

The second line specifies the array, the array index, the structure member, and the new value.

And I dont remember picking a addon format at all really, dont think I ever had a choice.

"You" in this case, in not you personally, but everyone who has had any part in the adoption of NFO as the standard scripting language for TTDPatch and OpenTTD graphics. This includes all NFO coders, most TTDPatch devs, many OpenTTD devs, and everyone who has ever complained that OpenTTD doesn't support some GRF file or otherwise implied that Open should.

If a addition was coded, that could read from a XML schematic and newGRFs, and modify the game data, would it actually ever get in the trunk?

If it does everything that NFO can do, is at least as extensible as NFO, has the proper coding style, and all that, there might be half a chance.
But why not write it as an independent XML->NFO or XML->GRF compiler instead? That leaves you with full control over the source, the release schedule, the support, &c.

Also, it's what I'm doing, with the C-injection I'm attempting over in the grfcodec discussion thread.

Well, this doesn't lead us anywhere.

Why do I think that you're saying this because you can't figure out how to write XML and/or LUA that satisfies my requests?

not likely that anyone will implement an easy-modding-system, because the developers happen to be nfo-experts and don't recognize the benefits of having a more user-friendly scripting engine.

What part of

I would recommend voting for it, just to get an idea of how many would welcome the change.

Heck. I'd vote for it, if I thought it would do any good.

did you not understand? An XML spec would be wonderful, if for no other reason than to get people like you to SHUT UP.
Except, of course, that it wouldn't actually achieve that. "Oh, the XML spec was designed badly. What we really need is an INI file." "Oh the INI format is too ...", ad infinitum.

[Haukinger]

Why do I think that you're saying this because you can't figure out how to write XML and/or LUA that satisfies my requests?

did you not understand? An XML spec would be wonderful, if for no other reason than to get people like you to SHUT UP.

No need to be rude.
The problem is not to write a lua-function that beeps every 32 ticks when driving between 60 to 89 mph, every child could do that:

Code: Select all

function TickCallback( vehicle, world ) 
    if world:get_clock()%32==0 and vehicle:get_speed()>=60 and vehicle:get_speed()<=89 then
        beep()
    end
end

Assume that ottd exports an object world with method get_clock that returns the current tick and an object vehicle with method get_speed that returns the current speed of the vehicle in question and finally a function beep that beeps. It has to do anyway, either to the nfo-interpreter or lua or any other scripting-engine.

I agree with willisterman that with the current restrictive policy of what is allowed into trunk, any time invested in integrating lua or xml in ottd is wasted.

[DaleStan]

And what about the other one? The lua script that selects a different sprite on Wednesdays? Or maybe Pikka meant that the vehicle should act as if the company color changed to orange on Wednesdays. Better do both, just to be sure.
However you do your sprite selection, make sure that it can handle arrangements where a sprite can be accessed via multiple paths, and even from multiple vehicles, without massive copy&paste.

[Brianetta]

orange on Wednesdays

...just text FILM to 241!

(sorry, you won't get that if you haven't been in a UK cinema lately)

[PikkaBird]

The problem is not to write a lua-function that beeps every 32 ticks when driving between 60 to 89 mph, every child could do that:

Wait, you mean I have to learn lua if I want to do anything that the xml spec author hasn't predicted I'll want to do? How come "every child" can write languages you're familiar with, but not nfo?

Code: Select all

1 * 1  02 00 01 81 0A 04 01 01 <sound> 00 00 <fail> // play sound every second event
1 * 1  02 00 01 81 10 00 FF 01 01 00 07 07 <fail> // sfx event check (16 tick)
1 * 1  02 00 01 85 0C 00 FF FF 01 01 00 33 00 33 00 <fail> // callback check
1 * 1  02 00 01 85 B4 00 FF FF 01 01 00 60 00 8E 00 <fail> // speed 60 to 89

[willisterman]

The difference between LUA and NFO is again that you need little to no programming experience to open it up, read and get a vague understanding, and begin to modify.

The idea being, the easier it is to modify, the more people that will do it, meaning the more addons the game has, increasing the popularity of the game.

[DaleStan]

If you are convinced that LUA can do what NFO does, and better, there are really only two options:
1) Write a program that takes your LUA scripts and converts it to NFO, then use the already-(mostly-)working NFO support in OTTD and be done.
2) Write a program that takes your LUA scripts file and converts it to some other, yet-to-be-specified easily computer-readable format. Then start from scratch implementing this format (which for NFO took many, many months and won't be significantly faster no matter how nicely you design your new one), fixing bugs, redoing the specs because you find things you need to do that can't be done, restart coding yet again, fixing the limitations of specs. Repeat as necessary.

But I seem to be repeating myself.

Note that option 3: "Update OpenTTD to read your LUA scripts directly." really resolves down to (1) or (2). Sprite selection, especially, must be very fast, because it must be done for every visible object[0] on every single tick, at the very least. Far more likely is every single object, period[1]. Direct text parsing is way too slow for this procedure, so you have to compile the LUA script to something more computer-friendly.

If you are not actively engaged in either of these two options, then discussion is really not going to be productive. Everyone who has ever read NFO knows that it is basically a write-only language. But everyone who has ever *written* NFO knows that it will require a great quantity of "more readable" to get them to give up even a little of its power. Any format that doesn't provide all of actions 0..4, 7..D, and 11, at the very least, isn't likely to meet with much acceptance.

[0] Object: Anything that has a defined 1/2/3 system in the NFO spec: vehicles, stations, canals, houses, industry tiles, and industries.
[1] This is because the RNG can be called at almost any time in sprite selection, and these calls must proceed in lock-step or multiplayer games will desync.

[Brianetta]

Code: Select all

1 * 1  02 00 01 81 0A 04 01 01 <sound> 00 00 <fail> // play sound every second event
1 * 1  02 00 01 81 10 00 FF 01 01 00 07 07 <fail> // sfx event check (16 tick)
1 * 1  02 00 01 85 0C 00 FF FF 01 01 00 33 00 33 00 <fail> // callback check
1 * 1  02 00 01 85 B4 00 FF FF 01 01 00 60 00 8E 00 <fail> // speed 60 to 89

Now that's not pretty. I've never programmed in LUA, but it looks similar enough to a bunch of languages I do know that I'd stand half a chance of modifying it without breaking it. NFO code, on the other hand, is a string of hex numbers, which can't be intuited. It must be learned. That code means nothing to me. If it wasn't commented, I wouldn't even be sure it was code. It has fewer meaningful symbols than assembler.

DaleStan's right. What we really need is a high level language that compiles to NFO (or directly to newgrf; I don't know the intricacies). I've never written a compiler, or even a full blown parser, and I have no NFO experience either, so this wouldn't be the best thing for me to tackle.

[Haukinger]

The problem is not to write a lua-function that beeps every 32 ticks when driving between 60 to 89 mph, every child could do that:

Wait, you mean I have to learn lua if I want to do anything that the xml spec author hasn't predicted I'll want to do? How come "every child" can write languages you're familiar with, but not nfo?

To be honest, that code where the first lines of lua I ever wrote. Believe it or not.

EDIT: correction - I should have written mod(a,b) instead of a%b

[Haukinger]

If you are convinced that LUA can do what NFO does, and better, there are really only two options:
1) Write a program that takes your LUA scripts and converts it to NFO, then use the already-(mostly-)working NFO support in OTTD and be done.
2) Write a program that takes your LUA scripts file and converts it to some other, yet-to-be-specified easily computer-readable format. Then start from scratch implementing this format (which for NFO took many, many months and won't be significantly faster no matter how nicely you design your new one), fixing bugs, redoing the specs because you find things you need to do that can't be done, restart coding yet again, fixing the limitations of specs. Repeat as necessary.

But I seem to be repeating myself.

Note that option 3: "Update OpenTTD to read your LUA scripts directly." really resolves down to (1) or (2). Sprite selection, especially, must be very fast, because it must be done for every visible object[0] on every single tick, at the very least. Far more likely is every single object, period[1]. Direct text parsing is way too slow for this procedure, so you have to compile the LUA script to something more computer-friendly.

If you are not actively engaged in either of these two options, then discussion is really not going to be productive. Everyone who has ever read NFO knows that it is basically a write-only language. But everyone who has ever *written* NFO knows that it will require a great quantity of "more readable" to get them to give up even a little of its power. Any format that doesn't provide all of actions 0..4, 7..D, and 11, at the very least, isn't likely to meet with much acceptance.

[0] Object: Anything that has a defined 1/2/3 system in the NFO spec: vehicles, stations, canals, houses, industry tiles, and industries.
[1] This is because the RNG can be called at almost any time in sprite selection, and these calls must proceed in lock-step or multiplayer games will desync.

If using lua, there's no need to translate to yet-another-format - the scripts are compiled to bytecode either offline using luac (the lua-compiler, shipped with lua) or online upon loading the script in ottd (that is, at startup). If you don't write megabytes of lua-script, I doubt there would be a significant speed difference between precompiled or plaintext scripts, execution times of the script are always the same.

To make myself understood - the benefit of lua is having a high-level language with c-like syntax and polymorphism (and dynamic binding, I think) that's ready to use. No need for writing interpreters, compilers or whatever, it's all there.
You're always free restrict certain functions to predefined ones with parameters specified directly in in the xml-file if it turns out that a lua-script is too slow there.

On the other hand, Lua is approximately 20 times slower than C. This seems to be a typical value for interpreted languages

How fast is nfo btw ? It's run on a virtual machine, too, isn't it ?

[BobDendry]

How fast is nfo btw ? It's run on a virtual machine, too, isn't it ?

I think we've found the winner to the "The Most Stupid Post of the Month" competition. You should keep your mouth shut on things you know nothing about.

[Haukinger]

Wait, you mean I have to learn lua if I want to do anything that the xml spec author hasn't predicted I'll want to do?

Yes. That's even better than it is now, because one has to learn nfo to do anything at all.

Everyone who has ever read NFO knows that it is basically a write-only language.

And as DaleStan truthfully points out, you can't learn nfo by looking at others nfo-code, in contrast to lua which has a somewhat clear syntax.