New cargos experimental test version - a55vcs4

[DaleStan]

It would have to be an industry that appears in/near a city: Waste Collection Point, and another that apears away from cities, a Landfill, but yes, it could be done.

[Csaboka]

Currently, the only things houses can produce are passengers and mail. Anyway, I think it shouldn't work this way. Just imagine: "Foobar Station. Waiting: 200 passengers, 10 tons of junk". Instead, some towns should have rubbish dumping grounds near them (but not too near), that produce junk and you can transport that to a waste incinerator. Rubbish dumping grounds shouldn't close down if they're serviced badly, but waste incinerators should.

[Flamelord]

Awesome; I'm glad it's possible. Anyway, I decided I wanted to contribute something besides ideas to the process, so I made this. It's a symbol (The kind that appear in the station window for waiting items) for Chemicals. Hope it's good enough to use (At least temporarily), and that I didn't do funny things with the colors (One of the greys might cause problems; the others are all borrowed colors).

[EDIT] The smallest image should be the correct size! [/EDIT]

[Csaboka]

Thanks for the contribution, but that chemicals GRF isn't meant to be played seriously. I changed the icon just to demonstrate that it's possible to do. If someone wants to do chemicals "for real", they should come from the oil refinery instead, and could go to a Chemical Plant generating artificial fertilizer for farms. (I don't know if this would be realistic, though)

[Flamelord]

Ah. Well, if someone needs it later, I suppose they could just steal it from here, then.

[wallyweb]

If someone wants to do chemicals "for real", they should come from the oil refinery instead, and could go to a Chemical Plant generating artificial fertilizer for farms. (I don't know if this would be realistic, though)

Seeing as how we would now have access to additional cargo types:

Oil Well/Rig (1. Oil => Refinery + Oil Fired Power Plant)
Refinery (1. fuel/goods => towns + 2. chemicals =>Chemical Plant)
Chemical Plant (1. plastics => auto factory + 2. fertilizer =>farm)
Auto Factory (autos/goods => towns)
etc. etc.

With Csaboka's excelent work, the possibilities are infinite.
Someone should create an Industry Set with variations for Temperate, Arctic and Tropic and whatever is deemed appropriate for Toyland (Per Uzurpator's split perhaps?). Who knows ... maybe Michael B. is already down in his secret lab putting something together as we speak

[Csaboka]

Since no one seemed to be testing the AI with newcargos, I went ahead and tried it myself. It turned out that there is a crash when the AI tries transporting a new cargo type, which is now fixed. The AI will still choose the wrong vehicle to carry the cargo, so after the route is built, it will start waiting forever for the correct vehicle to become available. To fix this, GRFs should use callback 18 to tell the AI which the right vehicle is. Chemi.grf is updated to show an example for this.

[Oracle]

Csaboka, I seem to have several problems with alpha 55 vcs with newcargos on. I can't transport any steel at all, with or without the steel mill demo GRF - it gets produced by the industry but none goes to any (train) stations (with selectgoods on). If selectgoods is off, steel goes to the (train) stations but there sometimes seem to be problems loading it then (sorry for the vagueness). Also, if selectgoods is off and steel is at the stations, the amount doesn't seem to be reflected in station action 2 variable D4 (whereas the amount of wood does seem to be).
Everything works as I would expect it to with newcargos off.

If you want me to elaborate further or to supply examples of (both new and old) savegames then I will try to do so.

[Csaboka]

A savegame and your config would be handy to reproduce your problem.

[DaleStan]

This savegame gets caught in a tight loop when I attempt to veiw the train list in a55vcs, but not in a55.

On the offchance that it's useful, I screenshotted Ollydbg too.

[Csaboka]

DaleStan: It's my fault again. I broke the code that sorts by cargo type while rewriting it to handle 32 cargo types. A fix will be uploaded soon.

[Csaboka]

Also, if selectgoods is off and steel is at the stations, the amount doesn't seem to be reflected in station action 2 variable D4 (whereas the amount of wood does seem to be).

With newcargos on, station variables 9C..EB work differently, so you can't use that variable safely anymore. This change was needed to make stations able to hold the new cargo types. I don't know how you can reproduce the same functionality without using them, though.

[Oracle]

A savegame and your config would be handy to reproduce your problem.

I've attached two games and my config files showing the problems. The first is the original game that I had the problem with, made pre-a55. The steel train never seems to get any steel at all. The second game was created under a55 vcs and shows what I should have mentioned in my first post: steel arrives at the station where cargo is delivered to the industry, but doesn't arrive at other stations, as you can see in the game.

Also, if selectgoods is off and steel is at the stations, the amount doesn't seem to be reflected in station action 2 variable D4 (whereas the amount of wood does seem to be).

With newcargos on, station variables 9C..EB work differently, so you can't use that variable safely anymore. This change was needed to make stations able to hold the new cargo types. I don't know how you can reproduce the same functionality without using them, though.

That's a real problem because I've used those variables in several stations that I've coded. I though that you might need to change them for newcargos, though, but I could really do with something to replace them with.
If you don't mind, could you explain how those variables work with newcargos on? Is it as simple as the first cargo to be used goes in the first set of variables and so on? If so, I could probably use that, but it would be nice to be able to check the cargotype too, if that's at all possible .

[Csaboka]

I've attached two games and my config files showing the problems. The first is the original game that I had the problem with, made pre-a55. The steel train never seems to get any steel at all. The second game was created under a55 vcs and shows what I should have mentioned in my first post: steel arrives at the station where cargo is delivered to the industry, but doesn't arrive at other stations, as you can see in the game.

Thanks, I can reproduce the problem and will try to fix it soon.

That's a real problem because I've used those variables in several stations that I've coded. I though that you might need to change them for newcargos, though, but I could really do with something to replace them with.

Nevermind, it's easier if I do some backward compatibility hacks than forcing every GRF coder to upgrade their stations. I still don't know how will the same data be accessible for new cargo types, though.

If you don't mind, could you explain how those variables work with newcargos on? Is it as simple as the first cargo to be used goes in the first set of variables and so on? If so, I could probably use that, but it would be nice to be able to check the cargotype too, if that's at all possible .

Instead of hardwiring a variable set to a cargo type, every slot has a "cargo type" field, so slots can dynamically be allocated/released. Unfortunately, the "type" field is in the station2 structure, therefore it's unaccessible from GRFs. Even if you could access the type, it would be PITA to find the slot for a given cargo type by using action 2s. This definitely needs some patch help, but I don't know how it will work.

[DaleStan]

Instead of hardwiring a variable set to a cargo type, every slot has a "cargo type" field, so slots can dynamically be allocated/released. Unfortunately, the "type" field is in the station2 structure, therefore it's unaccessible from GRFs.

40+x?

Even if you could access the type, it would be PITA to find the slot for a given cargo type by using action 2s. This definitely needs some patch help, but I don't know how it will work.

Idea: action 2 types 9x (meanings for the low nibble correspond to the variational 8x types):

Code: Select all

<02> <ID> <9x> <value> <num-vars> {<cargoID> <var> <var-adjust>(?)}... <defaultID>

which selects the first <cargoID> for which the corresponding <var>/<varadjust> == <value>.
<value> is a B/W/D, <num-vars> is a B, {<cargoID> <var> <var-adjust>(?)} is repeated <num-vars> times. Everything else is the same as in 8x variationals.
If a variable is inaccessible, the corresponding <cargoID> will not be chosen.

EDIT: or maybe <min-val> <max-val> instead of <value>?

Is that workable? (EDIT2: Or even useful? It'd require 12 near-identical action2s, and that still doesn't solve the accessing-new-cargo-info problem.)

[Csaboka]

Oracle: How exactly do you use those variables? Do you need the exact amount waiting, or just the fact that there's some cargo there? In the second case, I could just create a 4x variable that gives you the mask of cargo types waiting, and maybe a mask of cargo types accepted.

DaleStan: As I said, it'd be a real pain to do this via GRFs, while rather easy from patch code. I was thinking about a new variable type, parametrized variables. You'd have to give a one-byte parameter after the variable number, allowing the GRF to give info to the patch, not just ask for it. For example, variable 60 xx could be "amount waiting from type xx", 61 xx "ratings for type xx", 62 xx "time since type xx was last picked up" etc. If the given cargo type isn't present at the station, you'd get some default values.

[BobDendry]

Can't wait for new cargos to be fully working so we can make new industries and totally new cargo(eg. not renaming ones.) keep up the work!

[SHADOW-XIII]

oh I'm waiting for something like Cht: RebuildIndustries or Cht: ResetIndustry
so that all industries will recreate acceptance

[Csaboka]

Oracle: I've found the problem that caused the "steel never arrives" bug. It was my mistake; I initialized the FIFO data incorrectly. Until the fixed version comes out, a "Cht: ResetFifo" should solve your problems, at least temporarily.

[Oracle]

Oracle: How exactly do you use those variables? Do you need the exact amount waiting, or just the fact that there's some cargo there? In the second case, I could just create a 4x variable that gives you the mask of cargo types waiting, and maybe a mask of cargo types accepted.

No, I'm afraid I do actually use the amount that is waiting there for some changes depending upon that amount. I also have used the ratings for a specific cargo type at the station and whether that cargo type has been rated yet at that station (the latter to avoid giving completely bare graphics when a station will be used for unloading, for example).

That's a real problem because I've used those variables in several stations that I've coded. I though that you might need to change them for newcargos, though, but I could really do with something to replace them with.

Nevermind, it's easier if I do some backward compatibility hacks than forcing every GRF coder to upgrade their stations. I still don't know how will the same data be accessible for new cargo types, though.

I have a feeling that I'm the only coder using those variables and I don't mind changing my GRFs if that's helpful for you and saves you work.

As I said, it'd be a real pain to do this via GRFs, while rather easy from patch code. I was thinking about a new variable type, parametrized variables. You'd have to give a one-byte parameter after the variable number, allowing the GRF to give info to the patch, not just ask for it. For example, variable 60 xx could be "amount waiting from type xx", 61 xx "ratings for type xx", 62 xx "time since type xx was last picked up" etc. If the given cargo type isn't present at the station, you'd get some default values.

I had had a similar thought, although not as complete as yours. This would, of course, be fine for me, but it's yet more work for you.

Oracle: I've found the problem that caused the "steel never arrives" bug. It was my mistake; I initialized the FIFO data incorrectly. Until the fixed version comes out, a "Cht: ResetFifo" should solve your problems, at least temporarily.

Thanks. I only noticed it in test games so it wasn't really urgent but it needed fixing nevertheless.