Variable cargo output types?

[gmyx]

I have two questions for you all.

I'm doing some planing on a industry set and was wondering if it is possible that when an industry is built that it can choose what cargoes it produces? I was thinking along the lines of a random var 2 selecting a "branch" of an industry that has different properties. Example a "farm" could produce two of livestock, grain, wheat, etc.

I am looking at creating "generic" industries that are less static than what we currently see. I don't see the need (or benefit) for an industry to change it's output types long after it was created.

Secondly, is the limit to accept a maximum of 3 cargo types a hard limit or just to much work for too little benefit?

Thank you.

[Csaboka]

I'm doing some planing on a industry set and was wondering if it is possible that when an industry is built that it can choose what cargoes it produces? I was thinking along the lines of a random var 2 selecting a "branch" of an industry that has different properties. Example a "farm" could produce two of livestock, grain, wheat, etc.

It would be possible with minimal work on TTDPatch. The same is true for accepted cargoes, except that you would need to synchronize the acceptance of the individual tiles to the acceptance of the industry, so it would require more GRF code to work correctly.

Secondly, is the limit to accept a maximum of 3 cargo types a hard limit or just to much work for too little benefit?

It's a hard limit; many parts of the industry handling would have to be rewritten to allow more cargoes. Of course it's not impossible, you just need someone "dedicated" enough to do it

[gmyx]

I'm doing some planing on a industry set and was wondering if it is possible that when an industry is built that it can choose what cargoes it produces? I was thinking along the lines of a random var 2 selecting a "branch" of an industry that has different properties. Example a "farm" could produce two of livestock, grain, wheat, etc.

It would be possible with minimal work on TTDPatch. The same is true for accepted cargoes, except that you would need to synchronize the acceptance of the individual tiles to the acceptance of the industry, so it would require more GRF code to work correctly.

I expected the need for extra GRF code since this is an extra feature. It's just like any other features such as dynamic output amounts and others. I don't know how many GRF authors would use this feature, but it would introduce less predictability in industries, especially with prospecting. It would potentially also alleviate the limit of 37 on industries (why you would want so many, I don't know but it would be possible). It would also help with the overhead map not showing industries above the original amount.

There is no rush on this as I still writing up all of the properties in a spreadsheet for reference during coding, as well as planing. It does help to know that it's not major and can be done - it gives me direction on what implementation route I'm going to do.

Secondly, is the limit to accept a maximum of 3 cargo types a hard limit or just to much work for too little benefit?

It's a hard limit; many parts of the industry handling would have to be rewritten to allow more cargoes. Of course it's not impossible, you just need someone "dedicated" enough to do it

I quite expected that, but it doesn't hurt to ask.

[Csaboka]

It would potentially also alleviate the limit of 37 on industries

Well, you shouldn't have different industries merged into the same industry type. You must still have the same name, map color, prospecting cost etc. for all instances of an industry type; changing just the accepted and produced cargoes wouldn't be enough for a new type.

A more appropriate application would be a harbour industry, that accepts ("exports") raw materials and produces ("imports") cars, goods and similar things from them. The cargo types imported by the harbour could be selected randomly.

It would also help with the overhead map not showing industries above the original amount.

Do you mean the map legend? That thing is just hardcoded, it doesn't change no matter what GRFs you enable. I didn't feel "dedicated" enough to patch the drawing routine and adapt it to displaying up to 37 industry entries depending on currently enabled industry types. You shouldn't limit the number of industry types just because I was too lazy to do that part

[gmyx]

Well, you shouldn't have different industries merged into the same industry type. You must still have the same name, map color, prospecting cost etc. for all instances of an industry type; changing just the accepted and produced cargoes wouldn't be enough for a new type.

A more appropriate application would be a harbour industry, that accepts ("exports") raw materials and produces ("imports") cars, goods and similar things from them. The cargo types imported by the harbour could be selected randomly.

That is along the lines I was thinking of, the only properties that would change would be the in/out cargoes and possibly the associated graphics to match the subtle differences, hence branches. It would still be the same "generic" industry.

What I meant is that by having "generic" industries such as a farm that produces different cargoes but is still a farm with the fields and all. It appears like different farms in the TTD sense for route planing and such, just not completely different industries. So if I was to "plant" a new farm - I can't control what it produces, just the fact that there is a farm at that location.

Under current rules, for a similar system with 3 output cargoes (A,B and C) "randomly" chosen, it takes 3 industries to archive this effect: A+B, A+C, B+C. While with random outputs, it only takes one industry so that a farm is just farm. The more outputs, the more industries it takes to achieve the effect. That is what i mean by alleviating the limit of 37 on industries, it takes less industries to achieve the desired effect of very similar industries. To me it's like each farm is different from the others. It's not just take cargo fro point a to point b, you need to look at what is produced and plan accordingly.

For me the 37 industries limit is not an issue, my last count was around 20 if random outputs are possible. It balloons to around 33 without random outputs and many "duplicates".

Do you mean the map legend? That thing is just hardcoded, it doesn't change no matter what GRFs you enable. I didn't feel "dedicated" enough to patch the drawing routine and adapt it to displaying up to 37 industry entries depending on currently enabled industry types. You shouldn't limit the number of industry types just because I was too lazy to do that part

If only i knew assembler + i386... It's a minor irritant for me, thats all. After a while, you learn the colours and move on.

[m3henry]

...I didn't feel "dedicated" enough to patch the drawing routine and adapt it to displaying up to 37 industry entries depending on currently enabled industry types...

Is this on one of the patch todo lists?
P.S. you seem to be hyro quoting A LOT now

[Csaboka]

No, it isn't. I simply consider it too much work for too little benefit.

Generating the new legend data wouldn't be that difficult, but there isn't enough space in the window in the worst case. In the small map mode, there are two columns of legend, each of which can have space for seven texts. In other words, we have space for 14 industry names when the map window is in the small mode. We would need 37 to show all industry names when industry types are maxed out. Do you really want to spend two and a half times of the default legend space on an industry legend?

[gmyx]

No, it isn't. I simply consider it too much work for too little benefit.

Generating the new legend data wouldn't be that difficult, but there isn't enough space in the window in the worst case. In the small map mode, there are two columns of legend, each of which can have space for seven texts. In other words, we have space for 14 industry names when the map window is in the small mode. We would need 37 to show all industry names when industry types are maxed out. Do you really want to spend two and a half times of the default legend space on an industry legend?

That just gave me laugh at the image it put in my head -> kind of turning on all of the toolbars is OpenOffice. It doesn't leave much room for useful data.

Having never thought of that, it makes sense to leave the system has is. I can't image having a longer legend at the bottom of the map. The only way I can see it working is by removing the legend form the small map and only displaying it on the larger map, using more than 2 columns and more than 7 items for column. Even adding 3 items in a column could add 1/3 more legend space requirement to the large map.

Wow, it does seem like a lot of work for something so minor - a task for a slow day . But we digress from the original post.

[athanasios]

Nothing is impossible. Well, the following screenshot is from OpenTTD. Korenn did it there I don't know about TTDPatch.

[Csaboka]

OK, and why exactly did you post that picture? It feels like you're showing off how the OTTD devs are better because they can add something I can't.

Changing things in OTTD is easier, so it's no wonder that less things are in the "too much work for too little benefit" category...

[Hyronymus]

I fail to see any support in your post too, athanasios. If you really want the TTD devs to keep doing their best you should change your tone from condescending to constructive. And if nothing is impossible, how come you didn't fix it yet?!

EDIT: on second thought I wonder what this has to do with Graphics so I moved it to Suggestions.

[gmyx]

I don't want this to degrade into TTD vs. OTTD so I leave that aside and scratch my heads on what that image has to do with the overview map...

on second thought I wonder what this has to do with Graphics so I moved it to Suggestions.

I thought since this was NFO related, it was a best fit in graphics, but it can also easily fit into suggestions as well. I didn't want to cross post so decided on graphics. At least now it kind of cross posted via the "Moved" feature of phpBB.

[athanasios]

OK, and why exactly did you post that picture? It feels like you're showing off how the OTTD devs are better because they can add something I can't.

... you should change your tone from condescending to constructive.

Wrong interpretation of my post.
No I didn't want to show off or demean you. Your work we all admire and respect. Korenn is Tycoon (coder) not an OTTD developer, neither do I. I though that since he has already done that in OpenTTD his code could be used as a basis/guide for TTDPatch too, thus avoiding much hard work or that he might be willing to work on that for TTDPatch too. This is not condescending it is constructive.

...OpenTTD. Korenn did it there I don't know about TTDPatch.

= I don't know if it is reasonable to do, or if anyone has tried something similar in TTDPatch that I am not aware of on the past.

And if nothing is impossible, how come you didn't fix it yet?!

Don't ask me, ask Csakoka, he's got the answer, I just quoted from him:

Secondly, is the limit to accept a maximum of 3 cargo types a hard limit or just to much work for too little benefit?

It's a hard limit; many parts of the industry handling would have to be rewritten to allow more cargoes. Of course it's not impossible, you just need someone "dedicated" enough to do it

Certainly I am not the someone "dedicated" enough , and most important , as you already know, not even a coder.

...what that image has to do with the overview map...

:

Secondly, is the limit to accept a maximum of 3 cargo types a hard limit or just to much work for too little benefit?

I don't want this to degrade into TTD vs. OTTD...

Neither do I. Because, although I have a preference for OTTD, I PLAY BOTH and OTTD wouldn't exist without TTDPatch.

[Csaboka]

Wrong interpretation of my post.

I'm sorry, I've jumped to conclusions too quickly.

I though that since he has already done that in OpenTTD his code could be used as a basis/guide for TTDPatch too, thus avoiding much hard work or that he might be willing to work on that for TTDPatch too.

You should have put this sentence in your original post, that would have prevented the misunderstanding

Unfortunately, OTTD code can't usually be used to help patching, except to get the general idea of how a feature works. You still need to write it almost from scratch in TTDPatch. (BTW, the TTDPatch->OTTD direction is the same, as belugas can tell you.) I'm sure adding a fourth (or fifth, or twelfth) input cargo for OTTD is easy, but it's still very hard for TTDPatch.

[gmyx]

...what that image has to do with the overview map...

:

Secondly, is the limit to accept a maximum of 3 cargo types a hard limit or just to much work for too little benefit?

Sorry! I didn't notice that connection (I had forgotten about the second part of the original post). The context of your message made me think you refereeing to the overview map, not my second request.

[athanasios]

My turn to apologize! I attributed the work to Thgergo. My fault: coder of spinoff is Korenn.
(Thgergo did the grf for spinoff.)
I will edit my posts and correct.

[belugas]

Unfortunately, OTTD code can't usually be used to help patching, except to get the general idea of how a feature works. You still need to write it almost from scratch in TTDPatch. (BTW, the TTDPatch->OTTD direction is the same, as belugas can tell you.) I'm sure adding a fourth (or fifth, or twelfth) input cargo for OTTD is easy, but it's still very hard for TTDPatch.

The same can be said the other way around. Having the sources of TTDPatch for newindustries does not makes it easy to implement the corresponding feature in OpenTTD. The general idea can be extracted, but that's about it. As some points, i even had to draw flowchart diagrams and present them to Csaboka in order to verify the correct pattern.

As for having more input cargo, yes, it would be relatively easy, but i see no points in doing so. Plus, it would imply a new spec to support the additional cargo(s). Thus making it prone to errors of compability. Let say we will stick as close as close as possible to the original specs.
What Korren did is nice, i respect his work. But it's not because it can be done that it must be done.

The only liberty I took is regarding the number of industries : OpenTTD will be able to support 64 industries redefinitions. It was just a nicer number than 37. I understand why TTDPatch cannot have more than 37, but I do not have the same limitation. But that's the only transgression I took.

[gmyx]

As for having more input cargo, yes, it would be relatively easy, but i see no points in doing so. Plus, it would imply a new spec to support the additional cargo(s). Thus making it prone to errors of compability. Let say we will stick as close as close as possible to the original specs.
What Korren did is nice, i respect his work. But it's not because it can be done that it must be done.

While it does require the NFO specs to change to allow variable cargo types (both input and output) and possibly more that the current limit, I don't see that as being a good reason not to do it. I am aware that any change in TTDPatch is non-trivial and even simple changes can take time. Many features have been added because it adds to (O)TTD. What if we had that attitude to other features such as PBS or larger stations just to name two? Are you suggesting we freeze the NFO spec? Should we stop adding new features?

This has been done many times and throughout the NFO spec you see many minimum patch version requirements - meaning the NFO was extended many times and is a "living" document. It is equivalent to the Win32 API of the Linux kernel, they have been amened many times to accommodate new, innovative features.

The fact that Korren has done more than 3 input cargoes in OTTD means that there are at least two users (me and Korren) who would like to see those limitations change.

I sorry if this seems a little hash or rude, but my original questions was "Is this possible?". Basically the answer was "yes with some work". I am hopping that it does get implemented and asking politely for it to be implemented in TTDPatch. Whether you see it fit to implement these features in OTTD or not, thats up to you.

[DaleStan]

What if we had that attitude to other features such as PBS or larger stations just to name two? Are you suggesting we freeze the NFO spec?

Good try. But neither of those have anything to do with NFO.

And I think Belugas is suggesting that Open fully support the spec before extending it willy-nilly.

[Dave]

It is, indeed, one of the things that infuriates quite a few of the old patch veterans.

The new kid on the block comes in, and completely ignores some parts of the way things work, takes it over, extends it as it will, and leaves everyone else in turmoil.

Basically, as DaleStan said - OTTD can extend NFO when it fully supports NFO. Until then, I'm not sure what "rights" or whatever you're talking about apply.