Transport Tycoon Forums

DaleStan wrote:

eis_os wrote:> 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.

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:

eis_os wrote: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.

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.
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

Oskar, there seems to be a bug with ship sets, see: http://www.tt-forums.net/viewtopic.php?f=24&t=38164

regards
Michael

Again a silly error that should be fixed now, please note that I am not be able to work on ttdpatch until around 2008/07/22. TTDPatch seem to compile still fine but I can't test the build.
-edit-
Note: Fixing such errors is quite easy, simply checking the sizes in grfprop.asm and the relevant wiki/old table definition comments. I wonder why it was found now and not earlier considering the time...

eis_os wrote:I wonder why it was found now and not earlier considering the time...

I don´t know. Possibly because the system has grown quite large meanwhile. Personally, when testing other things (CBs on buildings) I had already noticed that NewShipsXL was marked faulty in the .grf menu, but I didn´t had time to figure it out until that other bug was posted. Sorry.

please note that I am not be able to work on ttdpatch until around 2008/07/22.

You´re on vacancies? Happy bear hunting.

regards
Michael

Renovation/reconstruction

New cables, new plaster on one wall, glas faser wall paper ...

eis_os

The ship cargo problem is indeed fixed. thank you.

Next problem is to try and find out why Pikka's logging truck can also refit to mail and valuables.

Mervyn

Does it happen in the pre action 0 rewrite version too?

I have a logging truck?

eis_os wrote:Does it happen in the pre action 0 rewrite version too?

Yes.

PikkaBird wrote:I have a logging truck?

It seems to be part of your pb_hovs set.
While there could be a need for valuables to be carried, would that not be better done using the mail truck in the early days.

Mervyn