Transport Tycoon Forums

Hi

I have rework the internal Action 0 property system for TTDPatch and plan to commit the changes in the TTDPatch trunk branch the following week.

What does this mean as grf author / player ?

Revisions after around r1893 may fail with sprite errors because the new internal system has an unknown bug or the old parser simply ignored something in your grf.
The first test with DBSetXL and stations didn't show any problems.
You may want to test an old nightly http://nightly.ttdpatch.net/ then.
Bridge GRFs may fail. (see below for more)

What changes are done? Why changes in newgrfs core algorithm are done?

Action0 in it's current system manages internal 3 separate ways to set properties for a id. Currently we lose 8 properties for any non vehicle.
Neither is the current system flexible enough to replace these with custom internal function handlers to keep grf compatibility when the internal may change in the future. New features may be more logical structured
Old features are mostly impossible to extend id wise.
Lot of special code handling but less memory usage by definition.

New System:
Uses more memory to define the properties, but is a lot easier to maintain and can be extended, a lot code paths are removed and replaced by table lookups.
As the bridge Action0 was quite a hack, it couldn't be converted.
The result was a rewrite of the current bridge functions. While I haven't managed to fix the gui and add new stuff. The internal system now allows theoretical new 100 bridge ids.
Therefor some new stuff needs to be introduced property wise. (New icon handling, text handling, fail back handling) so the bridge grfs may fail... (As a grf author may want to add your wishes for bridge properties here)

Note: If you have currently errors with sprites with r1893, or sprite errors in beta it's not my fault.

There are only few extra properties that I can think of that bridges could use - custom icon is definitely a must even if you'd keep just the current number of bridges. It may be handy to have the ability to define a bitmask of track types the bridge will be available for (avoid maglev on wooden bridge, for example). It would also be handy to have the ability to define layout tables for different track types independently(so that you could modify only road bridges, for example).

This is problably out of the scope of what you're doing, but here it goes anyway - The really neat features would involve having a VA2 support for either setting properties (speed/availability/length limits/etc. different for different tracks), or for picking of layouts to draw (with inputs such as position from beginning of the bridge, height above ground, length of bridge, info about the map tile). If that was possible, it may be handy to have the ability to define more layouts per bridge, maybe even have ability to track date built.

Currently the bridge heads are common for all climates, so you can't for example have part that's covered with grass, because it would look odd in the middle of desert or snow. This would be solved by VA2 support mentioned above, or possibly there could be an extra layout for bridgeheads on snow.

Would signals onm bridges be a remote possibility?

A bridge id can only be edited by one GRF at a time, (we can't resolve TextIDs across grfs without storing each textid with grfid). Actually the layout of a bridge is quite fixed, the layout functions haven't been changed.

Currently for climate different sprites you have to switch via Action7, thats how TTD does it internal too...

I don't want to switch to Action321 now, as this would mean all current bridge/roadset grfs are invalid and would be again void for newroutes. *
The new action0 system depend on the rewritten bridge code.

L8 is planed for storing the date, but because Action321 isn't used, it would have very limited usage...

-edit-
Patgreg: No - thats quite impossible because of a lot of facts.

Please only grf authors or at least people who have an idea how O)TTD(Patch works (GRF, Savegame or internal wise)

-edit 2-
* A pre-newroutes possibility would be to add some dummy newroutes lookups that always result in Action5 based fixed sprites, GRF authors of road and rail pieces could then add then necessary 2*4 route type sprites... And bridge authors would add the necessary spriteid for calling these in an new layout system. Again a bridge shouldn't know the track style on top...

eis_os wrote:Currently for climate different sprites you have to switch via Action7, thats how TTD does it internal too...

Indeed, however that does not solve the issue of landscapes with two different ground types (which now with support for snow in temperate means all). See attached picture - that's something action 7 can't help you with (ignore the wrong shade of grass).

EDIT: I suppose that without A123 and with respect to changes being done for newroutes, there really isn't anything useful I can think of (that would be worth it). Some provisional support that may allow people to start preparing things for newroutes would be handy tho.

TTD should draw the ground, not the bridge sprite... (so coasts can be seen) But after all, only with action321 this can be done
A other solution is to use a partly transparent dithered sprite...

True, I completely forgot about coasts. Too bad - in that case i'm content with what's there now, since anything that I can think of are just limited workarounds for lack of A123.

Its nice to see, finally bridges will have proper action 0-1-2-3 support in the near future isnt it? Altough this is a nice development, even it does not offer too much yet, I`m looking forward to this. Only this that disappoint me, these new changes break the compatibility with older bridgesets, which made with the older hackish method, including mine, wont work with TTDpatch anymore. Would it possible to keep the old bridge action while developing this new?

eis_os wrote:As a grf author may want to add your wishes for bridge properties here

-defineble sprite usage for every length : The ability to define the sprites from the north corner to the south per tile. Same thing should be used for pillars. I think a good solution would be good to introduce bridgetiles, then construct the final bridge with those predefined tiles.
-pillars should differ in length! : With the current system the pillars isnt very nice, pillars are a 8 tile long samples, tall bridges looks ugy with them. It would be nice to the pillars look different per height. Also, the front pillar, and the back pillar should be defined seperetly.
Its just my 2 cents...

eis_os wrote:(As a grf author may want to add your wishes for bridge properties here)

Be careful what you wish for...

As I said, the action0 rewrite already needs an change in Action0 for bridges, so it may be easier to already write code that may be reused later (or already allows later to add a requested featue) As example, while the bridge icon spriteids can't be changed yet, the code already restores them properly. Ohh, and the new code should be robust to TTD Alter changed exe files. (Bridge speeds are located now completely different)

Thought I might post a few bugs I've been experiencing since r1896.

• Errors:
• Generating a new random terrain game hangs,
• Some bridges have 0 mph speed limits or broken costs,
• Bridges (newgrf and stock) use the wrong graphics.

~ Lakie

At least the bridge problems should be fixed in r1898
-edit-
In r1900 ...
-edit-
or in r1901 when a bridge grf may have changed the introduction years

I found another bug since r1896: Pikka's Aviators Aircraft set doesn't work. See attached picture:

Hmm, I found an error in the property size of capacity , should be fixed in r1905..

Using r1902, the US Set (trains) doesn't build its vehicle list correctly: 1921 is blank, 1925 has the newer diesel and electric trains, steam is hardly seen. Also, the planes vehicle list (not affected by any grf addon) shows all the jumbo jets and future aircraft, even in 1921.

Thanks for the report, please try r1906.

If I can propose a few change/additions in properies, please consider
Climate Availability (see minime post)
Life Time usability

For now, those are the only two properties i'm about to add to the code.
Of course, available callbacks, but that is really usefull while action 1/2/3 are not done

belugas wrote:Climate Availability (see minime post)

Wouldn't it be better to guard the controlling actions with a climate-dependent 7, instead of consuming a bridge slot for a bridge that's only available in not-this-climate?

Can you explain me the details how you want to add "Life Time usability" ?

@Dalestan : True that currently, we do not have much room to navigate, with only 11/13 slots. On OpenTTD side, the numbers will grow to quite a few more slots (although the exact number is not decided yet). So, I was thinking of a convenient way for bridges creators to dispatch their creations by setting simply a property, much like what happens with house's property "Building availability mask (13)".

@eis_os : First, after expiration of the said time life, no bridges of that type will be allowed to be built. Technologically wise, it makes sens. Second, for an already built bridge of that type, when life time expires, that bridge is going to be prone to collapsing. In fact, it's linked to the disaster system... This, of course, is a feature i've already started to code. The default would be to determine, my current one is 0, as eternal bridge, kinda.

Now, while I was typing, I remembered something else I wanted to suggest:
Maximum number of appearance. Tis comes from the fact that a bridge can be an architectural structure that has no counterpart or copy anywhere in the world, like the Golden Gate and others alike. So, in order to avoid over population of the same bridge everywhere on the map, such a property would allow to have a more evenly spread use of more diversity of bridges. and not just the fastest anymore... This is, too, something i have started coding.