Michael Blunck's new graphics [http://www.ttdpatch.de/]

[minime]

Michael,

how do you make your DBSetXL increase the cost of other vehicles (in other sets), even though it has a lower priority? I love to use the set for it's wagons, since AFAIK there is no equivalent to it yet. However, since I use a different set for the locos (CSDSet) which already has good prices assigned to the vehicles, I find it undesireable to have them modified (it can make some games impossible to start due to limited budget).

Would it be possible (for somebody) to create an individual grf that would do just that? Could you please point me in the right direction (e.g. what actions to use) to achieve that? My guess is that you either set a global coefficient that applies to all the IDs, or that you modify the costs per ID (maybe action D?)

Would you mind if i examine the DBSetXL grf to figure out how you did it?

Cheers,
minime

[michael blunck]

The DB Set XL uses "global cost base multipliers" implemented via action00 prop 08.

see: http://wiki.ttdpatch.net/tiki-index.php ... lVariables

By doing this it increases costs of

- signals (building *8, removing *4)
- depots (building *8, removing *4)
- locomotives *2
- coaches/wagons *4

By setting Bit 4 in the DBXL´s additional parameter these costs would be increased by half only, i.e. building wagons would get a factor of 2 instead of 4, etc.

AFAIK, those global variables are used by all .grfs successively, so it wouldn´t be a good idea to "overload" foreign vehicles which would suffer by those modified costs.

You may try to include an own "global cost base multiplier" in the CSD set as well, thus trying to reset things to normal:

Code: Select all

-1 * 55	00 08 01 31 00 08
	08 08 08 08 08 08 08 08 08 08 
	08 08 08 08 08 08 08 08 08 08 
	08 08 08 08 08 08 08 08 08 08 
	08 08 08 08 08 08 08 08 08 08 
	08 08 08 08 08 08 08 08 08 

HTH

regards
Michael

[Geo Ghost]

Theres a small bug..

Im getting that A LOT also.
The way round it i find is to make the station different shapes till it dissapears.

[michael blunck]

Ah yes. Sorry, somehow I missed that post.

> Theres a small bug..

V0.44 (Dec 27th, 2005)
- Coordinate tweak in non-tile station buildings because of sprite sorter issues.
- Changed fence appearance on non-track platforms.
- Taucha got chimneys.

http://www.ttdpatch.de/download.html

regards
Michael

[minime]

The DB Set XL uses "global cost base multipliers" implemented via action00 prop 08.

That was my other suspect for a possible solution.

Thanks a ton for the prompt explanation, as well as for producing all those lovely sets of yours. TTD wouldn't be the same without them.

minime

[jonty-comp]

I had just noticed that earlier bug, too... Thanks for fixing it!

Small Suggestion:

- The 'Car Park' platform sometimes doesn't fit in with my setups. I think it would be great if you could make a Non-Track Tile with a carpark on. That way, you could have the car park, then a building with the ticket office in, then the railway platform. I'm trying to put together a pic of what I mean using the GIMP, but it's not done yet.

EDIT: OK I was trying to put together a sample pic in the GIMP, but it was too difficult. You'll just have to work out what I mean.

[Geo Ghost]

Small Suggestion:

- The 'Car Park' platform sometimes doesn't fit in with my setups. I think it would be great if you could make a Non-Track Tile with a carpark on.

That would be really good. Realistic for very large stations

[minime]

Hello Michael,

I have a few questions and speculations about your GRF files. (Since this involves coding, anyone else competent to answer, please feel free to do so.)

1. In many of your GRFs (newshipsw, cargosetw, dbsetw, dbsetxlw and newstatsw) you have a 52x1 pixel sprite near the beginnin of the file. It's loaded using action 01, and in the first four mentioned sets, it's the second sprite out of 4 with the other sprites being empty, like so:

Code: Select all

    5 * 4	 01 00 01 04
    6 * 1	 00
    7 sprites/dbsetw.pcx 130 8 01 1 52 -14 -7
    8 * 1	 00
    9 * 1	 00 

In the stations GRF, it's just a single sprite, and the action 1 is for feature 04 instead of 00.

What is the purpose of that sprite? More importantly, since there is no action 2 following this sprite block, how do you later access this sprite? (AFAIK, unlike in action A, in action 1 you don't define the sprite number, only the sprite count (num-sets*set-size)).

2. I assume that by including a pseudo sprite inside an action 1 or action A block, you're basically including the bytes contained in the pseudo-sprite.

As such

Code: Select all

    8 * 1	 00

would most likely be an empty (NULL) sprite (most likely used to save memory or hassle of defining unused sprites)? Anything to watch out for if you use this?

The first byte is probably some kind of a flag.
I've noticed the 2ccol maps are defined similarly, and their first byte is also a 00. Similarly, all the sprites of this format that can be found in the original game data files also start with a 00. However, in newstatsw you use an action A to load something like this:

Code: Select all

    6 * 257	 01 00 01 01....

i.e. you set the first byte to 01. Why is that?

I haven't found any reference of using pseudosprites within action 1 or action A blocks (other than the talk about 2cc in action 5), so i'm mostly guessing here. Are my assumptions in this point correct?

3. Somewhat connected with the previous point. After some pondering, I have concluded that with

Code: Select all

    5 * 5	 0A 01 01 13 12
    6 * 257	 01 00 01.....

you load your custom colour translation map to a sprite-id of your choice.

You then later on use this map when drawing your glass roofs, such as in the following sprite layout:

Code: Select all

2D 04 00 80
00 00 00  10 05 0B  2D 04 00 00
00 0B 00  10 05 0B  77 84 00 00
00 00 80  00 00 00  9B 44 13 12
80

Of course, the interesting part there is the number of the last sprite - 0x1213449B - which seems to mean:
Draw sprite number 49B
Bit 14 is set, so draw transparent (well, more accurately draw using colour translation, since that's how transparency seems to be done)
using colour translation map in sprite number 0x1213 (the one you loaded in the action A).

Did i get that right?

----

Well, that's all of it. As a side note to those who take care of the Wiki - while some of this may be mentioned in various places, it's damn hard to find, and not apparently obvious.


Cheers,
minime

[DaleStan]

1) As far as I can tell, it serves no functional purpose. As you mentioned, there is no action 2 before the next action 1, so the sprite can never be used.

2) Pseudos of the form "-1 * 1 00" are used in action 1 blocks to avoid adding an never-used real sprite, most commonly for vehicle sprite sets that are only used in the purchase window. I believe, though I've never tested this, that TTD[Patch] will crash if it ever attempts to draw one of those false-real sprites.
Pseudos of the form "-1 * 257 00 ...", on the other hand, are used in action A blocks and some action 5 blocks, as recolor sprites; see the Action5 page for more information.
No clue why Michael's 257-byte pseudo starts with 01, but it probaby has no effect on the game. Patchman suspects that the first byte is some sort of bit-field, but I don't believe even he knows exactly what it does.

3) Corrrect. "Transparent drawing" means to apply the associated recolor map to the sprite(s) below the "transparent" sprite everywhere the transparent sprite is contains pixels in any color other than transparent blue.

As a side note to those who take care of the Wiki - while some of this may be mentioned in various places, it's damn hard to find, and not apparently obvious.

It's a wiki. Accordingly:
Where did you expect to find this information? Put it there. (Preferably after verifying or disproving the will-crash-on-false-real bit.)

I have often considered splitting the information on real sprites, recolor sprites, and binary imports/includes off to their own pages, and may actually do that later tonight.

[minime]

Pseudos of the form "-1 * 257 00 ...", on the other hand, are used in action A blocks and some action 5 blocks, as recolor sprites; see the Action5 page for more information.

Yeah, I've seen it, that's one of the things I've drawn my conclusions from.

... but I don't believe even he knows exactly what it does.

Got it

As a side note to those who take care of the Wiki - while some of this may be mentioned in various places, it's damn hard to find, and not apparently obvious.

It's a wiki. Accordingly:
Where did you expect to find this information? Put it there. (Preferably after verifying or disproving the will-crash-on-false-real bit.)

I didn't really consider myself qualified enough to do so - definitely not enough to write documentation. But considering your nag, I guess I'll get a login and take part.
[EDIT: Ooopsie, I guess I already had one. ]

I have often considered splitting the information on real sprites, recolor sprites, and binary imports/includes off to their own pages, and may actually do that later tonight.

Yes, that would be lovely. Pretty much anything like this that applies to more than one feature/action/whatever deserves a separate page.

BTW, when defining station sprite layouts via property 09, there is a mention that you can define fewer than 8, however there is no mention of any lower limit. Considering that defining only two of them makes the game crash when the build station window is open, and remembering that the window normally displays the "platform with building" tiles for the default station, I am lead to believe that you _have_ to define at least 4 tiles. Something tells me that there may be a way to get around that by using a callback to select the tiles, but I haven't examined that possibility yet.

Correct?

Anyway, thanks for the answers man,

minime

[DaleStan]

I didn't really consider myself qualified enough to do so - definitely not enough to write documentation.

When complaining about documentation, it's always a good idea to report where you thought the information should be, even if you don't consider yourself qualified enough to write the documentation.

I have often considered splitting the information on real sprites, recolor sprites, and binary imports/includes off to their own pages, and may actually do that later tonight.

I am currently working on this. (OK, so I'm currently posting to the forums. You know what I mean.)

My recollection of the station window is that it displays tile types 00..04. It might be possible to change this with judicious use of cargo type FE/FF and callback 24, but no guarantees.

[DaleStan]

I have often considered splitting the information on real sprites, recolor sprites, and binary imports/includes

I am currently working on this. (OK, so I'm currently posting to the forums. You know what I mean.)

And it's done. I decided to leave the import/include information on the Action11 page, since it doesn't apply to any other actions.
I'm not entirely happy with the structure, but other than that, how does it look?

My recollection of the station window is that it displays tile types 00..04.

Must be bedtime. That should be 00..03. (Not to mention several stupid mistakes when creating the wiki-pages.)

[eis_os]

I think this goes now a bit far to offtopic. And I don't think you are allowed to decompile Michaels GRF files anyway


Recoloring:

And you shouldn't worry about stuff you don't understand
Simple use it as the wiki says. There is nothing behind the first byte, the reason why there is a 01 is because of me, but at that time I simple did a wrong interpretation of the code. There is no hidden functionality, no hidden bitfeld or something, it simple isn't used. (That doesn't mean you should put something different then 00 in it, maybe a patchdev likes that byte and use it for different use in the future.)

About the other stuff, you shouldn't worry about stuff you aren't supposed to see.

a) Do it the wiki way, it's the only way we support
b) If something isn't in the wiki, you can ask some dev and if you understand what he tells you write a wiki entry.
c) Ask Michael for functionality you don't understand but don't copy code! He is very supportive when you ask something about how stuff works.

Now back on topic please, ok?

[michael blunck]

@minime

[use of recoloring sprites]

There is no real difference between "normal" and "transparent" recolouring aside from a conceptual notion. Both are using colour look-up tables to transposing colours into other colours, the only difference being that a coulour look-up table being used for company colour translation would normally define only 8 colour transformations while a look-up table used for "transparency" purposes would use all 256 colour entries (well, most of all, except those "special colours").

Fortunately, most of your questions have been answered concerning this issue and in addition Dalestan kindly updated the Wiki regarding these questions. However, another important point is that you shouldn´t set up recolouring sprites anymore as shown in the (outdated) examples above, namely by using real sprites (from toyland). Instead you should use the patch´s "Graphic Ressource Management" (GRM) features.

I.e. instead of

Code: Select all

5 * 5	0A 01 01 13 12
6 * 257	..........

You should always allocate real sprites using the GRF Resource Management:

Code: Select all

// GRM - reserve 1 sprite
5 * 9	0D 01 00 00 FE FF 08 01 00
// relocate sprite block
6 * 5	06 01 02 03 FF
7 * 5	0A 01 01 13 12
8 * 257	..........

And instead of referencing that sprite simply by number (1213h) you´ll have to use the mechanism outlined here:

http://wiki.ttdpatch.net/tiki-index.php?page=Action6

Only in this way collisions between sets using the same real sprites would be avoided.


[station sprite layout blocks]

Yes, 4 tiles would be the minimum for definition in a station sprite layout block (even when using callback 14). You´ll need:

- 2 tiles for track x- and y-direction
- 2 tiles for icons in the building window



[edit]
@Oskar

And I don't think you are allowed to decompile Michaels GRF files anyway

Well. The Copyright notice doesn´t explicitly forbid this. Although, in general, it´s only permitted to "use, copy and distribute" the software as it is, I don´t think "decompiling" my .grfs would be a Copyright infringement at all, as long it´s done because of the desire to learn. I´ve always seen my .grfs as tutorials for novice .grf developers and many people have looked into them.

O/c it is forbidden to copy graphics (and code) in whole or in part into other .grfs or modify the original .grf and to distribute it.

I generally tolerate modifications and usage for personal use.

regards
Michael

[minime]

Thank you to DaleStan and MB.

Now, I know I'm going OT with this, but Oskar, you brought this on yourself. Apology to Michael for doing this in his topic.

1.

And I don't think you are allowed to decompile Michaels GRF files anyway

I would say it's about as questionable as patching TTD is (or do you want to lead me to believe all the patch devs learn the insides of TTD by consultation with a divine being?).

Besides (and Michael already confirmed this), would you please back your statement with _FACTS_, before you whine at me first. Or maybe just leave it to the author - he's got fingers as well.

Third of all, how else do you expect people to learn coding? Or am I mistaken, and noone here is interested in any new graphics files?
As a programmer, I learn from reading other people's code. Documentation is fine and dandy, but often it's incomplete, and it can only provide you with a reference.

Once the documentation of GRF features is exhaustive and filled with hundreds of examples of complete, functional NFO files (not just the few trivial - but useful nevertheless - that are there now), I'll be more than happy to use that as my only source of information.

2.

And you shouldn't worry about stuff you don't understand

That's just plain stupid/ignorant (pick whichever you like more) thing to say.

3.

Simple use it as the wiki says.

Wiki didn't say, hence I asked.

4.

That doesn't mean you should put something different then 00 in it, maybe a patchdev likes that byte and use it for different use in the future.

Please don't treat me like a retard...
I've seen an exception to the rule, and I've asked.

5.

About the other stuff, you shouldn't worry about stuff you aren't supposed to see.

See #2.

And where is it said I am not supposed to see something? By whose authority? Why?

6.

Ask Michael for functionality you don't understand

That's what I'm doing.

7.

but don't copy code!

Would you please point out _WHERE_ I copied his code (and no, the parts i pasted into my post to show him what I meant don't count).
If you can't, then I believe an apology would be in place, considering you've just accused me of a crime with no proof.

8.

Now back on topic please, ok?

Well, considering I've asked Michael about his graphics, this would seem to be the most appropriate topic. Your rant on the other hand... If this is your idea of being helpful, I pity you.

Regards,
minime

[DaleStan]

I think this goes now a bit far to offtopic. And I don't think you are allowed to decompile Michaels GRF files anyway

Hmm... I'm in trouble then. His NFOs were some of the first to be run through NFORenum, once I added the linter.

Minime:
Try to avoid beating up a patchdev, even a "retired" one. Oskar has had his fair share of copyright troubles. You do have a point, though.

1) Most EULAs do forbid TTDPatch-type activity, but, AIUI, the TTD EULA, for one reason or another, fails to forbid it.

Once the documentation of GRF features is exhaustive and filled with hundreds of examples of complete, functional NFO files (not just the few trivial - but useful nevertheless - that are there now),

May I suggest that you post examples, if/as you code them? They're substantially easier to verify than documentation.
I don't often find examples useful, so I don't tend to add them to the wiki.

I don't forsee the wiki becoming a repository of complete, functional NFO files; real-world ones are usually over five hundred sprites, and they tend to go obsolete almost as fast as they're coded. Snippets stay valid for much longer.

[minime]

Minime:
Try to avoid beating up a patchdev, even a "retired" one.

I'd love to, but being a patch dev does not excuse rudeness. If he throws a punch, I won't take it silently.

May I suggest that you post examples, if/as you code them? They're substantially easier to verify than documentation.
I don't often find examples useful, so I don't tend to add them to the wiki.

Yes, I will. I intend to release my GRFs with the full source. You're right, snippets are useful too, but sometimes it's nice to see how the author approached the problem. And if the source is included, you don't lose the comments.

Gotta run...

[eis_os]

Grr, please read again my posts, it was in a general form

I didn't say you have copied code, the post showed general guidelines what to do.

If this is your idea of being helpful, I pity you.

After your post I think: "Why I have used my time to explain you why there is a 01 and not a 00." And explained in detail why you shouldn't use something that isn't 00.

"And you shouldn't worry about stuff you don't understand" <- I could have send you A LOT explaination of assembler code and why Chris Sawyer maybe did it this way. I give the needed explaination that there is no functionality and why Michael has 01 in it. And not the bitfield stuff floating around. From my standpoint there is no code accessing this first byte but for future additions don't use anything that isn't 00.

Again I have to say, please don't use any hacks, broken action 1s or some other unsupport stuff. Most patchdevs see when say the DBSetXL breaks because of something that shouldn't be there, other sets aren't that tested. Ohh and I consinder putting pseudo sprites in action 1 as rubbish. Thats stuff you shouldn't see, and shouldn't do. Sample the grf helper window can get confused or even totally screw up memory locations when you try to access them. New action code can get confused aswell. We already had the problem that action 01 have used the wrong feature. It worked until changes had to be made to the code.

Action 01 is used to define sets of real sprites (as opposed to pseudo-sprites). It can be put anywhere in the .nfo file after action 8.

For me this means, I have spend time I could used different. As It seems my explanation why the first byte should be 00 was unwanted, I will not tell people anymore about internals. Don't ask me anymore about any internals on tt-forums, the irc channel or somewhere else, Thanks.

[minime]

Dear Oskar,

Notice I've never questioned the accuracy or validity of your explanation of the meaning of that byte. However, I did dislike the arrogant and condescending tone of your post, and now I'm apparently an asshole, because I let you know how I felt about it.

Anyway, I apologize for going offtopic now.

Regards,
minime

[lobster]

However, I did dislike the arrogant and condescending tone of your post, and now I'm apparently an asshole, because I let you know how I felt about it.

as being a 3rd party lurking reader (i always tense up whenever there's new posts in this topic, hoping a new release is done) and having read the last conversation you had with eis_os (and in particular your behaviour towards him) i can agree: you are an asshole. and please stop polluting this topic with your nonsense.