Planed changes in GRF System may influence coding/sprite err

[eis_os]

Actually TTDPatch has currently up to 254 slots, but they aren't usable, nor documented.
The ids should be allocated as I said already to you Belugas, to be exact I want the TTD bridges be accessible as before. (So not all sets are directly void.)

Hmm, I could understand a life span of a bridge, or in what time span you can build bridge, but connecting both doesn't seem desirable.
Otherwise you will get this statement: "Why is this silly bridge collapsing after 5 years?"

It's normal to restore bridges so I don't see how you want to allow players to keep bridges?
"Maximum number of appearance.", actually how you are able to extend a bridge then? This needs some regional component then.

What happens if all bridges are already build?

[minime]

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.

Good point, although ideally this would be something you would be able to control using a callback, somewhat along the line of CB17.

A property determining the probability of appearance when built by a town could be handy. The ability to control what bridge gets built by town by a callback would be ideal (like CB18?).

Life Time usability

Should that not be two values, as is with vehicles? It would not make sense if a year-old wooden bridge suddenly collapsed only because that type of bridge is no longer being built. Similarly, lifetime of a design does not need to reflect lifetime of an individual structure.

[eis_os]

To be exact http://svn.ttdpatch.net/trac/browser/tr ... ef.inc#L18 but well you get the point, it's simple a constant in TTDPatch that can be up to 255.


I would say:
Long format of last year of availability.
Lifespan (usually lifespan) <- how a player can extend it, how he know the bridge is old? With transparent bridges on, you won't see much of graphic degradation
Maximum percentage of appearance. <- still I don't like the concept as said...
Callback deciding if a bridge can be build, should get sizes, climate, nearby town pop ( You don't want to have the Golden Gate bridge in a tiny town? )


Towns will build bridges with infinity lifespan...

[minime]

Lifespan (usually lifespan) <- how a player can extend it, how he know the bridge is old? With transparent bridges on, you won't see much of graphic degradation

The age/build date should be displayed in the info window. Player should be notified by a message, when a bridge is old, as with vehicles. Before A1/2/3 are available, old bridges could have a sign displayed above them to show their state.

Callback deciding if a bridge can be build, should get sizes, climate, nearby town pop

Distance from nearest town center, possibly? Flag whether it's the player or a town building the bridge? Count of how many instances of the bridge are in a town/whole map?

[belugas]

To be exact http://svn.ttdpatch.net/trac/browser/tr ... ef.inc#L18 but well you get the point, it's simple a constant in TTDPatch that can be up to 255.

Understood.

I would say:
Long format of last year of availability.
Lifespan (usually lifespan) <- how a player can extend it, how he know the bridge is old? With transparent bridges on, you won't see much of graphic degradation
Maximum percentage of appearance. <- still I don't like the concept as said...
Callback deciding if a bridge can be build, should get sizes, climate, nearby town pop ( You don't want to have the Golden Gate bridge in a tiny town? )

Sounds fair enough. Although, if callbacks are going to be implemented, i guess that the maximum appearance wold not be needed as such. As for how the bridge will change (if ever it does) his look after lifespan, that is something else. The feature is not coded far enough as to actually propose something, therefor, it's still available to discuss. But one thing is sure, the collapsing I mentioned earlier is going to take place as part of the degradation. A portion of the bridge will OR cease to exists, OR fall down to ground level. The actual behaviour could eventually be a property or a callback's result, not sure exactly yet.

Towns will build bridges with infinity lifespan...

Now that is interesting... Could certain types of bridge could be available only for towns? Or not available for town at all? It's quite easy to address, and may be an interesting feature

[LordAzamath]

Could certain types of bridge could be available only for towns?

No.. Think of all the threads in Problems section 'I cant build the same bridge as town'..
Do you really want to answer those threads?

[belugas]

That would only be some more false bugs due to ignorance...
Let say we are a bit accustomed to the feeling...
If that was an argument to not go any further, let say the game will be very boring otherwise.

[Mickeye]

And another error since r1896, this time with USSet (same with 0.87.3 or 0.87.4d version). The game crash when trying to buy rail car, or passenger vagon and engine in same depot. In r1895 everything works fine. Ttdpatch.cfg was default, in newgrfw.cfg was only ttdpbasew.grf and ussetw.grf.

[eis_os]

What version did you actually test? r1907 or a later version? If it's later please test with r1907 too, thanks...

[Mickeye]

It was in r1909 (see the CRASH000.TXT) and in r1907 everything works good...

[eis_os]

1908/1909 are changes by DaleStan... Not related to action code directly...

[DaleStan]

If it crashes instead of opening a vehicle window, that's my fault. Don't blame eis_os for that.

But I think r1913 should work properly.

[Mickeye]

I didn't blamed anybody , I just though it has something to do with r1896, but it was r1908(9). Anyway, thanks for quick replies and patches, in both cases.

[michael blunck]

[on bridge features]

Other interesting features for bridges inside a 0123 framework would be

- height about ground
- landscape class of tile under bridge (i.e., road, rail, water, ...)
- awareness of snow

regards
Michael

[PikkaBird]

Other interesting features for bridges inside a 0123 framework would be

Here's the variables that I think would be useful: http://pikkabird.livejournal.com/14565.html - thoughts or additions?

[eis_os]

It's not easy to follow cross blogs, please could we stay on the forums, if it's suitable we could create a wiki page for it.

> 40 W Year built (long format)

From my standpoint I would really like an age property, what do you want to do with the date?

> 41 B direction of bridge
The direction is explicit set by the bridge sprite table

> 42 B
Bridge head information
Again the system would be split by bridge middle parts and ramps,
I can understand an advanced property for custombridgeheads...

> 43 B Type of bridge (rail electrified monorail maglev road)
I would say rail, road, tram
You shouldn't depend on the route information.

>44 B Tt Land use under bridge
Sounds ok.

> 45 D Hhbbaall, Length, height, position
Actually not possible, sorry, the only values to calculate are:
Groundheight, TopHeight ( for pillar drawing current height)
TTDPatch has no concept of bridge length, it would be very very expensive to calculate a length. (specially bridges have to redrawn a lot more often then stations)

> 46 B
> Terrain slope, as for ss in industry tile var 60
For the lowest pillar call, yes, otherwise flat.

> 47 B Owner/Builder, as for industry var A7
Ok

>48 B Colour scheme (of owner), as for Cc in vehicle var 43
Should be doable

> 49 B
> A random byte.
Not sure how to do it, canals simply return 0 for bridges...

[PikkaBird]

> 40 W Year built (long format)
From my standpoint I would really like an age property, what do you want to do with the date?

I suppose either is easily calculable from the other. I figured that people were more likely to want different-looking bridges built in different periods than to make bridges change as they age.

As for the other stuff, I guess was hoping for a more freeform, adjustable way of designing bridges than the default 5-tile-repeating-section - surely those computationally-expenisve values could be cached? It's not like bridges move around or can be modified.

[Rubidium]

>> 42 B Bridge head information
>Again the system would be split by bridge middle parts and ramps,
>I can understand an advanced property for custombridgeheads...
In OpenTTD there are technically no middle parts. The only thing that is stored about a bridge middle part is the direction of the bridge.

>>44 B Tt Land use under bridge
>Sounds ok.
In OpenTTD this can be a lot more than in TTDP; in OpenTTD one can have tram, road and rail on the same tile under the bridge.

>> 49 B A random byte.
>Not sure how to do it, canals simply return 0 for bridges...
As stated before, OpenTTD only stores data for the bridgeheads, so there can only be a random byte for the bridgeheads and not the middle parts.

[eis_os]

>> 42 B Bridge head information
>Again the system would be split by bridge middle parts and ramps,
>I can understand an advanced property for custombridgeheads...
In OpenTTD there are technically no middle parts. The only thing that is stored about a bridge middle part is the direction of the bridge.

CalcBridgePiece ?

>>44 B Tt Land use under bridge
>Sounds ok.
In OpenTTD this can be a lot more than in TTDP; in OpenTTD one can have tram, road and rail on the same tile under the bridge.

We can have a plain tile, a general route, a water title, a structure

>> 49 B A random byte.
>Not sure how to do it, canals simply return 0 for bridges...
As stated before, OpenTTD only stores data for the bridgeheads, so there can only be a random byte for the bridgeheads and not the middle parts.

TTDPatch doesn't even have the concept, and for custombridgeheads we really have no room.
If there is someday a different storage system bridge could be theoretical build on anything,
if I am really be forced to need that amount of storage, I see only one way, the newmaparray system

-edit-

It would be nice to have full tile size pillars too, (on non usage titles), maybe someone has an idea?

[DaleStan]

> 40 W Year built (long format)
From my standpoint I would really like an age property, what do you want to do with the date?

Calculate the age of the bridge, I assume.

> 41 B direction of bridge
The direction is explicit set by the bridge sprite table

I thought we were trying to get rid of the sprite table.

TTDPatch has no concept of bridge length, it would be very very expensive to calculate a length.

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.

(specially bridges have to redrawn a lot more often then stations)

Why? Granted, they have to be redrawn every time a vehicle moves or is otherwise redrawn in their vicinity, but why would this happen more often for bridges than for stations? Then there's station animation. Bridges aren't generally animated.

> 47 B Owner/Builder, as for industry var A7
Ok

>48 B Colour scheme (of owner), as for Cc in vehicle var 43
Should be doable

Should these be merged into one variable?

As stated before, OpenTTD only stores data for the bridgeheads, so there can only be a random byte for the bridgeheads and not the middle parts.

I imagine that desire here is only to have a single byte for the entire bridge, not randomness for each bridge tile.