Extended Cargo Scheme (ECS) discussion

[George]

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

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

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.

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

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

They are reserved. there are 253 allowed

You don't set labels that don't belong to cargos.

why not?

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.

[Patchman]

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.

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.

[George]

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)

[Patchman]

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.

[krtaylor]

We carry tinfoil now! Great!

[George]

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?

[DaleStan]

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.

[George]

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

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

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)

[Patchman]

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.

[George]

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.

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

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

[DaleStan]

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."

[Patchman]

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.

[George]

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?

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?

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

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)

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)

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

May be a pre version for tests?

[Patchman]

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.

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.

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...

[George]

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

[Patchman]

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:

Code: Select all

2.0.1 alpha 66
- added PPC compilation platform (using gcc-mingw cross compiler)
- fixed endianness issues of makelang.c
- moved all Makefile user configurations to Makefile.local
- make action 2 var 7F accessible even when regular 40/60/80+x variables aren't
- fixed bug in helicopter rotor override handling causing random crashes
- fixed train crashes if road crossing was immediately followed by a PBS signal
- added cargo translation table for vehicle grfs
- added vehicle sound events 7,8,9; fixed event 4 to not happen while
  waiting at signal
- fixed veh var.43 being broken after loading savegames
- morecurrencies is now a proper bit switch
- fixed bug with refit cargo classes for non-rail vehicles not working
- fixed incorrect refit list display for wagons with no capacity
- fixed action 7/9 tests 9 and A
- fixed incorrect error message display if action B severity had bit 7 set
- added action 7 test B to check whether cargo is defined

I will probably release a66 tomorrow night.

[edit] Attachments removed since a66 is out

[DaleStan]

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

[George]

Somebody

See the history. It's me

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.

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

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

Me too.

[George]

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

[goalie]

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