Transport Tycoon Forums

andythenorth wrote: "5t of metal" and "5t of metals" are both about the same.

(Off-topic, needless nitpicking ahead ) I'd say that 5t of metals would imply that there are many different types of metal, where as 5t of metal could just be any old metal and sounds better anyhow. Not that it really matters, and I'm pretty sure you're already using the non-plural version.

I'll stop wasting everyone's time now...

@Pinga I think that's a good point, actually, not off-topic at all. It implies the plural would be more appropriate for FIRS usage specifically because it can cover a mixed consignment of aluminium, steel, (and perhaps even copper, tin, or any other metal types added by FIRS or a FIRS-alike at a later date). After all, you could have one train refitted for 'metals' serving both a steel mill and an aluminium plant.

I'd also vote for 'produce' for fruit [dictionary.com gives 'agricultural products collectively, especially vegetables and fruits' as one definition]. While at least one person has said they wouldn't necessarily recognise the term straight away, I feel 'produce' fits well with the tone of the OTTD game, and it's still flexible enough to cover other farm products (such as eggs, for example).

I'd prefer it remain '__t of metal' rather than 'metals'. An aluminum plant doesn't produce metals, just aluminum metal. [Or aluminium, as some say. ]

Thinking on it some more I suppose if one wanted to represent things in the most accurate way possible you'd have to do this:

steel mill produces __t of metal
aluminium plant produces __t of metal
vehicles carry __t of metals
factories/machine shops etc. accept metals

So singular for the producing industries, but plural for vehicles shipping it, as they can carry a mixture, and plural for factories and machine shops that can accept a mixture.

This demonstrates why it's a 50/50 call between using 'metal' and 'metals'. It means you can't really win, because the game engine isn't capable of using 'metal' in some places and 'metals' in others for what is internally the same cargo.

You're forgetting 'scrap metal'. It would be considerably mixed by its very nature of being scrapped from a variety of items.

I think a rule for consistency should be decided, such that all cargo adhere to either form: Fruit, metal, chemical; Or fruits, metals, chemicals. (barring translation exceptions where something sounds off)

andythenorth wrote:It's either a yard belonging to a construction firm or builders merchant, depending on how you want to interpret it. It's not a big deal either way

A contractor, perhaps?

Chemical isn't a plural ever. It would always have to be Chemicals.

Core Xii wrote:You're forgetting 'scrap metal'. It would be considerably mixed by its very nature of being scrapped from a variety of items.

No, I hadn't. 'Scrap metal' would stay as 'scrap metal', even though it may be a mix of metals. (And anyway, it's a separate cargo type.) English is far too idiosyncratic to be consistent, and plural collective nouns are an area of the language where it's hard to even see a pattern. If you're a native speaker you usually have a feel for what's right, but if you're not you might have a 3/4 chance of guessing right.

I think a rule for consistency should be decided, such that all cargo adhere to either form: Fruit, metal, chemical; Or fruits, metals, chemicals. (barring translation exceptions where something sounds off)

I think wording such a rule precisely and making it loophole-free would probably take more work than just producing a list. 'Fruit' and 'metal' can work as singulars, but 'chemicals' can't. Conversely, 'metals' and 'chemicals' both work in the plural form, but 'fruits' doesn't work; it just sounds like a bad translation. 'Coal', 'oil', 'fruit', 'chemicals', 'building materials', 'engineering supplies', 'goods'. With metal/metals I can make a case either way, but I suppose you get greatest consistency with the other cargos (incl. scrap metal) if you stick with 'metal'. I suppose it's handy to have steel and aluminium both being called 'metal'; saves a needless refit if you switch from transporting one to the other.

Core Xii wrote:A contractor, perhaps?

Yes, that would work.

Core Xii wrote: [*]I could have cloned a git repo and provided a patch but you're using mercurial

git patches work perfectly with hg, it is also recommend to make git patches with mercurial.

HG is able to clone git repos, not possible the opposite?

Greets
Ammler

Ammler wrote:HG is able to clone git repos, not possible the opposite?

There might be a command but I use a GUI. Don't see that option.

I'm going to patch the Finnish translation with the fixes once you commit the initial file.

Now, if I were to touch up the sprites once more, what would the recommended workflow be? Looking at the PSD, should I anti-alias each tile separately? Do the tiles have variations of themselves? (like a forklift randomly being or not being present) And to disrupt your work as little as possible, what should I do about all the cloned layers once I edit the original? (update them? delete them? keep as-is? I presume you shift them around to try industry layouts) Have you tried smart objects? I think they solve that problem - single image used in many places; Edit the original, changes reflected throughout.

Speaking of industry layouts, I've been wanting to try my hand at that, but it seems there's nfo coding involved, which I don't know. Is it useful at all to come up with new arrangements if you have to code them anyway? (which I presume to be the bottleneck in that process)

If I may comment, recently while making a UK game, I tried to transport food using refrigerated lorries, as happens in reality, and everytime i generate a loss over distances because food deteriorates in payment too quickly. I think that with the improvement in refrigeration, perhaps the drop in food payment should not be as steep as it currently is, as my vehicles are making a loss Unless you have an alternative solution that can be applied to the vehicles which can change this into a profit, but im fairly sure the problem lies with the cargo itself.

Leanden wrote:If I may comment, recently while making a UK game, I tried to transport food using refrigerated lorries, as happens in reality, and everytime i generate a loss over distances because food deteriorates in payment too quickly. I think that with the improvement in refrigeration, perhaps the drop in food payment should not be as steep as it currently is, as my vehicles are making a loss Unless you have an alternative solution that can be applied to the vehicles which can change this into a profit, but im fairly sure the problem lies with the cargo itself.

Transport across a shorter distance, perhaps? Further isn't always better, certainly not with RVs.

Hirundo wrote:

Leanden wrote:If I may comment, recently while making a UK game, I tried to transport food using refrigerated lorries, as happens in reality, and everytime i generate a loss over distances because food deteriorates in payment too quickly. I think that with the improvement in refrigeration, perhaps the drop in food payment should not be as steep as it currently is, as my vehicles are making a loss Unless you have an alternative solution that can be applied to the vehicles which can change this into a profit, but im fairly sure the problem lies with the cargo itself.

Transport across a shorter distance, perhaps? Further isn't always better, certainly not with RVs.

Transporting across a shorter distance is all well and good, but you shouldn't be penalised for wanting to transport over larger distances. Im playing a UK map and want to distribute food throughout the whole of the UK using RVs as is realistic.

It's completely possible to make UK maps of any size, 64x64 up to 2048x2048. Should transporting food throughout the map be equally profitable in all of these cases, since all of these maps are equally 'realistic'?

Please specify the map size, grfs/vehicles used and any other information (cost settings etc.) that may be relevant. Without such information I can't say anything relevant about this issue.

Hirundo wrote:

Leanden wrote:If I may comment, recently while making a UK game, I tried to transport food using refrigerated lorries, as happens in reality, and everytime i generate a loss over distances because food deteriorates in payment too quickly. I think that with the improvement in refrigeration, perhaps the drop in food payment should not be as steep as it currently is, as my vehicles are making a loss Unless you have an alternative solution that can be applied to the vehicles which can change this into a profit, but im fairly sure the problem lies with the cargo itself.

Transport across a shorter distance, perhaps? Further isn't always better, certainly not with RVs.

I noticed in BRBV the food trucks don't make money where as the other variants do over the same distance

Bob_Mackenzie wrote:I noticed in BRBV the food trucks don't make money where as the other variants do over the same distance

Check the cargo payment rates graph. Food payment decays faster than other cargos. See also http://wiki.openttd.org/Cargo_income

Hirundo wrote:It's completely possible to make UK maps of any size, 64x64 up to 2048x2048. Should transporting food throughout the map be equally profitable in all of these cases, since all of these maps are equally 'realistic'?

Please specify the map size, grfs/vehicles used and any other information (cost settings etc.) that may be relevant. Without such information I can't say anything relevant about this issue.

Im using BRBVS. My map is 2048x2048 based on the UK and Wales scenario from bananas. And as Bob says, the food trucks dont make profit where other vehicles do.

Terkhen wrote:

Bob_Mackenzie wrote:I noticed in BRBV the food trucks don't make money where as the other variants do over the same distance

Check the cargo payment rates graph. Food payment decays faster than other cargos. See also http://wiki.openttd.org/Cargo_income

I know that food payment decays faster, this is what i was requesting to be changed, as lets be honest, food transported and stored in game, would be done in refrigerated areas and so should last longer over long distances.

The cargo decay rates were originally balanced for 128x128 maps, but now we have clearly larger map sizes and the cargo rates should be adjusted to reflect that fact.

You mention that there is a 2048x2048 UK and Wales scenario. There are also 1024x1024 Antarctica and Australia scenarios. Which one has the right "realistic" scale?



IMO there is no point on trying to scale cargo payment rates automatically to scenario sizes, because as Hirundo already pointed they are not related to the "real distance" they might represent.

Another option would be adding FIRS parameters for controlling each cargo payment rates. Since FIRS has 31 cargos and payment rates are set by three parameters, this option would need 93 parameters.

You could also add a setting to OpenTTD that changes the "base distance" used for computing payments. This would allow the player to scale how all payment ratings decay with the distance. Personally if I play a big map, I expect payment to stay the same when I do lines of the same size than in smaller maps, so I wouldn't use the setting even if it existed.

Terkhen wrote:Another option would be adding FIRS parameters for controlling each cargo payment rates. Since FIRS has 31 cargos and payment rates are set by three parameters, this option would need 93 parameters.

Maybe three presets would be sufficient: slow decay, normal decay and fast decay. If someone really wants to tweak all nuts and bolts it should check out the source, do some tweaking and build a custom version.