Every feature has some kind of spritetable, station, houses... The only difference here, is you can select a sprite in most recent action0 and select the table by action2, reference a sprite in TTD and the new concept of drawing a foreign sprite for the bridge surface. A reason I don't like the concept of to much specific route description for bridges... (only tram, rail, road and not monorail, maglev)DaleStan wrote:I thought we were trying to get rid of the sprite table.eis_os wrote:> 41 B direction of bridge
The direction is explicit set by the bridge sprite table
As the bounding boxes are much bigger with higher bridges a bridge title is a lot more influenced then a general title, thats my opinion about it.DaleStan wrote:You travel one direction on the map array until you hit a bridge head, then you travel the other direction until you find the other head. Why is this expensive? Or, at least, more expensive than the various 40, 41, 46, 47, 49 station variables? They have to go in all four directions and make quite a few more checks.eis_os wrote:TTDPatch has no concept of bridge length, it would be very very expensive to calculate a length.
And with future add ons to bridges like curves (not my idea directly) I really don't want to have that property, again people may have other options about it, I would generally return 0 for the length, and a grf should understand it, if it wishes to use the property... OTTD or Dalestan may add the necessary adjustments later to return the length.
-ediz-
My current plan:
Find an easy way to map ids to gameids but allowing up to 0x0F old bridge types, (If I remember right, it's the last OTTD bridge)
Enable Action 0 feature bridge prop 0 to set the failback bridge type and select a sprite, otherwise use the general overwrite method
-> if enabled, disable action0 prop 0x0D
-> use grf id to gameid mapping
Write a table drawing and parser modul with the new table format
