GRFCompiler Starting Development

[George]

Action 7 / 9 will be used with labels, no counting, thats the plan ...

It would quite useful

Now you have a problem with your action7 when you convert your comment to a action 0C, the count of action 7 isn't right anymore

And you can also convert it back. I use this batch when working on graphics

Code: Select all

set namedos=3LongBus
set name=3LongBusesw
!-!remarks.pl %name%.NFO
renum.pl %name%.NFO
copy %name%.NFO %namedos%.NFO
cd ..
grfcodec -e -c %namedos%.grf -m 1
del SPRITES\%namedos%.NFO
grfcodec -e -c %name%.grf
grfcodec -p 2 -d -w 600 -h 400 %name%.grf
if exist \GAMES\ttd-win\newgrf\%name%.grf del \GAMES\ttd-win\newgrf\%name%.grf
copy %name%.grf \GAMES\ttd-win\newgrf\%name%.grf
cd \GAMES\ttd-win\
%1 ttdpatchw.exe
cd \GAMES\TTD-WIN\GRF\pl\SPRITES
!-!remarks.pl %name%.NFO

I also have the idea to learn !-!remarks.pl to determinate the converting direction.

Well and I don't speak Russian

It is a small description for functionality of the tool. I think, first we have to make desision about working on it. If this done, I shall translate this text to english.

[Wile E. Coyote]

I read somewhere (I can't remember where) about some program called GRFmaker in development. Is it done? If yes, where can I download it? Is it simmilar with those ideas? (Sorry if I'm not in topic problem)

[eis_os]

George:
Well, you didn't answer my question, you have to count the comment lines at action 7 aswell... For me thats a mixing of comment and real code, I don't like that... I think you should put your ideas in a new thread...

As locotool grfcompiler could be used as dll I think aswell.

Now to the current output of grfcompiler, currently it's very hackish app,
action A is currently in write ...

Code: Select all

<grfdata>
    <pseudo>04 00 00 00</pseudo>
    <pseudo>
        <action8 grfid="FF FF FF FF" version="2" name="" description="Created by GRDTOGRF" />
    </pseudo>
    <pseudo>
        <actionA num-sets="1" />
    </pseudo>
    <sprite ydim="52" xdim="24" xrel="0" yrel="0" compression="17" filename="unknown" />
</grfdata>

Well the graphic input & output system isn't yet there, it should support png / pcx reading/ bmp reading (all 8bit).

Ohh, Status: 0.001% Done
(well you can put some zeros between dot and one if you like)

[George]

Well, you didn't answer my question

What question?

Action 7 / 9 will be used with labels, no counting, thats the plan ...
Now you have a problem with your action7 when you convert your comment to a action 0C, the count of action 7 isn't right anymore

Do you mean that you want to ask me, do labels is what I want? Yes, they are. Or any other alternative to mark blocks.

you have to count the comment lines at action 7 aswell... For me thats a mixing of comment and real code, I don't like that... I think you should put your ideas in a new thread...

Do you mean that you have decided not to put such functionality into your tool?
You mean, that you have decided to create one more small tool instead of creating a one complete program, that will unite all these small tools and provide the complex functionality for creating and working with grf files?
That's bad idea, I think.

Ohh, Status: 0.001% Done
(well you can put some zeros between dot and one if you like)

I highly recomend you not to waste your expensive time for such a think. I hope you will accept my suggestion to start the complex tool project.

[eis_os]

George: Please reread all stuff again...

Well you said you the perl you posted, then I asked you about what you make with action7, you have to count comments as sprites aswell currently, that I don't like, mixing comments and code when calculating actions and stuff...

Sure I will provide labels, otherwise the whole xml concept is useless...

So what grfcompiler will have: convert grf to xml + png, support labels, comments (they will be stored special so counting of actions don't run into problems, sample action 6 can only change the following sprite)

[George]

Well you said you the perl you posted, then I asked you about what you make with action7, you have to count comments as sprites aswell currently, that I don't like, mixing comments and code when calculating actions and stuff...

Sorry, I can't understand your question.
Do you ask me, how do I do it now? I do it manually. I controll every action 7 myself.
Do you ask me what do I do with comments in my script? I code them as 0c 0c when parsing forward, and I recode 0c 0c as a comment as I parse back. I plan to learn the script to determinate the direction automaticaly and to support direction specifying. (now, if both 0c 0c and comments are present, they would be both reversed, that is wrong)
Do you ask me how do I see labels? For example, as special code in 0c action. For example, as 0c 0c 0c label text in hex. Then all we need is to learn grfcodec to understand action 7/9 that have some incorrect numbers of sprites to skip, for example ff label text in hex 00.

Sure I will provide labels, otherwise the whole xml concept is useless...

Well, as I said, label are required to mark block end. If you use cinstructions like

Code: Select all

<something />
<someblock>
<something />
...
<something />
</someblock>
<something />

it is not neccesary to specify thу block end, because it is already marked with end-tag. Then the action 7/9 can be transformed into skip block kommand and all, we need, is to plase block after it

Code: Select all

<If condition skipblock>
<someblock>
<something />
...
<something />
</someblock>
<something />

So what grfcompiler will have: convert grf to xml + png, support labels, comments (they will be stored special so counting of actions don't run into problems, sample action 6 can only change the following sprite)

Well, nfo-xml convertor was already done by A. Scrobov, and when I tested it I found it useless.
Once again, Oskar. I think, that you are writing not the thing that is required. It is only IMHO, but I have some experience in creating grfs and I think I know, what tool is required. I think you choosed the wrong work to do. I hope you'll change your opinion. Oops, I'm learning you what to do. How bad Well, look at it as just an advice

[eis_os]

Currently I have no clue what you want and whats wrong with actions like this:

...
<action7 ... label="jumpoverbus" />
<action1 />
<action2 />
<action3 />
<action0 />
<label name="jumpoverbus" />
...

well action7 jumps to label named jumpoverbus

Well again, please make a new topic and write down what you think is required for a tool, otherwise it's quite useless

[Zimmlock]

What kind of tool ll this be? the same as GRFwizard? (GRFcodec) dot need 2 of the same but if it can do more and more comfortable than what i use now, not bad.
I did not vote dont know what this is.

[George]

Currently I have no clue what you want and whats wrong with actions like this:
<action7 ... label="jumpoverbus" />
<action1 />
<action2 />
<action3 />
<action0 />
<label name="jumpoverbus" />
well action7 jumps to label named jumpoverbus

Nothing wrong, it is ok. BTW, what will it do, if the jumpoverbus is more than 255 lines below?

Well again, please make a new topic and write down what you think is required for a tool, otherwise it's quite useless

Well, currently Szappy contacted me (he can read Russian) and wrote, that described functionality will be supported by GRFMaker. So, no new thread is needed, my attention would be focused on GRFMaker.
As for your tool, I think (IMHO), that when the GRFMaker will be done, it will become useless, because GRFMaker will cover the whole required functionality.

[eis_os]

Well somehome I think it's very bad if you require something but only have it in a foreign language... and then saying you will use GrfMaker?

And well first it was mentioned grfmaker won't decompile grfs, then it will maybe, maybe not Very confuseing...

As I said, all grfs (even with currupted actions) should be decompiled via grfcompiler... As far I can tell about gl2 tool it's not out and Szappy said he don't really want a decompile option...

And I said it's a replacement for grfcodec not a new programm that let you drag & drop your grfs together. If I have a better control about the processing of the grfs, (Josef's tool isn't the best code wise) I can maybe create some new grf features...

[George]

Hm' looks like sometimes I have problems in expressing my thoughts. This message seems to be read trom the end

So, a small resume first, then the post.
Form my point of view (as grf author), it would be very good, if the efforts of people, who create tools for working with grf, will be united, not separated. Do I ask for too much?

Well somehome I think it's very bad if you require something but only have it in a foreign language... and then saying you will use GrfMaker?

As I said in a short form (in english) that's requires the whole different concept of the tool. No parser is needed. A parser, is a one more state between the grf and the user. I find it a wrong concept. I think, that a tool has to be the only step between the user and the grf file. I try to convince you of this idea for the sevral posts. Szappy said, that they are ready to improve the GRFMaker with this concept (truth to say, they also came to the same concept, so, the concept is already in, just more coding is required). In this case, I find that your work on the parser-like is the waste of your time (IMHO) and you'd better take part part in GRFMaker project, help Mek working on TTDPatch (or even work on the patch yourself), or maybe draw some graphics, it is also fun , but not write the parser.

And well first it was mentioned grfmaker won't decompile grfs, then it will maybe, maybe not Very confuseing...

Szappy wrote today, that it will, they work on it now.

As I said, all grfs (even with currupted actions) should be decompiled via grfcompiler... As far I can tell about gl2 tool it's not out and Szappy said he don't really want a decompile option...

He wrote me today, that they are working on it. I think (IMHO) they would be very glad if you'd join their project.

And I said it's a replacement for grfcodec not a new programm that let you drag & drop your grfs together. If I have a better control about the processing of the grfs, (Josef's tool isn't the best code wise) I can maybe create some new grf features...

Yes, you are guru in it and, of cause, make a good code, but, once again, do not make it a separate tool, create the program, that would cover the whole creating process. May be it is possible to look it other way: To include GRFMaker into the grfcompiller? Well, form my point of view (as grf author), it would be very good, if the efforts of people, who create tools for working with grf, will be united, not separated.

[eis_os]

I don't like tools that hide stuff in a nice happy gui ... (so grfmaker isn't the right tool for me) Well and I can't help any project when there is a language barrier aswell.

But I don't see what you see as additonal step in grfcompiler?

Grfcompiler reads grfs and produces xml or grfcompiler reads an xml and will create a grf from it?
It's not a tool that works on nfo files. So where is the step inbetween?

Well even in grfmaker there a parsers thats a fundamental stuff of computer logic...

A different point is I do like to work with my prefered graphic application when creating the images, my pcx file for my bridge looks like a scretchpad. I don't like to be forced to work in an icon editor like application, so even the released graphic editor part looks nice but wouldn't fit my needs.

[George]

I don't like tools that hide stuff in a nice happy GUI ... (so GRF-maker isn't the right tool for me)

You can always watch GRF in hex editor, can't you? Or the in the NFO format, that is rather understandable, not much less, than XML. But for creating GRFs it is not important.

Well and I can't help any project when there is a language barrier as well.

Szappy can knows English, isn't it enough?

But I don't see what you see as additional step in GRF-compiler?

a XML is a step between the terms, GRF author work in, and the GRF. Now this step is the NFO file, with GRF-compiler it would be an XML file, that is more native, but not enough. (I tested XML representations of NFO-s by Scrobov, so I can imagine, what it is). The tool has to work in term like Vehicle graphics, vehicle properties, condition and so on, like GRF-maker does. It looks a really promising tool for creating GRFs.

GRF-compiler reads GRFs and produces XML or GRF-compiler reads an XML and will create a GRF from it? It's not a tool that works on NFO files. So where is the step in-between?

XML is that step. Look, this is a part of XML of long vehicles file im XML form:

Code: Select all

<?XML version='1.0' encoding='iso-8859-1'?>
<gdf>
<if parameter='climate' condition='not-equal' value='3'>
<if parameter='climate' condition='not-equal' value='2'>
<version GRF-version='2' GRF-id='Meo0;' description='Long vehicles' copyright='Copyright (C) 2003 by George. All rights reserved. e-mail: georgevb@flashmail.com, george-b@mail.ru; WWW: http://ttd.cernun.net'/>
<vehicles type='road' offset='56'>
<property vehicle='1' name='designed' value='23725'/>
<property vehicle='1' name='decay' value='20'/>
<property vehicle='1' name='life' value='15'/>
<property vehicle='1' name='model-life' value='50'/>
<property vehicle='1' name='climates' value='3'/>
<property vehicle='1' name='load' value='10'/>
<property vehicle='1' name='speed' value='255'/>
<property vehicle='1' name='running-cost' value='220'/>
<property vehicle='1' name='sprite' value='255'/>
<property vehicle='1' name='capacity' value='55'/>
<property vehicle='1' name='cargo' value='0'/>
<property vehicle='1' name='cost' value='190'/>
<property vehicle='1' name='sound' value='26'/>
<property vehicle='1' name='power' value='58'/>
<property vehicle='1' name='weight' value='56'/>
<property vehicle='1' name='new-speed' value='70'/>
</vehicles>
<sprites type='road' count='2' directions='8'>
<sprite value='F:\GAMES\TTD-WIN\GRF\pl\SPRITES\LongBusesw00.PCX 114 8 1 28 9 -3 -15'/>
<sprite value='F:\GAMES\TTD-WIN\GRF\pl\SPRITES\LongBusesw00.PCX 130 8 9 25 32 -19 -12'/>
<sprite value='F:\GAMES\TTD-WIN\GRF\pl\SPRITES\LongBusesw00.PCX 178 8 1 14 40 -20 -7'/>
<sprite value='F:\GAMES\TTD-WIN\GRF\pl\SPRITES\LongBusesw00.PCX 226 8 9 25 32 -11 -11'/>
<sprite value='F:\GAMES\TTD-WIN\GRF\pl\SPRITES\LongBusesw00.PCX 274 8 1 28 9 -3 -15'/>
<sprite value='F:\GAMES\TTD-WIN\GRF\pl\SPRITES\LongBusesw00.PCX 290 8 9 25 32 -19 -11'/>
<sprite value='F:\GAMES\TTD-WIN\GRF\pl\SPRITES\LongBusesw00.PCX 338 8 1 14 40 -20 -7'/>
<sprite value='F:\GAMES\TTD-WIN\GRF\pl\SPRITES\LongBusesw00.PCX 386 8 9 25 32 -11 -12'/>
<sprite value='* 1	00 '/>
<sprite value='* 1	00 '/>
<sprite value='* 1	00 '/>
<sprite value='* 1	00 '/>
<sprite value='* 1	00 '/>
<sprite value='* 1	00 '/>
<sprite value='F:\GAMES\TTD-WIN\GRF\pl\SPRITES\LongBusesw00.PCX 530 8 1 14 28 -14 -7'/>
<sprite value='* 1	00 '/>
</sprites>
<cargo type='road' id='0'>
<loaded-state sprite='0'/>
<loading-state sprite='0'/>
</cargo>
<cargo type='road' id='255'>
<loaded-state sprite='1'/>
<loading-state sprite='1'/>
</cargo>
<bind type='road'>
<bound-vehicle id='56'/>
<bound-cargo cargo='0' id='0'/>
<bound-cargo cargo='255' id='255'/>
<default-cargo id='0'/>
</bind>
<text type='road' language='31'>
<vehicle-name offset='56' value='Volvo Bus'/>
</text>
<vehicles type='road' offset='54'>
<property vehicle='1' name='designed' value='29930'/>
<property vehicle='1' name='decay' value='10'/>
<property vehicle='1' name='life' value='21'/>
<property vehicle='1' name='model-life' value='50'/>
<property vehicle='1' name='climates' value='3'/>
<property vehicle='1' name='load' value='10'/>
<property vehicle='1' name='speed' value='255'/>
...

It is not much more readable, than the NFO file. This is the point. The structure of the GRF file should be clean, the props encapsulated on their levels.

Well even in GRF-maker there a parsers that’s a fundamental stuff of computer logic...

But it is hidden from the user, the user has not to be familiar with any code.

A different point is I do like to work with my preferred graphic application when creating the images, my PCX file for my bridge looks like a scratchpad. I don't like to be forced to work in an icon editor like application, so even the released graphic editor part looks nice but wouldn't fit my needs.

Of cause graphics should be allowed to be created in a powerful graphics application (I prefer PhotoShop). But for now I do not see any problems about it in the GRF-maker.

Looks like I could not persuade you to take part in GRF-maker (or to include GRF-maker into GRF-compiler). Sad Ok, let it be that way

[eis_os]

Well, sure this xml is more complicate. George again, don't try to compare my tool with Scrobovs tool, is he spelled right? Well I can't find his tool.

But I will take the time for some comparison:

<if parameter='climate' condition='not-equal' value='3'>
That doesn't look like an action 7 or 9, thats confuseing then hell!

Let's look on an action8 (why is there a ; behind the grfid?):

Code: Select all

<version GRF-version='2' GRF-id='Meo0;' description='Long vehicles' copyright='Copyright (C) 2003 by George. All rights reserved. e-mail: georgevb@flashmail.com, george-b@mail.ru; WWW: http://ttd.cernun.net'/> 

Code: Select all

<action8 grfid="FF FF FF FF" version="2" name="" description="Created by GRDTOGRF" />

The xml you posted hasn't anything todo with my grfcompiler idea,
the xml tool you have tries to add an layer on top of the action syntax system. Grfcompiler will use the normal actions like before. So you will have the same properties. (There will be some lists that can convert names of properties to numbers) and will have the same actions.

What it removes: counting of sprites (because of labels), counting of properties (the count can be automatical determine)

What it adds is comments (that don't affect action7/9, nor action6),
that can be stripped.

Then we have this here:

Code: Select all

<sprite value='F:\GAMES\TTD-WIN\GRF\pl\SPRITES\LongBusesw00.PCX 114 8 1 28 9 -3 -15'/> 

Aswell confuseing. Do we have an xml or what?

Code: Select all

<sprite ydim="52" xdim="24" xrel="0" yrel="0" compression="17" filename="unknown" /> 

Szappy isn't the author or the one that is programming grfmaker...

[George]

Well, sure this XML is more complicate.

Yes, but I do not think that the one, you'll make, be understandable to everyone from the first view. Yes, it would be more handy, that a NFO file, but will operate on the same level. For example, how would it parse the situation, then you have to skip 257 lines?

George again, don't try to compare my tool with Scrobov's tool, is he spelled right?

Yes, you spell it right.

Well I can't find his tool.

I've posted his e-mail in the first post, you can contact him, and he speaks English. But When he started that tool, I tried it and said, that it is unusable and suggested to stop working on it, and to create the other tool (I've posted the description here in Russian). He said that he will think, but didn't start it as far as I know. Now there is GRF-Maker that is planned this way.

But I will take the time for some comparison:

I'm sure that you will make a better tool. But the question (from my point of view) is not the quality of the realisation. The question is the methodology, which is put into the basis of the tool. And a very good coded tool with a week idea in it is more useless, than a somehow coded tool with a good idea in it. This is my point.
Let's us come to the tool from the other point of view. Whom is the tool for? What is it for? What tasks should it solve?
The main task is to create GRF file from graphics. Do you agree with this basic concept?

That doesn't look like an action 7 or 9, that’s confusing then hell! Let's look on an action8 (why is there a ; behind the GRF-id?):
The XML you posted hasn't anything to-do with my GRF-compiler idea

Sorry, but for now I see, that it the same idea, only the week realisation. You will write a powerful realisation, but would it change the picture dramatically? I'm not sure

the XML tool you have tries to add a layer on top of the action syntax system. Grf-compiler will use the normal actions like before.

That's why I say it is the same level as NFO file, simply other (may be much better) realisation

So you will have the same properties. (There will be some lists that can convert names of properties to numbers) and will have the same actions.

But is what we need? Why GRF file author has to think about actions and their properties? It has to think about game objects and their characteristics. That's all. No, I do not suggest to make GRF author doom, I only suggest saving his time.

What it removes: counting of sprites (because of labels), counting of properties (the count can be automatically determine)
What it adds is comments (that don't affect action7/9, nor action6),
that can be stripped. As well confusing. Do we have an XML or what?

It does not matter for me, how good or bad XML we have. The only question is - what to do with it.

Sorry, may be it sounds offending, but you act as a programmer who tries to persuade the client, that the way, he offers to write the software, is the most good for client, while indeed it is the easiest way to program.

Szappy isn't the author or the one that is programming grf-maker...

But he says he is in the team, who creates GRF-Maker

[eis_os]

Well I don't force you to use this tool, I never said I do want a grfmaker like application, I want a replacement for grfcodec... Is this so problematical to understand?

Because grfcodec is weak on some point and well I have no use for a grfmaker like applications, some samples:

My bridge project, how should I coded it without a lowlevel tool?
If you want to hide all grf internals use grfmaker, if you need a tool to work lowlevel there is currently, well only grfcodec.

Next sample:
If I try to test some lowlevel compression stuff, I can't use grfmaker.
I haven't any control in the process of creating the finally grf.

I already have seen that you don't like the idea thats ok... But I already said in the start of grfcompiler it's a replacement for grfcodec.

And as you see on the name, it's an compiler, you are responsible to put the logic in your grf... So the 255 will create a Error Message and I try to make an switch automatic resolve this...

If you want to use an framework or a GRF Designer you should use grfmaker.


PS: And I already have written Client - Software, the main idea behind my software I write is to make it as simple as possible.

[George]

Well I don't force you to use this tool, I never said I do want a GRF-maker like application, I want a replacement for GRF-codec... Is this so problematical to understand? Because grfcodec is weak on some point and well I have no use for a GRF-maker like applications, some samples: My bridge project, how should I coded it without a lowlevel tool? If you want to hide all grf internals use grfmaker, if you need a tool to work lowlevel there is currently, well only grfcodec. Next sample: If I try to test some lowlevel compression stuff, I can't use grfmaker. I haven't any control in the process of creating the finally grf.

Well, you position your tool as a patch tester/developers tool. Then why not to just fix GRF-codec?

[eis_os]

Well, because it's not a tool I like to use. You don't directly write in maschine code, well we use compilers, even if it's an assembler...


Here I tried to reduce the redudant stuff that would get written:

Code: Select all

<grfdata>04 00 00 00
    <act8 grfid="FF FF FF FF" version="2" name="" description="Created by GRDTOGRF" />
    <actA sets="1">
        <set count="1" startsprite="0" />
    </actA>
    <sprite ydim="52" xdim="24" xrel="0" yrel="0" compression="17" filename="unknown" />
</grfdata>