Modular Locomotive sheds [MLSS 0.5.2]

[supermop]

So right now I am struggling to understand the documentation for actions 02 and 03 for the station tiles. The stuff I'm reading seems to suggest that action 02 deals with graphics associated with cargo, which I do not need, but also states repeatedly not to skip action 02. The description of action 03 also seems hard for me to parse without thinking in terms or certain cargo types. I'm not really sure that the Station tools in GRFMaker make much sense to me either. I'm not sure what I use to designate certain sprites to be drawn as the background of the station either.

As I am not making much progress, I am going to head to bed, and hopefully approach it afresh tomorrow. Thanks to everyone for their help so far!

Best,

[Freak_NL]

I feel your pain. It took me a few hours to get my first NFO working. All the documentation is geared towards trains.

Basically, this seems to work after the sprites and Action0:

Code: Select all

02 04 00 00 01 00 00
03 04 01 ID_USED_IN_ACTION0 00 00 00

Of course, you need to put 1 * 10 or something in front of them if you let NFORenum check your NFO.

[Jim Starluck]

More sprites. So far I have three roof styles. I would like to add more, and create a depot that is subtly, yet readily distinguished from the station sheds, so you don't open the station window 20 times while trying to build trains. I feel the plain corugated walls lets the pieces blend easily, but I would like to add some pieces with more detail. A CC stripe along the side, lights next to the doors etc. Doors that open on the station pieces, like on the ISR train sheds, would also be nice. I also want to eventually add other shed styles for different railtypes with corresponding depots, potentially one for every slot in NuTracks.

Here's an idea for a different depot/station style... have one based on the default depot--something kinda like the Bigger Train Depot--as its brick-building art style is far more suited to the steam locomotive era than corrugated steel. Not that many station grfs include older-style art suitable for the steam era, so it would be nice to have something that would fit in with that time period.

It would be especially nifty if you had a subset of depot-station tiles that would let a player build a mockup roundhouse, so that it looks like a 3x3--or maybe even 5x5--building but only 1 tile on one side of it is an actual depot. If you could pull it off, well...

[supermop]

Freak_NL: Thanks! To be honest, I think that your Subway Grf and this one have A LOT in common, spiritually. I am excited to see both make it to a wide release on Bananas. Let me know if you want any drawing help for your cover tiles.

As for my set, lets say I want at least two different categories for now, Flat roof and box roof, and I want them to be selectable in the station GUI much as one chooses "Raw Materials" or "Processed Products" in ISR. Would using different actions 2 and 3 lets me create these categories? or does that come later?

Jim Starluck: It would certainly be possible to create an older style, pitched roof graphic for the station tiles. The problem is, that you would have to change NewGrfs when you wanted to enter the modern age, as you cannot currently select various depot styles in game. If one is using NuTracks, there are about 14 different railtypes, so potentially 14 styles of depot (although the track planning depot wll not do you A LOT of good). I am interested in taking advantage of this in the future, but there are several obstacles:

Complexity. This set introduces A LOT of wierd tiles, which are not only hard for me to code (because I have no idea what I am doing), but also may confuse people who just download it off bananas without reading about it first. I want people to get the hang of building sheds first.

Geometry: Assuming the steam era depot will look much like the original depot, it will have a pitched roof, and will only line up with other tiles with the same track direction. This could cause problems for the special overlays, if it partially occludes a roof with the opposite orientation. There are some changes I can make to the sprites to make this not as bad, but it will still look wierd and cost the user some flexibility. The advantage of the boring flat roofs is that your "yard" inside the shed can contain track perpendicular to the long axis of the building. The round house will be possible, but even less functional, and tricky to build in game, so I do not yet want to promise it yet.

Priority: I would love to diversify the set, but the first priority is to get what I have working and available to people. Adding more depot types will likely be done via my regular workflow of model, render, photoshop to create both 8bpp and 32bpp. As such I will fit it in with the other project I am working on.

Thanks for your help and feedback so far!

Best,

[Kogut]

And it may be nice to have it as standalone, not bounded to NuTracks.
I think it is better to have all Modular Locomotive sheds tiles in one category - lets say "Modular Locomotive sheds".

[supermop]

That seems like a good idea for now, but how do I make that one category to begin with?

[Kogut]

As for my set, lets say I want at least two different categories for now, Flat roof and box roof, and I want them to be selectable in the station GUI much as one chooses "Raw Materials" or "Processed Products" in ISR.

I think it is better to have all Modular Locomotive sheds tiles in one category - lets say "Modular Locomotive sheds" instead of putting it inside IRS.

[supermop]

I think it is better to have all Modular Locomotive sheds tiles in one category - lets say "Modular Locomotive sheds" instead of putting it inside IRS.

I think there has been a misunderstanding here. It was never my intention to make this set part of ISR (not that I have anthying like the authority to do so anyway), I was just using the categories within ISR as examples. Whether all of my shed tiles end up in one category, or in two categories based on type, I still need to figure out what action makes that category, so that the user may select the modular shed category from within his station GUI. As I understand it so far, I need to group two sprites together for each tile, front+roof and background. Then I need to group those groups together to make the category? I am assuming that the action 01 is for the entire group of sprites in the GRF, and that Actions 2 and 3 create subgroups, but the documentation suggests that those actions are for cargo waiting sprites... Maybe someone who has put together a station set can give me a tip about grouping the sprites. I am currently looking through the Japanese Station set to see how it is organized, but it is a little overwhelming so far.

Thanks, and hopefully I can pull something small together tonight.

Best,

[DJ Nekkid]

i assume you are looking at DECODED stuff. That is nearly impossible to read, even for seasoned people. Ask dandan (i think) for the japanese stations, and for a commented example. Another alternative is to ask XeriusTC (ish) for some of his code. I might be wrong now, and kinda drunk after a gig (:)), but check the "devzone" (dev.openttdcoop.org) and look for the dutch stations, iirc are the code for that set there. Either that or thoose red*star stations. Anyway, commented exampels are your friend!

[supermop]

Oh man, I wish I had seen this earlier. I've just been looking at the .nfo I got out of the station set with grfcodec, and trying to guess whats going on. I have been annotating my own .nfo as I go along though, just to keep track of things. I still dont understand A LOT, but I think crossreferencing this with the wiki will help me greatly.

Thanks!

Anyway, if I am lucky, I might be able to post something tonight.

Best,

[frosch]

If you still want to explore encoded grfs, which you have no commented source of, you might want to try Grf2Html:
http://www.tt-forums.net/viewtopic.php?f=68&t=34279

But it might also help to explore commented grfs.

[Freak_NL]

These two commented NFO's were helpful to me thus far:

http://trac.openttdcoop.org/browser/grf ... h_set.hnfo
http://dev.openttdcoop.org/projects/mod ... forms.hnfo

These sets split up their NFO over multiple files, so the Action8 may be in one file, and a set of platforms in aother, but they are fairly well documented. They also use a Makefile to replace all the ALL_CAPS_NAMES with their hex values, so ID_BASIC_PLATFORM becomes 00 in the resulting NFO after processing. This system is recommendable when your NFO becomes larger, but not necessary for now.

[supermop]

Thanks for everyone's help so far! I have put together an .nfo file that seems like it should work as I want. I used an action 00 for the sprite layout pretty much identical to that used by dutch stations set (thanks to DJ Nekkid for pointing me there, and to those who created it for providing a commented example!). It seemed simple enough, and I use another action 00 for each shed tile. I ran into this problem when trying to encode, however: Grfcodec gives this error "Error: Encountered invalid character looking for literal bite. While reading sprite:41"

Here is my sprite 41:

Code: Select all

  41 * 109 00 04 02 01 ID_FLAT_BASIC                       // Action 00: Change 2 properties for basic flatroof shed
            08 CLASS_NORMAL                                 // Place in Normal Category
            09 04                                           // Define Layout for 4 tiles (not sure why this cannot be 2...)
          
          F4 03 00 00  00 00 00 08 10 0d  2D 04 00 00  00 00 00 10 10 24  2E 04 00 00  80 
          F3 03 00 00  00 00 00 10 08 0d  2F 04 00 00  00 00 00 05 10 24  30 04 00 00  80
          F4 03 00 00  00 00 00 08 10 0d  2D 04 00 00  00 00 00 10 10 24  2E 04 00 00  80 
          F3 03 00 00  00 00 00 10 08 0d  2F 04 00 00  00 00 00 05 10 24  30 04 00 00  80

Looking at it, I dont immediately see what could be causing the problem. ID_FLAT_BASIC is not written in hex, but the equivalent id in the set I looked at also had alphanumeric characters here. I dont think that my annotations are the problem, because I have similar ones earlier in the .nfo that did not cause any problems. I am assuming that what ever is the problem here will also show up in all of my other action 00 sprites once Grfcodec is able to get to them, because I created them by copy and pasting this one.

Can anyone see an obvious mistake that I am being oblivious to?

Thanks, and Best,

[DJ Nekkid]

i have exactly 0 experience in station coding, so i cannot help you with your problem, but its good to see that you are useing the makefile-system. It really helps to do stuff easy and simple and abit more readable

[Freak_NL]

You have to replace those ID_SOMETHINGS with hex numbers (01 and such). The Dutch station set does this too, but uses a Makefile to pre-process the NFO, automating the process.

Here's my extremely simple NFO for a single tile station:

Code: Select all

// Automatically generated by GRFCODEC. Do not modify!
// (Info version 7)
// Format: spritenum pcxfile xpos ypos compression ysize xsize xrel yrel
1 * 10  00 00 00 00
1 * 10  08 07 "FN01" // GRF_ID
        "Subway park stations" 00 // Name
        "Subway stations in the form of parks above ground" 0D // Description
        "by Freak_NL" 00 // Author
1 * 10   01 04 01 04
1 sprites/platforms.pcx   1   7  09 23 42  -9  -3        // ID 42D platform NE
1 sprites/platforms.pcx  113  38 09 31 64 -31  -1        // ID 42E roof
1 sprites/platforms.pcx  91   7  09 23 42 -31  -3        // ID 42F platform NW
1 sprites/platforms.pcx  46   38 09 31 64 -31  -1        // ID 430 roof
1 * 10  00 04 02 01 01 // Changing 2 properties for 1 station
        08 "PRKP" // Put the station in "Park platforms"
        09 02 // Tile layout, 2 different tiles
        // tiletype   bounding box        sprite id     bounding box        sprite id
        F4 03 00 00   00 00 00 10 05 03   2F 04 00 00   00 00 07 10 10 01   30 04 00 00   80
        F3 03 00 00   00 00 00 05 10 03   2D 04 00 00   00 00 07 10 10 01   2E 04 00 00   80
1 * 10  02 04 00 00 01 00 00
1 * 10  03 04 01 01 00 00 00
1 * 10  04 48 FF 01 01 C5 "Park platform" 00
1 * 10  04 48 FF 01 01 C4 "Subway park platforms" 00

It doesn't look very readable without those ID_SOMETHINGS, so switching to a Makefile in due time is advisable (but overkill for now if you've never used automake and gcc and such before).

This is the file Dutch stations uses to have automake (the Makefile processor) replace the ID_SOMETHINGS with hex numbers:

http://trac.openttdcoop.org/browser/grf ... s/ids.hnfo

And this is their Makefile:

http://trac.openttdcoop.org/browser/grf ... s/Makefile

This is the step that replaces those IDS:

Code: Select all

# GCC Preprocess the HNFO into the Windows NFO copy     
$(NAME)w.pnfo :
	        @echo "GCC Preprocessing HNFO:"
	        $(CC) $(PREPROCESS) $(NAME).hnfo > $(NAME)w.nfo
	        @echo

[supermop]

Hello,

I was pretty busy over the weekend, but found time this evening to try fixing the problems with my action 04s. Thanks to Freak_NL for his sample code. As far as I can tell, there are no actions missing, but playing with the grf, my category, Modular Station Sheds, still will not show up in in my station gui. At this point I am at a complete loss as to how to get the category to appear in-game. If anyone can spot some obvious mistakes that I am making, please let me know.

Thanks for everyone's patience with me so far. I really want to get this out so people can start using it, before they lose interest.

Best,

[Freak_NL]

NFORenum starts complaining about it expecting 108 real sprites (36 * 3), so something is wrong with the way you define sets and views with that Action1. I haven't figured that bit out just yet though. Any NFO gurus around?

You could try to define only one tile with its 3 sprites to see if you can get that working, and go from there. Could you post the PCX too?

[DJ Nekkid]

Code: Select all

    2 * 4   01 04                                         // Action 01 for Stations (feature 04)
            24 03                                         //  36 sets of views, 3 views per entry (ground tile, background, foreground)

instead try:

Code: Select all

    2 * 4   01 04                                         // Action 01 for Stations (feature 04)
          \b12 03                                       //  12 entrys with 3 views per entry (ground tile, background, foreground)

and btw;
for easier readability/thinking for yourself, where you dont want to convert decimal-hex everywhere, you can use \b<0-255>, \w<0-65565> or \d<0-roughly 4 billion>. Or if you know the hex number, and isnt entierly into the "little endian" thingy, you can \wxFF00 instead of 00 FF. (and its \dx equivilent). This does atleast make more sense to me

[supermop]

DJ Nekkid: I will try to implement your suggestion. I actually only need 20 real sprites for all of the flat-roof shed pieces (18 foregrounds, and two backgrounds, which I am assuming can be reused). I am not going to include the other roof styles until I can be sure I can get something basic to work. If I switch to 12 entries instead of 20 or 36, will I then need to add other action 01s for the other sprites? should I just use a new action 01 for each action 00, and define only 4 sprites per action 01?

Freak_NL: I am not using NFORenum, so I must have missed that problem. Maybe it will fix it self when I change my action 01 to follow DJ Nekkid's suggestion. I will attach my .pcx to this post.

Thanks to both of you guys, and everyone else who is being patient and helpfull with my project.

[zero.eight]

Good to see other people working on stations. This looks like a useful concept. Unfortunately, the wiki is confusing in several places, but I have managed to fudge together some working code. I can't guarantee that any of the following is "correct"; rather it has worked when I have tried to create stations.

Layouts - Action 0 Feature 04 Property 09

This controls what sprites are displayed, where they are displayed, and in what order. The property is variable sized, and contains the data for all 8 possible station tile types. If this property is set, the num-ent in the corresponding action 1 need not be equal to 12 (hex), it can in fact be any number, and any number of sprites can be displayed in any order.

I believe that this description refers to the default station layout, which has 4 possible tiles types in 2 directions (plain platform; platform with building; platform with roof left side; platform with roof right side), making 8 possible default tile types. The 0x12 figure comes from the fact that there are 18 (decimal) sprites required to make these 8 default tile types (see sprites 1069 - 1086) in ogfx1_base). This is helpful if you want to make a station using the default layout, but that is not the case here. You should be able to define only 2 layouts. (one for SW -> NE, one for SE -> NW). I have managed to get non-track tiles into OpenTTD with only 2 defined layouts. At the very least, this will allow you to place 1x1 layouts. More complicated layouts can be controlled using Variational Action 2 Variable 40/41/46/47/49, such as 2x1, 3x3 etc, but those aren't needed here.

Real Sprites and Sets - Action 1/2/3

I'm not sure why you need 3 (non-groundsprite) sprites per tile. I think it should just be a case of foreground + background (+ groundsprite, whichyou are taking from the existing graphics so does not need to be Action 1ed), so 2 sprites per set * 2 views (SW -> NE , SE -> NW) = 4 sprites per set. If you have 20 tiles, you need 20 Action 2 sets, and therefore 80 sprites in the Action 1 block. Half of these sprites will be the background sprites that do not change, so for each set you can just reference the same two sprites for the background and then the two different background sprites. The wiki seems to suggest that you can draw any sprite defined in an Action 01 block, which is true, but it doesn't work as you may think.

Just to summarise, an Action 1 defines (a) set(s) of sprites and Action 2s give a setID (confusingly called a <cid> in some places on the wiki) to a subset of sprites within that Action 1. Each subset in this Action has the same number of elements (each set has the same number of sprites). To link graphics from a specific Action 2 setID to a station tile, an Action 3 takes the ID of the station defined in property 08 of an Action 0 Feature 07 and chooses which setID to use. For stations, the sprite number defined in Action 0 Property 09 is indexed at 0x42D, but is also relative to the setID to which it is linked via an Action 3. Your code assumes that all sprite numbers are simply counted from 0x42D. While this will choose a sprite, it will probably not be the one that you want. Instead, for each Action 2 set, all sprites are indexed at 0x42D, so if you want to draw the first sprite in any Action 2 set, use sprite number 0x42D in the Action 00 Property 09. If you want the fourth sprite, use sprite number 0x430 (This assumes that the set is has four sprites. If it has fewer, the fourth sprite will be taken from the next set. This may be useful, but it is just confusing). If you define your sprites in an Action 1 block as

Code: Select all

// Tile 1
<backgroundsprite1>         // ID 0x42D
<backgroundsprite2>         // ID 0x42E
<Tile1Foregroundsprite1>         // ID 0x42F
<Tile1foregroundsprite2>         // ID 0x430
// Tile 2
<backgroundsprite1>         // ID 0x42D 
<backgroundsprite2>         // ID 0x42E 
<Tile1Foregroundsprite1>         // ID 0x42F
<Tile2Foregroundsprite2>         // ID 0x430
// Tile 3
etc

All Action 0 Prop 09 defintions should use

Code: Select all

<grndspriteNumber> 
<bckgrndsprite1Offsets + bckgrndsprite1Sizes> 2D 04 00 00 
<foregrndsprite1Offsets + foregrndsprite1Sizes> 2F 04 00 00 
80
<grndspriteNumber> 
<bckgrndsprite2Offsets + bckgrndsprite2Sizes> 2E 04 00 00 
<foregrndsprite2Offsets + foregrndsprite2Sizes> 30 04 00 00 
80

assuming the background is drawn first (it depends on the bounding boxes apparently - I haven't tried).

Additionally, you are only using setID 0x00 for Action 2 IDs, which is why Renum complains that "ID 01 has not been defined" in your Action 3s. Renum probably won't complain about defining only one ID since it is allowed to reuse them throughhout the code.

Action2s should be something like

Code: Select all

// big action 1 block
// action 0 for tile 1
<spritenum> * <len>	 02 04            // Action 02 feature 04 
            00            // unique setID
            00 01 
            00 00            // set from last Action 1 ( zero indexed )                             
// action 3 and 4s for tile 1
// action 0 for tile 2
<spritenum> * <len>	 02 04            // Action 02 feature 04 
            01            // unique setID
            00 01 
            01 00            // set from last Action 1 ( zero indexed )  
// action 3 and 4s for tile 2         
// moar

Action 3 Cargo-types

I'm not sure if your Action 3s are ok. I don't specify Cargo-types here because I don't understand what the wiki is trying to say about it.

For stations, you can additionally define a special cargo-type of FE which prevents the default from being used (which would show the sum of all cargo). Instead, the given cid is displayed with no cargo at all.

From my tests, the default setID is used in the station window and the Cargo-type FE setID is used for construction. I have no idea what the intended behaviour is. I avoid this by setting <num-cid> to 0. This uses only the given setID (cid) as below:

Code: Select all

  <spritenum> * <length>	 03	04                          // Action 3 Feature 04
                                                   01                  // <n-id> : one ID
                                                   04                  // station ID 04
                                                   00                  // <num-cid> : support no cids
                                                   08 00              // <def-cid> : always use set 08

Action 4s look ok.

I hope this is helpful. Let me know if I you want me to explain something in more detail. But if in doubt, wiki + beer = great success

edit

should I just use a new action 01 for each action 00, and define only 4 sprites per action 01?

You can define a separate Action 01 for each Action 00; it would probably be easier to read this way, and you wouldn't need to change the offset in Action 2 to anything other than 00.