Transport Tycoon Forums

I'm using a box, it's called a computer, that does all that work for me ... translating, merging, text ID allocation and making sure they get referenced correctly - This doesn't cost me any time.


No, at this stage, we do not use class based cargo; all is done via individual cargo types. If a new one comes along, like milk and honey, we do not want that suddenly a crude oil tank car, being defined as liquid cargo freight wagon, starts transporting these cargos. If we want the new cargo, it is going to be added, almost instantly, using the above box.

At least the milk should require refrigeration, and I rather doubt the crude oil tanker has a refrigeration unit. (ie prop 29 should be set to 80 00. Or, more likely, 84 00.)


FVO "almost instantly" that equal "once the users realize that there's a new version and download it"?

>>> ... and while you are fixing this, you can make this feature an 'opt out of it' one as I do not wish to have it [...]

>> Yeah, using saved time for a reasonable translation of all those texts.

> I'm using a box, it's called a computer, that does all that work for me [...]

Cómo funciona esto? Quisiera pedir hora para el tratamiento.

Michael

Michael, you should know the rules!!! English only!

James

I was of course giving only a silly example ... I haven't followed all those new cargo scheme discussions, so I do not consider my self qualified to remark any further; except that I think the whole thing with new cargo and industries will require modifications to vehicle sets anyway. I favour that vehicle set creators do decide what is in and out.

Now to something more interesting ...

we have this feature that lets us check what alpha version the .grf is being loaded and we use that if we have used features that where not available in earlier alpha's. But what do gamers see when they use an earlier version, they get this message of invalid sprites instead of the message to use a more recent alpha and they get the impression that .grf is faulty but of course it is not.

Can that be changed, that when an invalid sprite is detected, that the .grf is processed from the beginning anyway at least until action-08 is found and carry out those checks (action-09). It would be nice to see the intended message and not the invalid sprite one.

    1 * 9     09 8B 04 05 39 02 0A 02 01
    2 * 19    0B 03 1F 00 32 2E 30 2E 31 20 61 6C 70 68 61 20 35 37 00 

What's the difference between the grfs in those screenshots?

Anyway, the patch always keeps the first error message, if the error is fatal the grf is marked as bad and never processed again.

FWIW, I have never heard of a refrigerated railway tank car. In the UK, until the 1960s when road transport took over, milk was transported either in tankers externally identical to oil tankers (but often glass or stainless steel lined, for hygeine, and painted white or silver to keep them cool), or, for less-than-industrial quantities, in churns in (again unrefrigerated) vans or mail cars.

Back on topic, I'm following this topic with interest, and will endevour to make my train sets as newcargos-compatible as possible.

I commented the 'invalid sprite' out, so that I could see my message working. The sprites (in prev post) are my very first two sprites.

That's the 'invalid sprite' reported, which is perfectly ok in a57 but not in a52 :

3380 * 15    02 00 9E 82 60 28 00 FF 01 FE FF 00 02 41 FF

But when I check within a started game and see that grey box with the triangle; there is the graphics ID and all the text from action-08 together with the 'invalid sprite' message and not the 'incorrect alpha' one.

Hmm. Yes.

Normally action B is skipped during initialization. If the "invalid sprite" message is generated during initialization, it becomes the first message and is retained.

There is an undocumented (apparently...) way of forcing action B to apply at initialization: set bit 7 of the severity. However in my brief tests, that didn't work anyway.

This is rather unsatisfactory...

Just tried that ...

The linter doesn't like that idea either :

//!!Error (150): Invalid severity byte.
    2 * 19    0B 83 1F 00 32 2E 30 2E 31 20 61 6C 70 68 61 20 35 37 00

Forcing it through; I get the messae '-1990 ton of grain'.

I'll leave that then with you.

Well, it's undocumented, hence I had no way[0] of knowing about that. Local source was just fixed; it'll be in the next NFORenum release. (Soon after a66, assuming I get all my as-yet-untested changes working.)

Another workaround is:

0*0 09 <test goes here> 02
0*0 0B <...>
0*0 09 <test that's always true> 00

In this case, the severity can have bit 7 either set or un-set.

[0] OK, so I could have read the TTDPatch source, but that doesn't strike me as a useful way to spend my time.

How could you have known, nobody is blaming you. I just mentioned it so you could cater for it once it is working.

DaleStan, many thanks for the workaround, it works fine; but if I put the 2nd act-09 after act-08, it works even better. That way, I get the message in the startup screen and if proceeding into a game, not only is the message shown in the .grf window but the graphics file's description, ID etc is also there. Perfect.

1 * 9       09 8B 04 05 39 02 0A 02 01
2 * 19      0B 03 1F 00 32 2E 30 2E 31 20 61 6C 70 68 61 20 35 37 00

3 * 184     08 06 43 41 53 61 ...

4 * 9       09 8B 04 04 3A 02 0A 02 00

Trying to build a new vehicle crashes the game.
If all the ECS files except town vector are removed from newgrf.cfg, the game is crashed while landscape generation

This may or may not be related to George's problem:

1. I am using alpha66 and I do not have any ECS files loaded.
2. With all of George's lv's turned off I am able to build the TTD trucks without any problems.
3. With George's lv's turned on I can build the lv busses.
4. With George's lv's turned on I can not see any trucks, lv or TTDX, to build.
5. With George's lv's turned on the GRF Status window appears as below.

I confirm the problem with actions 7 and B.
When I test the condition 6 (GRF loaded) in action 7 I get the true value even if the grf is below in the newgrf.cfg
I think it means all the GRF should be recoded due the new action B handling in alpha 66

I му got problem with making AI manager working in alpha 66. Previously, the following check allowed to check the required files

//  Check for other files being loaded
//  Check for Mercedes trucks. Skip the rest of file if will not activated
   44 * 9    07 88 04 08 4D 65 6F 07 02
   45 * 62    0B 02 1F FF 4C 6F 6E 67 20 76 65 68 69 63 6C 65 73 20 76 33 BE 2E 20 4D 65 72 63 65 64 65 73 20
            54 72 75 63 6B 73 20 66 69 6C 65 20 68 61 73 20 74 6F 20 62 65 20 6C 6F 61 64 65 64 00 00
   46 * 6    07 83 01 03 04 00

Now it reports the error, while the file is loaded. (the previous rar contains all the reqiured files)

Nobody seams to have noticed this yet. Only happens in A66:

When managing a competitor and buying some RVs in Company colours, the RVs get the company colour of the main player 1, not of the managed company. Seams to happen only since A66. I don't know if it is happening also with trains, airplanes or ships, but for sure with RVs

Stupid me forgot .cfg files and savegame. Hope you can use the screenie anyways for something. Maybe I can post it tommorrow.

Minor flaw with refitting capacity callback (15), been around for quite some time. I can live with it, but it may be worth investigating it.

When refitting from one cargo type to another, where the amount of cargo is the same but the weight of one unit of cargo is different, refitting fails to set amount/weight correctly.

Examples :

- refitting primary cargo Goods (30 crates = 15 t) to Food (30 t) results in Food (15 t);
- refitting primary cargo Food (30 t) to Goods (30 crates = 15 t) results in Goods (60 crates);
- but, refitting primary cargo Goods (30 cartes = 15 t) to Food (31 t) will be correct > Food (31 t), because amount 30 / 31 is different.

What does the callback return in each case?

Unless there's a bug, cargo weight should have no bearing when using the capacity callback.