GRF encoder tool: GRFMaker [under development]
Moderator: Graphics Moderators
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.
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.
Currently working under the name 'reldred' on Github, and Discord.
NFO/NML coder, part-time patch writer for JGRPP, and all round belligerent.
14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
NFO/NML coder, part-time patch writer for JGRPP, and all round belligerent.
14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
- Andrew Barchifowski
- Engineer
- Posts: 65
- Joined: 03 May 2005 00:10
- Contact:
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 .Andrew Barchifowski wrote:Can we possibly see a public release of the GRF Maker?
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.
Currently working under the name 'reldred' on Github, and Discord.
NFO/NML coder, part-time patch writer for JGRPP, and all round belligerent.
14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
NFO/NML coder, part-time patch writer for JGRPP, and all round belligerent.
14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
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.)
(at least, I hope that's the right variable.)
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
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.
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.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
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.
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 .
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 .
Currently working under the name 'reldred' on Github, and Discord.
NFO/NML coder, part-time patch writer for JGRPP, and all round belligerent.
14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
NFO/NML coder, part-time patch writer for JGRPP, and all round belligerent.
14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
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.
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.
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.
Hodie Mihi Cras Tibi
It is a GUi tool for programming in NFO language.Zimmlock wrote: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.
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.
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.
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.
Hodie Mihi Cras Tibi
*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 .
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 .
Currently working under the name 'reldred' on Github, and Discord.
NFO/NML coder, part-time patch writer for JGRPP, and all round belligerent.
14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
NFO/NML coder, part-time patch writer for JGRPP, and all round belligerent.
14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
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):
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]
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.
Currently working under the name 'reldred' on Github, and Discord.
NFO/NML coder, part-time patch writer for JGRPP, and all round belligerent.
14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
NFO/NML coder, part-time patch writer for JGRPP, and all round belligerent.
14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
-
- Tycoon
- Posts: 5950
- Joined: 27 Apr 2005 07:09
- Contact:
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
[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
I figured as much .michael blunck wrote: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.
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.[GRFmaker feature request]
You´re requesting sort of a compiler. But of course you´re not the first who did.
regards
Michael
Currently working under the name 'reldred' on Github, and Discord.
NFO/NML coder, part-time patch writer for JGRPP, and all round belligerent.
14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
NFO/NML coder, part-time patch writer for JGRPP, and all round belligerent.
14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
Who is online
Users browsing this forum: No registered users and 1 guest