GRF encoder tool: GRFMaker [under development]

[Aegir]

Bug report:

GRFMaker 2.11 (The last version you have given out) creates screwed up station data blocks which crash TTD duing grf-tests (Loading TTD with *only* that .grf) and when loaded allongside other .grfs, the stations have corrupted graphics.

This bug has always existed to my knowledge, but has come and gone. However, in this last build, it produces this error almost constantly, making it darned impossible to make a station set .

Price one pays for alpha testing software I guess .

If you want more info, just ask. I can discuss it at great lengths on IRC, here, or via email.

[Andrew Barchifowski]

Can we possibly see a public release of the GRF Maker?

[Aegir]

Can we possibly see a public release of the GRF Maker?

Why ofcourse, but there is still considerable amounts of work left to get it to a public test phase in my oppinion. Most importantly, documentation needs to be written, and well, Im a lazy person. So dont expect to see me writing any documentation. That and I still dont know what half the buttons do .

Im just a tester though, not a developer or PR guy. When GRFMaker is ready for public release, it will be made public. If your impatient though, you might want to ask Szappy for the program.

[Hyronymus]

Can a fellow coder help me? I coded 7 mailvan types for the Dutch trainset but 2 of them should only appear behind a 'motorpost' (= self-propelled mailvan). How do I do that with GRFmaker? Tell me if I need to supply more info and if you hate to go OT feel free to PM me.

[DaleStan]

Use callback 1D on the engine; check variable C6 (which will have the wagon's ID) to determine attachability.
(at least, I hope that's the right variable.)

[Hyronymus]

I'll try DaleStan, report to be in soon .

[Szappy]

DaleStan, could you provide me with a link to the description of this variable C6, because it seems it's not yet included in GRFMaker.

[DaleStan]

It's an 80+x variable. (More specifically, it's this one.)
It usually contains the type of the vehicle at the beginning of this variational chain. Callback 1D is called on the engine, but with the wagon's 40+x and 80+x variables. Of course, you can still get to the engine's information with type 82 variations.

[Hyronymus]

Ah, so that's why I didn't find it . Szappy, I have a suggestion btw. If you have several sprites to align and you select the vehicle sprite block the sprites are nicely scrolled into place. The x/ypos values don't however which means you have to scroll through a nice list sometimes. It would be nice if the proper x/ypos values would scroll into the edit-screen too.

[Aegir]

THE BUGS! THE BUGS! THEY'RE CRAWLING INTO MY EYES!!! GET THE RAZOR!!!

Ehehm... Anyway, I have a few bugs to report, with 2.18.

First:
GRF/NFO coding algorythm broken (Again) for, so far, stations. Same story as last time.

Seccond:
Not really a bug, but sorta. GRFMaker under WINE deletes all .lst files from the projects directory (Not the backups thankfully) that were opened and saved under GRFMaker. This I *think* may be due to the window manager grabbing partial control of the program (Title bars), and so when the X button on the title bar is pressed, WINE thinks the application hasnt shut down correctly and promptly deletes the last set of active files. Thus, the .lst's. My idea is to add a 'Quit' button within the 'File' menu itself. This should hopefully keep WINE happy about how the application terminates and not get paranoid and delete files. That was all just a wild guess btw, I dont actually know if GRFMaker behaves like that. Just a wild stab in the dark.

If this doesnt fix it, atleast the application will look more 'complete'.

Also, if that doesnt work, could you have a quick look into fixing this issue? I know Windows compatibility would be the primary focus, candy like Linux can wait. But still, I'd rather not have to run GRFMaker through my script which checks for the programs status and restores backups as necessary (Which needs to be modifies every time a filename changes or a new .lst has to be restored.).

Cheers, and great work on 2.18. It was a brilliant version right up until it spat out a screwy station .grf like last time .

[Hyronymus]

I have a possible great idea to make GRFmaker even better. I'm still lacking skills to create some advanced variatonal actions and are secretly waiting for Szappy to help me out. A way to keep myself from annoying Szappy would be if GRFmaker comes with template lst-files of the (all) variational actions. You could then import such a template into your own list and fill in the missing data yourself.

[Hyronymus]

Back with another post: the paste NFO option doesn't work .

[Zimmlock]

This tool looks verry promising although i do not understand it well, but what i do understand is that it creates a ready to run grf.
Does it do buildings? can i tell where buildings have to appear/ disapear, what colors have to be active, and what the behavior of the building(s) has to be?
Does it work reversible to?, Decoding, and is there a list with all available actions?
Does the introduction of this tool mean that artists do not need coders anymore?
A lot of question but for me coding is a mistery.

[Szappy]

This tool looks verry promising although i do not understand it well, but what i do understand is that it creates a ready to run grf.
Does it do buildings? can i tell where buildings have to appear/ disapear, what colors have to be active, and what the behavior of the building(s) has to be?
Does it work reversible to?, Decoding, and is there a list with all available actions?
Does the introduction of this tool mean that artists do not need coders anymore?
A lot of question but for me coding is a mistery.

It is a GUi tool for programming in NFO language.
Your TTRS is indeed coded with this tool too
It's reversible, but not because it can decode grf files, rather because you create a 'project' file (.lst) and you can encode/modify it as many times as you like.
Decoding, and understanding grf files is a pretty hard task to be programmed into a program, but gl2 is working on it.
As for the artists not needing coders, it depends how good the afforementioned artist understads nfo-coding
This is not a 'wizard', and I don't think it would be possible to create one. NFO *is* a programming language, and a quite hard at it, and I've never seen anybody doing wizard-like applications for programming tasks.

[Zimmlock]

Oke, i guess NFO stuff is nothing for me , i browsed the internet a little to know more about nfo coding.....
But If positioning of sprites can be made more easy with this tool it would help a lot and save time, now i have to copy sprite in to a decoded grf, encode it, start the game see if all is in the right place, if not take a screenie, close the game open the screenie in my drawing program, counting the number of pixels the sprite has to move to gain right posistion, change the nfo file encode again and see if all is right.
As you can see, not a verry usefull way.

[Hyronymus]

That's indeed a time consuming part of making new graphics. There was a promise to enlighten 'our' work though so keep your fingers crossed, Zimmlock.

BTW: in the mean time you could try Andres NFOeditor.

[Aegir]

*Aegir runs up over the crest of a hill and screams out "FEATURE REQUEST! TAKE COVER!" before diving for safety behind a rock*

Anyways, after some conversation with the almighty patch gurus, I learnt that there can be upto 32 station classes, and that they can also have any name. Except for DFLT and WAYP for obvious(ish) reasons.

So, what I'm asking is, is for, aswell as picking the eight preset ones, that it be possible to pick somthing else (And put in your own class name so that there arent cross-overs with other artists).

Thankyou .

[Aegir]

Okay, compared to the last feature request that I screamed for cover about, this one is like an atomic bomb.

So here it is (Mirrored on my blog and also on .txt for email if anyone wants a copy):

Code: Select all

Textual representation for the .lst format.

Before GRFMaker, you decoded .grf into an .nfo and a .pcx. You edited them both, and compiled them back into .grf.

When GRFMaker came allong, you worked in the GUI, using this concept of 'blocks' that represented chunks of .nfo code. GRFMaker made an .lst, and it could make a .pcx and .nfo out of your work. The .pcx and .nfo were then turned into a .grf. Just like normal.

What I propose, is a textual representation of the 'block' concept in use. To be used allongside GRFMaker, and perhaps instead of depending on the work situation (Unable to access GRFMaker, wanting to perform complex text operations on files for use with GRFMaker, and so forth).

For example. Instead of the .nfo/.pcx to .grf process, I propose:

GRFMaker Interface -------> .lst ---> .nfo/.pcx ---> .grf
         Text form ---/

So its the same, except at the very end stage, where the user interacts, he/she has two options, that work allongside each other.

GRFMaker already can save to .lst, and export to .grf (convert to .nfo then to .grf), what I would like to see is a set of command line tools similar to grfcodec for converting .lst to .nfo/.pcx, and converting .lst to a text form.

Another example. This is perhaps how a station (Because thats about all I code ;) ) name block would look like:

Another thing is that comments within each block would be useable, but they would be lost apon conversion to .lst, or when used with GRFMaker.

[Name Block] ; This is the header for the block. Would have the exact same name as what the block does in GRFMaker.
Feature = c5xx ; Station name
Language = 3 ; American and English
ID = 0
Name = Basic Platform

So obviously, its exactly the same as what you see and manipulate in GRFMaker, but in text form. What would be difficult is trying to represent blocks that have multiple windows to modify (Data blocks).

Here are my reasons for this rather large suggestion:

1) Another alternative way to code graphics

2) Allow drawing up plans and sketches easier on paper, or in .txt form easier when GRFMaker is not availible.

3) Perform search and replace operations on .lst's

4) Attract people familiar with modding other games, who do not wish to use a GUI (This text form I am proposing is very similar to what is used in the Command and Conquer series of games, and also very similar to what is used in the game Freelancer. Im quite sure other games use somthing similar aswell)

5) Some people think using GUI based tools is cheap. Give them an alternative (But they'll be attracted back to GRFMaker by the sprite block tools :) )

6) Command line utilities for converting .lst's to .nfo/.grf (Thats another suggestion) can be used allongside grfcodec and then used under other operating systems, and with advanced scripting (Such tools can be used with Cygwin bash aswell).

7) I have more points, but I'm slowly getting a headache from looking at bright white on a CRT monitor.

Now, finally, I am no programmer, so I have no idea wether this is an easy task, or somthing incredibly difficult, so obviously I'm not demanding anything, just throwing another suggestion onto the table.

This is not a serious request like the last post, as it is quite a bit larger. Well, I want to see it created ofcourse, but I wont be angry if you say somthing allong the lines of 'No bloody way'.[/code]

[michael blunck]

Aegir wrote:

[station classes]

> So, what I'm asking is, is for, aswell as picking the eight preset ones, that it be possible to pick somthing else (And put in your own class name so that there arent cross-overs with other artists).

I´m already doing it this way since a couple of NewStations versions.

[GRFmaker feature request]

You´re requesting sort of a compiler. But of course you´re not the first who did.

regards
Michael

[Aegir]

Aegir wrote:

[station classes]

> So, what I'm asking is, is for, aswell as picking the eight preset ones, that it be possible to pick somthing else (And put in your own class name so that there arent cross-overs with other artists).

I´m already doing it this way since a couple of NewStations versions.

I figured as much .

[GRFmaker feature request]

You´re requesting sort of a compiler. But of course you´re not the first who did.

regards
Michael

Bingo. I get the idea that a lot of current GRFMaker code can be re-used, but I may be completly wrong. I hope I am right though. I cant quite stomach NFO, and editing text has its advantages over GUI tools.