Replies-To: DaleStan, Haukinger, and willisterman
DaleStan wrote: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."
Haukinger wrote:*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.
Haukinger wrote:*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.
willisterman wrote: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.
willisterman wrote: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.
willisterman wrote: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.
willisterman wrote: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.