GRF encoder tool: GRFMaker [under development]

[FHS]

neg is right, I get the same error when trying to increase kN beyond its default setting.

[AndersI]

I could equally well say "You're both wrong, it doesn't happen for me". Please give more data, version numbers, project files, pictures, etc. to show what you do, what happens, and what you expected to happen. Your textual description is not enough...

[FHS]

I sended you the data you requested by PM.

[Killer 11]

I need some help with GRFMaker. I have no idea how to make articulated vehicles. I'd like that my 2M62 and my steamer could be bought complete and not in parts(2M62 unit A, 2M62 unit B) like it is now.

[AndersI]

@FHS & neg: OK, I've seen the same error now. Unfortunately, I don't have a Delphi environment available for the moment - old computer crashed, and the free Turbo Delphi is discontinued (no new licenses generated) - so I don't know when I will be able to look at it. Sorry

@Killer 11: Take a look in the attached steam.lst - the bitmaps are not there, but I think you can see what to do in GRFMaker anyway.

[johannes]

Thanks that helped me A LOT

Would you or someone else also show how to change livery? I know how to change it when vehicle is being refitted but I'd also like to know how I change livery at a certain year? For example vehicle is being introduced at year 1980 in blue and it would change its color to red in 1990, how can I assign that?

[Vemarkis]

Since I want to support newcargoes with this grf I've done with grfmaker, I would also need a cargo translation table. However, grfmaker refuses to accept one in a manual nfo block with the error "8401:incorrect hexadecimal number in the nfo code".

I used the nfo code from this post: http://www.tt-forums.net/viewtopic.php?p=742595#p742595 (and for those of you thinking that comments are the problem, I stripped those and I still get error 8401:incorrect hexadecimal number in the nfo code). It doesn't seem to like stuff like "PASS", so I imagine grfmaker needs to implement support for cargo translation tables(which are crucial for supporting new industries which it can code anyways).

[AndersI]

As I said in the previous post, I'm out of the loop with respect to fixes and additions in GRFMaker for the moment. I don't think there are any active developers right now, unfortunately

As for the NFO block, you have to translate *everything* to hex - plain old original nfo is what you can enter in the GRFMaker 'manual NFO' block.

[Vemarkis]

Well, I converted that CTT with str2hex, and I find out when I compile the grf with either grfcodec, or grfmaker that they both add extra " and \ into the CTT label bits for some reason.

http://pastebin.com/m492540e6

I cannot find those extra "'s and \'s in this str2hex output. They won't even show up in grfmaker, but they somehow end up into the compiled grf.

[edit]Apparently, you are not supposed to enter the "'s into the manual nfo block, grfmaker or grfcodec will do it for you
Here is the cargo translation table I put into grfmaker:
this is what it was in text
PASSCOALMAILOIL_LVSTGOODGRAIWOODIORESTELVALUPAPRFOODFRUTCOREWATRRUBRSUGRTOYSBATTSWETTOFFCOLACTCDBUBLPLSTFZDRWHEAGOLDMAIZTWODDIAM___A___B___C___D___E___F___G___H___I
heres the str2hex output
You need to have this code before the str2hex output in the manual nfo block:00 08 01 29 00 09
so the end result looks like this in grfmaker.

So, what can you do this with this cargo translation table? You can define proper refit masks for your vehicles(which means, only use available cargos for refitting only for exceptions, i.e define wood and TWOD when you have a vehicle with refittable cargo classes: piece goods set to disable carrying wood. You can also use it to define cargoes you want to be refitted that are outside your defined refittable cargo classes field, i.e you can have a box car refittable to milk even if you do not have the refittable cargo class "Liquids" selected. You can find the cargo order, and bit values for the cargoes in this thread. For example cargo TWOD resolves to the value 40000000 in grfmaker(aka the second to last cargo in the available cargoes for refitting list in grfmaker). When doing the graphics ID's, use the default ID to define the graphic that will be used when you have not defined a graphic for a cargo.

I'll probably do what I've learned above as a wiki article later, which would be more structured and easily understandable with plenty of pictures for each stage!

[DaleStan]

Well, I converted that CTT with str2hex, and I find out when I compile the grf with either grfcodec, or grfmaker that they both add extra " and \ into the CTT label bits for some reason.

You did that yourself. str2hex takes strings, not NFO. If you need an nfo2hex converter, encode the nfo with GRFCodec and then decode with -d -xxt.

I cannot find those extra "'s and \'s in this str2hex output.

See all those «22 20 22» triples? Those are your «\" \"» bits (Info version 7. Info versions 5 and 6 would read «22 "PASS" 22 20 22 "COAL" 22 20 22 "MAIL" 22 ...».)

GRFCodec interprets quotes as special one-character instructions to switch to or from reading quoted strings. To GRFCodec, «"PASS" "COAL" "MAIL"» is equivalent to, among other things, «"PASSCOALMAIL"», «"P" "A" "S" "S" "C" "O" "A" "L" "M" "A" "I" "L"», «"PASS""COAL""MAIL"», and «"P""A""S""S""C""O""A""L""M""A""I""L"», and all are 12 bytes long. To str2hex, these are 20, 14, 47, 18, and 36 (respectively) characters, to be converted to 20, 14, 47, 18, and 36 (respectively) hex bytes.

[Vemarkis]

I think you missed the fact I figured out how to get str2hex to convert that cargo translation table properly in the above post, DaleStan without bothering with compiling and decompiling a grf in the first place. Which is a much slower method.

[DaleStan]

I think you missed the fact I figured out how to get str2hex to convert that cargo translation table properly

No, you figured out how to type the cargo translation table properly. str2hex correctly converted what you typed. It's not its fault what you typed is not what you wanted converted, nor (as the case may be) that you misunderstood the correct input to str2hex.

I was explaining what you did wrong, and why GRFCodec wants «"PASS" "COAL" "MAIL"», but str2hex wants «PASSCOALMAIL».

[petert]

Wow, I just noticed that this was made by a Hungarian, and it includes Hungarian translations. Thank you!

[AndersI]

I have discovered a bug: If you try to increase traction beyond the default, GRFMaker will generate an error message that tells you that "'k' is not a valid integer value.".

OK, I have located and fixed this bug. Actually, GRFMaker was trying to say '#Tractive effort set too high. The maximum value is 10 times its weight: %1kN.' but there was an error in the English error message.

Build 218 is available at http://users.tt-forums.net/grfmaker

[oberhümer]

Next bug: GRFMaker sets the tractive effort wrong. Instead of setting it as a fraction of the possible total forward force, it literally writes the number that is set in the field for tractive effort into the NFO.

It is also not possible to set the bit for "is articulated vehicle" when coding a road vehicle.

[AndersI]

Next bug: GRFMaker sets the tractive effort wrong. Instead of setting it as a fraction of the possible total forward force, it literally writes the number that is set in the field for tractive effort into the NFO.

No. At least not for trains,

Wiki says:
prop. 1F = HEX ((TEreal / (Mass * g) * 255)

Code says:
te := trunc(vhd[idx].tractiveeffort / vhd[idx].weight * 25.5);
AP($1F, 1, te);

AFAICS, this is the same.

Now, if you're talking about road vehicles, it's another thing. There you are expected to enter the coefficient directly in GRFMaker (0..255) - who have ever heard of actual TE data for road vehicles?

It is also not possible to set the bit for "is articulated vehicle" when coding a road vehicle.

If you mean the callback bit, this is probably true. Articulated road vehicles were not invented when GRFMaker was written. It might be possible to work around with a "general NFO block", perhaps?

[oberhümer]

It's with RVs... there it is never possible to enter more than ten times their weight in tons as coefficient in GRFMaker itself. That cost me a bit of time...

[AndersI]

It's with RVs... there it is never possible to enter more than ten times their weight in tons as coefficient in GRFMaker itself.

OK, I've changed the test on TE for road vehicles - it is now assumed to be the coefficient (range 0..255), as that was what the code did, anyway. I choose not to change the code, as that would have invalidated all existing road vehicle projects.

Version 3.04B_r220 is available here.

[NekoMaster]

Um, for some reson not matter what I do grf maker keeps saying "Invalid Filename" when I try to compile a grf, even though Its called asdtest

[oberhümer]

Doesn't happen to me - have you tried the newest version?