Re: American Bridge Replacement Set [WIP]
Posted: 01 Oct 2016 23:47
As do I.oftcrash wrote:I like the dark. It helps separate it from the dirt road.
The place to talk about Transport Tycoon
https://www.tt-forums.net/
As do I.oftcrash wrote:I like the dark. It helps separate it from the dirt road.
I like the light, as it does not separate too much from the dirt road... Well, I know an easy way out. Make it configurable.oftcrash wrote:I like the dark. It helps separate it from the dirt road.
That's easy to do actually. Whether it's worth it is another thing though. Its unlikely anyone would even notice such a change after playing for a long time, and it would mean all bridges would make the change even if they had just been built, somewhat defeating the premise of 'aging'.NekoMaster wrote:Too bad you couldn't have it so that the wood bridge turns dark over time like how American and TTRS roads change over time (after reloading a save or reloading your GRF in game)
I like the light one. As for all gravely road and bridges, some dirt will pass onto the bridge over time and paint the blanks the same color.Andrew350 wrote:Only thing I can't decide on is whether to use the light shading or the dark. I like both, the lighter one seems more 'cheerful', but the darker one stands out more against the road, so I'm leaning towards the dark. What do you think?
looking goodAndrew350 wrote:Rainy day today, decided to draw a stone arch rail bridge.
Minfingburg Transport, Sep 17th, 2079.png
Needs some work, but stone bridge is basically done, moving on to steel girder bridge.
nfo bridge code is just cruel. Did you see this one?Andrew350 wrote: "Let's see if I can figure out NFO..."
My tile grid tool might be able to help with that. Just place the grids in a square around the abutments, then zoom in and adjust to taste. You'll quickly see if its an alignment or a sprite issue.Andrew350 wrote: - It is not perfect. I've done a lot of QA but some imperfections remain, such as mismatched bridge heads when building a bridge of length 0. These problems are minor though and will be addressed later.
Definitely a sprite issue in this case, bridge heads were a little offset from each other when drawn. That could be a nifty tool though, I'll check it outwallyweb wrote:My tile grid tool might be able to help with that. Just place the grids in a square around the abutments, then zoom in and adjust to taste. You'll quickly see if its an alignment or a sprite issue.
I didn't see that, no, but I did have a good look through m4nfo when scouring the deep corners of the internet trying to figure out how to code bridges originally. To be honest, I didn't think m4nfo looked any easier I eventually decided it would be best to try learning plain NFO before trying to dive into anything else, at least that way I have a basic understanding of what I'm doing first (sort of).michael blunck wrote:nfo bridge code is just cruel. Did you see this one?Andrew350 wrote: "Let's see if I can figure out NFO..."
viewtopic.php?p=1203281#p1203281
As a proof of concept, I had recoded almost all of thgergo´s bridges from his set.
regards
Michael
Well,Andrew350 wrote: To be honest, I didn't think m4nfo looked any easier
Code: Select all
//this reserves some sprites into temp. params
5 * 9 0D 00 \D= \DR FE FF 08 18 00 //this "main" param is used to allocate all of the graphics via the following action 6
6 * 9 0D 01 \D+ 00 FF 01 00 00 00 //each sprite then gets its own param # to use in the final action 6's which determine placement
7 * 9 0D 02 \D+ 00 FF 02 00 00 00
8 * 9 0D 03 \D+ 00 FF 03 00 00 00
[...]
27 * 9 0D 16 \D+ 00 FF 16 00 00 00
28 * 9 0D 17 \D+ 00 FF 17 00 00 00
//this allocates the following graphics (realsprites) into the sprites which were reserved earlier (in the order they are defined below)
29 * 5 06 00 02 03 FF
//sprite number 00 00 (the first sprite below) now gets changed to whatever number the grm picked for the first of the reserved sprites, then each subsequent sprite
//is allocated that number + 1 (which corresponds to the number of the param above)
30 * 5 0A 01 18 00 00
//rail
31 sprites/wooden_trestle_rail.png 8bpp 1 1 42 30 -20 -3 normal //flat back x 00
32 sprites/wooden_trestle_rail.png 8bpp 48 1 42 30 -20 -3 normal //flat back y 01
[...]
53 sprites/wooden_trestle_road.png 8bpp 1 45 57 31 -27 -4 normal //back x 16
54 sprites/wooden_trestle_road.png 8bpp 63 45 57 31 -28 -4 normal //back y 17
Code: Select all
spriteblock(ALLOCATE,
set(
sprite(wooden_trestle_rail.png 1 1 42 30 -20 -3) //flat back x 00
sprite(wooden_trestle_rail.png 48 1 42 30 -20 -3) //flat back y 01
[...]
sprite(wooden_trestle_rail.png 1 45 57 31 -27 -4) //back x 16
sprite(wooden_trestle_rail.png 63 45 57 31 -28 -4) //back y 17
)
)
spriteset(0)
Code: Select all
//and finally these action 6's tell where to place each of the reserved sprites (organized by table layout for easier viewing)
//Ack, I had to split them up individually because there aren't enough hex ids to do all in one
55 * 14 06
0A 02 08 //rail x (part 0 should probably never have pillars set)
0B 02 18 //rail y
16 02 28 //road x
17 02 38 //road y
//mono x
//mono y
//mlev x
//mlev y
FF
//Wooden Bridge (00)
56 * 136 00 06 01 01 00 0D 00 01 //action 00 bridges(06), 01 property, 01 ID, ID 00, prop 0D, tableID 00, 01 tables
//table 00 - offset starts at 08, add 16 for each row
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 //rail X: Back&Floor, Front, Pillars, 0 //08, 0C, 10, 14
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 //rail Y: Back&Floor, Front, Pillars, 0 //18, 1C, 20, 24
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 //Road X: Back&Floor, Front, Pillars, 0 //28, 2C, 30, 34
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 //Road Y: Back&Floor, Front, Pillars, 0 //38, 3C, 40, 44...
09 11 00 00 F6 09 00 00 F8 09 00 00 00 00 00 00 //Mono X: Back&Floor, Front, Pillars, 0
08 11 00 00 F5 09 00 00 F7 09 00 00 00 00 00 00 //Mono Y: Back&Floor, Front, Pillars, 0
31 11 00 00 F6 09 00 00 F8 09 00 00 00 00 00 00 //Mlev X: Back&Floor, Front, Pillars, 0
30 11 00 00 F5 09 00 00 F7 09 00 00 00 00 00 00 //Mlev Y: Back&Floor, Front, Pillars, 0 //78, 7C, 80, 84
[...]
Code: Select all
define({table_0},{
segment(
railbridge(front(2, 3), back(0, 1), pillar(NONE, NONE))
roadbridge(front(14, 15), back(12, 13), pillar(NONE, NONE))
monobridge(front(0x9F6, 0x9F5), back(0x1109, 0x1108), pillar(0x9F8, 0x9F7))
mlevbridge(front(0x9F6, 0x9F5), back(0x1131, 0x1130), pillar(0x9F8, 0x9F7))
)}
)
Code: Select all
//table 01
58 * 136 00 06 01 01 00 0D 01 01
[...]
//table 02
60 * 136 00 06 01 01 00 0D 02 01
[...]
//table 03
62 * 136 00 06 01 01 00 0D 03 01
[...]
//table 04
64 * 136 00 06 01 01 00 0D 04 01
[...]
//table 05
66 * 136 00 06 01 01 00 0D 05 01
[...]
//table 06
68 * 136 00 06 01 01 00 0D 06 01
[...]
Code: Select all
layout(WOODEN,0,
table_0()
table_0()
table_0()
table_0()
table_0()
table_0()
table_0()
)
Having a good idea of the underlying plain nfo is indispensable, especially for the more advanced projects, be it for m4nfo or for any other abstraction layer.Andrew350 wrote: [...] it would be best to try learning plain NFO before trying to dive into anything else, at least that way I have a basic understanding