Transport Tycoon Forums

DaleStan wrote:Well, the first problem is that you're not using literal strings,

Who said they have to be literal? "OIL " have non-literal symbol " "

DaleStan wrote:and the second is that you don't seem to have any line breaks,

who said there should be any breaks? The only place with breaks, I remember, is 00 80 in industry layouts.

DaleStan wrote:much lessline breaks in happy places. (Read: "*between* the labels, not in the middle of the labels".)
Do you have to work at making things hard for us, or does that come naturally to you?

It is how grfcodec suttorts it. I know about not using -t switch. The problem is that recognises as texts the things that are not texts. In action 0 for example

DaleStan wrote:/me wanders off to str2hex
Those labels belong to which cargos, exactly?

They are reserved. there are 253 allowed

DaleStan wrote:You don't set labels that don't belong to cargos.

why not?

DaleStan wrote:The whole point of this is to provide 253 climate independent IDs. You're defeating that if you use labels that will never be attached to cargos.

That is ok.

George wrote:

DaleStan wrote:Well, the first problem is that you're not using literal strings,

Who said they have to be literal? "OIL " have non-literal symbol " "

Sorry, I changed that because the space gets eaten by HTML and is just a poor choice on my part. In the real a66 release, it will be using "OIL_" with an underscore, as documented on the wiki now.

DaleStan wrote:You don't set labels that don't belong to cargos.

why not?

I can see the rationale behind leaving "reserved" spaces in the first 32 entries, because if you need them in the refit list, you can add them there later without recoding all action 3s. Even for the entries after that, it might be useful if you have some other scheme in mind.

In any case, it won't hurt at all, and it won't slow down the game at all if you reference non-existing cargos, so I have no problem with it.

However, to figure out what the problem is, just showing the translation table is rather useless. The table looks fine, but what doesn't work? The action 3? The refit mask?

Since your code is extremely hard to read (due to the lack of comments and because it uses hex instead of strings), I'll have to request a test grf if you want me to look at why it breaks.

Patchman wrote:However, to figure out what the problem is, just showing the translation table is rather useless. The table looks fine, but what doesn't work? The action 3? The refit mask?
Since your code is extremely hard to read (due to the lack of comments and because it uses hex instead of strings), I'll have to request a test grf if you want me to look at why it breaks.

Here it is. The problem is that is refited into passengers, while passengers are not represented in the table, while most cargo, represented in the table and action 3 are missing (when refit)

The refit mask (in sprite 611) is FFFFFFFF. This means it's refittable to the first 32 entries in the translation table, which are (together with some fillers) PASS MAIL GOOD TOUR COAL WATR SAND GLAS VALU GOLD DIAM FOIL.

So you do indeed set it to be refittable to passengers.

We carry tinfoil now! Great!

Patchman wrote:The refit mask (in sprite 611) is FFFFFFFF. This means it's refittable to the first 32 entries in the translation table, which are (together with some fillers) So you do indeed set it to be refittable to passengers.

When I set 1E and 1D to (FF FF + 00 00) or (FE FF + 00 00) or (FF FF + 01 00) or (FF FF + FF FF) I get the same result.
The question is: what values I have to specify in what props of action 0 to get the vehicle to be refittable to any cargo, specified in action 3?

George wrote:When I set 1E and 1D to (FF FF + 00 00) or (FE FF + 00 00) or (FF FF + 01 00) or (FF FF + FF FF)

Are you sure you said that in the right order?
1D 00 00 1E FF FF is *not* what you want; ditto on 1D 00 00 1E FE FF, 1D 01 00 1E FF FF, and 1D FF FF 1E FF FF.

If you want to carry all non-pax cargos, what you should be setting is 16 00 00 00 00 1D FE XX 1E 01 XX

I'm not sure what the official line on setting undefined cargo class bits; replace those "XX"es with whatever you want; AFAICK, they don't currently do anything.

DaleStan wrote:

George wrote:When I set 1E and 1D to (FF FF + 00 00) or (FE FF + 00 00) or (FF FF + 01 00) or (FF FF + FF FF)

Are you sure you said that in the right order?

Sorry, I meant 1D 1E

DaleStan wrote:1D 00 00 1E FF FF is *not* what you want; ditto on 1D 00 00 1E FE FF, 1D 01 00 1E FF FF, and 1D FF FF 1E FF FF.
If you want to carry all non-pax cargos, what you should be setting is 16 00 00 00 00 1D FE XX 1E 01 XX

That did not work. It did not allow me refitting at all if I specify 16 to 00 00 00 00. If I specify 16 to ff ff ff ff I get only first 32 cargos regargless what values I use for 1D 1E

DaleStan wrote:I'm not sure what the official line on setting undefined cargo class bits; replace those "XX"es with whatever you want; AFAICK, they don't currently do anything.

16 00 00 00 00 1D FE ff 1E 01 00 was tested. No result (not refittable vehicle)

George wrote:16 00 00 00 00 1D FE ff 1E 01 00 was tested. No result (not refittable vehicle)

Why didn't you mention that in the original post? I swear, if your intentions are to make me do as much extra work as possible, you're doing a great job.

Next time you post a problem, please say "this doesn't work, but neither does that nor that" when you have tried other things too.

Anyway, I'll look at it again when I have time, but probably not before the weekend.

Patchman wrote:

George wrote:16 00 00 00 00 1D FE ff 1E 01 00 was tested. No result (not refittable vehicle)

Why didn't you mention that in the original post?

Because only after DaleStan's post I tested that combination.

Patchman wrote:I swear, if your intentions are to make me do as much extra work as possible, you're doing a great job.

Sorry, it was not intended

Patchman wrote:Next time you post a problem, please say "this doesn't work, but neither does that nor that" when you have tried other things too.
Anyway, I'll look at it again when I have time, but probably not before the weekend.

Sorry again

George wrote:

Patchman wrote:

George wrote:16 00 00 00 00 1D FE ff 1E 01 00 was tested.

Why didn't you mention that in the original post?

Because only after DaleStan's post I tested that combination.

Then your English is off.

Although "was tested" is correct, it implies that you tried before I suggested trying it.

I would say "I just tried that, but it doesn't work either."

George yes, my message was written under the impression that you had tested it before. I'm sorry, perhaps I shouldn't draw such conclusions from someone for whom english is not the primary language.

Anyway, I've investigated again, and found that it's a bug in the general cargo class handling for all non-rail vehicles. The size of variable was declared as a byte, so only the first 128 IDs (116 rail plus the first 12 road vehicles) worked correctly. I've fixed this now for a66.

DaleStan wrote:

George wrote:

Patchman wrote:Why didn't you mention that in the original post?

Because only after DaleStan's post I tested that combination.

Then your English is off.

Should I add "Sorry for my bad English" into my signature?

DaleStan wrote:Although "was tested" is correct, it implies that you tried before I suggested trying it. I would say "I just tried that, but it doesn't work either."

Sorry, but could you explain the difference?

Patchman wrote:George yes, my message was written under the impression that you had tested it before. I'm sorry, perhaps I shouldn't draw such conclusions from someone for whom English is not the primary language.

Sorry for my bad English

Patchman wrote:Anyway, I've investigated again, and found that it's a bug in the general cargo class handling for all non-rail vehicles.

I'm confused. How can the cargo be supported different way for different vehicles? (Answer is not intended, because I'm not familiar with the code, but may be some short general explaining)

Patchman wrote:The size of variable was declared as a byte, so only the first 128 IDs

The byte has 256 values, isn't it? (me feels stupid again)

Patchman wrote:(116 rail plus the first 12 road vehicles) worked correctly. I've fixed this now for a66.

May be a pre version for tests?

George wrote:

Patchman wrote:George yes, my message was written under the impression that you had tested it before. I'm sorry, perhaps I shouldn't draw such conclusions from someone for whom English is not the primary language.

Sorry for my bad English

No, I have to apologize for shouting at you over a mere misunderstanding.

Patchman wrote:Anyway, I've investigated again, and found that it's a bug in the general cargo class handling for all non-rail vehicles.

I'm confused. How can the cargo be supported different way for different vehicles? (Answer is not intended, because I'm not familiar with the code, but may be some short general explaining)

Well, train vehicles fit in the first 128 of all vehicles in total, but RVs are (internally) IDs 116..203, then follow ships and planes. Only the first 128 IDs worked though.

Patchman wrote:The size of variable was declared as a byte, so only the first 128 IDs

The byte has 256 values, isn't it? (me feels stupid again)

The problem was, I declared 256 bytes, when it should've been 256 words. But then I accessed them as words, so the first 128 words (equal to 256 bytes) worked, the rest didn't.

May be a pre version for tests?

I'll post one tomorrow, I have to go sleep now...

Patchman wrote:The problem was, I declared 256 bytes, when it should've been 256 words. But then I accessed them as words, so the first 128 words (equal to 256 bytes) worked, the rest didn't.

May be a pre version for tests?

I'll post one tomorrow, I have to go sleep now...

I hoped you'll make a one before going to sleep to wake up and find, that it is tested and bugreports are waiting for you

Here's another preview. Aside from the aforementioned fixes, I also added an action 7 check to skip sprites if the cargo is not defined. I've also uploaded to the newgrfdemo directory updated versions of paper.grf and cargotrl.grf and their commented nfo files.

I also generally reworked the activation scheme, now all cargo definitions and GRM action D happen first in a separate pass over the file. Then all files are processed normally. This means that during activation, cargos and GRM are defined correctly no matter what the file order in newgrf(w).cfg is. This is especially important for the new action 7 test, as well as GRM operation 06, which returns the GRFID that has reserved a certain ID.

And the entire changelog: I will probably release a66 tomorrow night.

[edit] Attachments removed since a66 is out

Somebody recently added this line to the wiki:
PLAS | Plastic | 0040 Liquid
Is there a particular reason that this line is insufficient?
PLST | Plastic | 0040 Liquid

It seems to me that just copying the plastic stats from CargoDefaultProps and attaching it to PLST if the climate is tropic ought to work.

EDIT: I still don't really like it, but:
<@patchman> I think it's reasonable, actually

DaleStan wrote:Somebody

See the history. It's me

DaleStan wrote: recently added this line to the wiki:
PLAS | Plastic | 0040 Liquid
Is there a particular reason that this line is insufficient?
PLST | Plastic | 0040 Liquid

Yes. The same as for
wood - tropic wood
valuables - gold - diamonds
grain - wheat - maize
These should be different cargos. They may have different payments, I specify different capacities for them.

DaleStan wrote:It seems to me that just copying the plastic stats from CargoDefaultProps and attaching it to PLST if the climate is tropic ought to work.

Yes, unless you want to make them differnt in just one bit, even if it is a vehicle bit, not a cargo bit itself

DaleStan wrote:EDIT: I still don't really like it, but: <@patchman> I think it's reasonable, actually

Me too.

I've coded ECS alpha 0.
Now I'm looking for graphics artist who could donate their industries graphics for the ECS

are you not allowed to use michael blunks graphics or why do you not use his fish grounds