ECS vectors v1.1.2 (by George) 19/06/2011

[wallyweb]

Or in TTRS?

That would imply that Zimmlock would have to cooperate with the Industry Set authors or that the Industry Set authors would have to design a grf to work with TTRS ... I think Michael said that neither of these steps is necessary or desirable. That leaves only one other way to implement it ... through the Industry Set.

I'm not so happy with this idea. Now you have to find a place to transport cargo to. With "in house industries" you will not think about it, but deliver cargo to any big town - it will accept anything you like. I do not want to make it this way. Goods are enough for this.
I'd vote for increasing the size of industry array. I'd prefer them to be industries to provide limitations. Or, as alternative, some sort of accepting limit for houses, and me doubts what is easier

If you are the author of the Industry Set then you would have control over how the feature is implemented. The Glass Works is an excellent example. If a player only wants to use the Basic vector with the Town vector, then as it is now Glass is produced with nowhere to go. You said it should go to towns, but there is nothing in the towns that currently accepts glass. As I see it you have three choices:
1. Have the Glass Works produce goods when there is no other vector loaded to accept glass.
2. Have the Basic vector add a new industry to accept glass and convert it to goods when there is no other vector loaded to accept glass.
3. Have the Basic vector add a new building to towns to accept glass when there is no other vector loaded to accept glass.
Which one would be easier for you to do?

===============================================================

On your conversation with Axlrose:

As the author of an Industry Set you have full control of what and how much is available to a town. It does not matter how much the greedy town wants to accept ... they must take what you provide and nothing more. So how do you control how much is available? The way you do it now ... by limiting the size of an industry's raw material stockpile and by limiting the production rate of the industry. If the industry stops producing because the stockpile is empty, then it is sorry town but no more stuff for you until we can make some more.

Hmm ... sounds like the real life oil industry ... lots of oil in the ground but nobody wants to take it out and when they do take it out, there are not enough refineries to process it, so the oil companies rob us blind with their exorbitant petrol prices.

[George]

If you are the author of the Industry Set then you would have control over how the feature is implemented.

I'm not the patch\OTTD coder, so my control is limited by GRF spec

The Glass Works is an excellent example. If a player only wants to use the Basic vector with the Town vector, then as it is now Glass is produced with nowhere to go. You said it should go to towns, but there is nothing in the towns that currently accepts glass. As I see it you have three choices:
1. Have the Glass Works produce goods when there is no other vector loaded to accept glass.
2. Have the Basic vector add a new industry to accept glass and convert it to goods when there is no other vector loaded to accept glass.
3. Have the Basic vector add a new building to towns to accept glass when there is no other vector loaded to accept glass.
Which one would be easier for you to do?

4) implement glass factory, that transforms glass into goods. The same way as I have factory that transforms steel into goods in ECS Machinery vector.

[wallyweb]

I'm not the patch\OTTD coder, so my control is limited by GRF spec

So we have to ask Michael how he does it ... Did he write a new spec?

4) implement glass factory, that transforms glass into goods. The same way as I have factory that transforms steel into goods in ECS Machinery vector.

That would be the same as 2. Have the Basic vector add a new industry to accept glass and convert it to goods
I would call it a Window Factory so as to not confuse it with Glass Works.

[George]

I'm not the patch\OTTD coder, so my control is limited by GRF spec

So we have to ask Michael how he does it ... Did he write a new spec?

No. He decided that unlimited acceptance is ok. I do not like this idea

4) implement glass factory, that transforms glass into goods. The same way as I have factory that transforms steel into goods in ECS Machinery vector.

That would be the same as 2. Have the Basic vector add a new industry to accept glass and convert it to goods
I would call it a Window Factory so as to not confuse it with Glass Works.

It is not. It exists REGARDLESS other vectors.

[wallyweb]

No. He decided that unlimited acceptance is ok. I do not like this idea

That is ok. You are the author of the set so you have control over this. If you do not include it then it is not implemented with your ECS vectors.

It exists REGARDLESS other vectors.

Ah! So you will add it as a permanent industry to process glass in temperate and arctic and process ceramics in tropic, producing goods in all three climates? I like that idea. However my Window Factory idea is not valid. Ceramics make very poor windows. But glass and ceramics make very nice ornaments made by artisans in their craft shops and sold to towns as goods.

That leaves only one question ... the dyes from the Chemical industry ... They can be used by the artisans in the craft shop to colour their goods, but what if the player does not use a Basic vector?

Perhaps the Basic Vectors could be made into "must have" the same as the Town Vector is a must?

[George]

No. He decided that unlimited acceptance is ok. I do not like this idea

That is ok. You are the author of the set so you have control over this. If you do not include it then it is not implemented with your ECS vectors.

That does not work this way. Houses are in TTRs.

It exists REGARDLESS other vectors.

Ah! So you will add it as a permanent industry to process glass in temperate and arctic and process ceramics in tropic, producing goods in all three climates?

Yes

I like that idea. However my Window Factory idea is not valid. Ceramics make very poor windows. But glass and ceramics make very nice ornaments made by artisans in their craft shops and sold to towns as goods.

And if we'd gather many of them in one place we'd get Glass factory. May be a name a bit confusing because of a glass works, but any suggestions are welcome.

That leaves only one question ... the dyes from the Chemical industry ... They can be used by the artisans in the craft shop to colour their goods, but what if the player does not use a Basic vector?

Well, in my plans in chemical industries would not produce cargo that you do not transport, so you will not have to waste tons of dyes

Perhaps the Basic Vectors could be made into "must have" the same as the Town Vector is a must?

No. Town vector is a must. We can think about adding industries into it ... I like this idea! I can move factory from ECS machinery vector to ECS town vector, improve the code to support no steel situation ... Excellent! I'll do it this way! I can also code it to accept dyes instead of wood products, but to accept wood products if steel/glass/dyes is undefined!
What do you thing?

[wallyweb]

That does not work this way. Houses are in TTRs.

Then Zimmlock's coder would have to do the work, and I don't think they would do it without an option to turn it off. In fact, I don't think they would do it for a very long time because Zimmlock is concentrating on other things. So I don't think you have anything to worry about.

I like that idea. However my Window Factory idea is not valid. Ceramics make very poor windows. But glass and ceramics make very nice ornaments made by artisans in their craft shops and sold to towns as goods.

And if we'd gather many of them in one place we'd get Glass factory. May be a name a bit confusing because of a glass works, but any suggestions are welcome.

Actually we'd get an artisan community ... so my suggestion remains ... "Craft Shop".

Perhaps the Basic Vectors could be made into "must have" the same as the Town Vector is a must?

No. Town vector is a must. We can think about adding industries into it ... I like this idea! I can move factory from ECS machinery vector to ECS town vector, improve the code to support no steel situation ... Excellent! I'll do it this way! I can also code it to accept dyes instead of wood products, but to accept wood products if steel/glass/dyes is undefined!
What do you thing?

I like it. But what will the factory accept if there is only the Town Vector loaded? (I know! It's a stupid question, but I had to ask it. )

[George]

That does not work this way. Houses are in TTRs.

Then Zimmlock's coder would have to do the work,

Csaboka

Perhaps the Basic Vectors could be made into "must have" the same as the Town Vector is a must?

No. Town vector is a must. We can think about adding industries into it ... I like this idea! I can move factory from ECS machinery vector to ECS town vector, improve the code to support no steel situation ... Excellent! I'll do it this way! I can also code it to accept dyes instead of wood products, but to accept wood products if steel/glass/dyes is undefined!
What do you thing?

I like it. But what will the factory accept if there is only the Town Vector loaded? (I know! It's a stupid question, but I had to ask it. )

Tourists? Mail?
I think it should produce some amount of goods from nothing.

[belugas]

I'd prefer them to be industries to provide limitations. Or, as alternative, some sort of accepting limit for houses, and me doubts what is easier

I'm sorry to barge in that late in the debate, but i would like to mention that increasing the industry array in TTDPatch is simply not possible, unless an incredible big amount of work is done.
But in the Other Program (to paraphrase Dalestan), you can benefit of 27 more industry slots. Not that it means migrating, but it certainly can point toward increased possibilities.

[wallyweb]

I'm sorry to barge in that late in the debate, but i would like to mention that increasing the industry array in TTDPatch is simply not possible, unless an incredible big amount of work is done.
But in the Other Program (to paraphrase Dalestan), you can benefit of 27 more industry slots. Not that it means migrating, but it certainly can point toward increased possibilities.

George joined these forums in 2003, about a year and a half earlier than my own arrival, so I am sure he is as well aware (if not more so) as I of the limitations of TTDPatch. George's excellent work grew out of those early beginnings based upon what was the standard of the day. His work at expanding the possibilities of this game have been nothing short of remarkable. I don't think he needs reminding of limitations which are really more a matter of desire on the part of the developers rather than an actual impossibility. Although I have not played the "Other Program", I understand that OTTD is an excellent game as witnessed by the number of its fans, but it also is a work in progress and has its own set of limitations. In this case, I would like to think that George wants his work to be equally enjoyable by both communities and that he has opted to satisfy the lowest common denominator. I think that he has been remarkably successful. Don't you?

[belugas]

I don't think he needs reminding of limitations which are really more a matter of desire on the part of the developers rather than an actual impossibility.

Not entirely true, sorry to contradict you. After speaking with Csaboka, and checking in the sources of TTDPatch(newindu.asm, lines 1227 and 1228), it appears the main reason of the 37 industries limitation has much more to do with the difficult (and tedious) task of patching the numerous calls the program is performing on the original industry array, which is, strangely enough, just big enough for holding 37 industries, i.e.: all the original industries. So I though I would add this piece of information when I read George's suggestion of

I'd vote for increasing the size of industry array.

( somehow, i managed to goof horribly at quoting the wrong citation... This quote is the one I was referring to... Sorry for the confusion). And I do agree totally with you as much as the qualifications and the knowledge of George. Don't worry. I hold him in the highest estime.

I would like to think that George wants his work to be equally enjoyable by both communities and that he has opted to satisfy the lowest common denominator. I think that he has been remarkably successful. Don't you?

Words of wisdom, and I honestly bow deep before them

[wallyweb]

... has much more to do with the difficult (and tedious) task of patching the numerous calls the program is performing on the original industry array...

This would largely explain the lack of desire on behalf of the TTDPatch developers.

Thanks for replying, belugas. I never really doubted your intentions. I was however, concerned that others might, but I think we cleared that up.

[DaleStan]

... has much more to do with the difficult (and tedious) task of patching the numerous calls the program is performing on the original industry array...

This would largely explain the lack of desire on behalf of the TTDPatch developers.

I mean, seriously. There are only 1214 instances of the value 37 (25h) in the TTD code. And several (possibly even half!) of them can be immediately dismissed as uninteresting. Shouldn't that make the job pretty straightforward?

(Anyone who wants to is welcome to it.)

[OzTrans]

I'm just going to say the following here, it may not be the right place ... and you are not going to like it anyway ...

ECS, it's definition and implementation is utter rubbish and should be scrapped immediately; industries, cargoes and the various vehicle sets will never ever work together properly, unless each vehicle set tailors it's cargo transportation system to specific industry/cargo sets.

A few days ago, a minor problem was pointed out to me. The CanSet didn't want to transport glass (GLAS with cargo class 0x0020 'piece goods'). Initially I believed it was my fault, but after having things checked out and found that everything was defined as in the wiki, I had a look what the ECS Basic vector actually says about glass; well, it has been defined with cargo class 0x0004 'express'. Well glass is fragile and probably should just be transported express and definetely not what the wiki says..

Further to this, I am really puzzled why crude oil, water, petrol, milk and honey are not distinguished; no wonder why there is so much food poisoning happening.

Another example, bulk products, like iron ore and coal, traditionally transported in open hoppers, really clash with cargoes like cement, cereal, potash, oil seeds, sulphur to name a few. All of them are defined simply as bulk, and would go into open hoppers together with the ore. I'm just wondering what residents along rail lines would say, after a train load of cement has been transported past their homes in open hoppers; and the rail company (after a sudden downpour) about the state of their rolling stock, when trying to unload, what was left in the hoppers, they found a slimy sticky mess of concrete just about to dry up.

What about oil seeds (cargo class bulk) and fibre crops (cargo class bulk piece cargo) !. Why a difference here ?

I could go on and on ... we leave that for another day, but that implementation of cargo classes must be re-engineered. It's basically impossible to make sure a vehicle set will work with any industry/cargo set. Many ECS sets have cargo classes that do not match the wiki, thus it is impossible to get the in- and ex-clusions right. There would be constant modifications necessary, whenever a new cargo has been invented or a cargo set changed. I'm not going to tell what you should do, because you are not going to listen anyway ... but there is a sure system that would work without having to make changes to TTDPatch or OpenTTD; i.e. any vehicle set can work with any industry/cargo set without any set having to be aware of the other.

Now, you can start again, but do get it right this time ...

[DaleStan]

Many ECS sets have cargo classes that do not match the wiki, thus it is impossible to get the in- and ex-clusions right.

And George is clearly of the opinion that it's not his job to fix the wiki. I guess that means it's yours.

OY! George! Fix!

[George]

Many ECS sets have cargo classes that do not match the wiki, thus it is impossible to get the in- and ex-clusions right.

And George is clearly of the opinion that it's not his job to fix the wiki. I guess that means it's yours.
OY! George! Fix!

OzTransLtd is right for alpha vectors - some cargo classes were set wrong (not as in wiki). I had a task to fix them in todo list for a long time, Ok, I'll fix them ASAP.
The second point is what classes should cargoes on wiki have. If OzTransLtd would like to suggest some other values - fine he can simply change the wiki. If no one would disagree, I'll change that in the vectors, it is not hard at all. If some change would cause a question - a discussion can be done here. At list I do not see a big problem yet. I do not see what to redo. At least now I see only a place for bug fixes.

[George]

I did not expected the post like "Hey you, idiots, you did it bad because it does not work with my super puper set" form the person like you. Sad.

Instead, you could simply point out what cargo is defined wrong on the wiki and what in the GRF file. A question for a simple bug fix.

I could go on and on ... we leave that for another day, but that implementation of cargo classes must be re-engineered.

Suggest a list of cargo classes and a list of classes for ECS cargoes.

Many ECS sets have cargo classes that do not match the wiki

Why not to make a bug report, like Wile did?
Machinery vector:
STEL coded Action 0 prop. 16 10 instead of 20
fixed

Basic tropic vector:
WATR 16 10 instead of 40; CERA 16 04 instead of 20
fixed

Agricultural vector:
WOOL 16 04 instead of 20; FERT 16 10 instead of 30; FICR 16 20 instead of 30
FERT 70, fixed

Construction vector:
CMNT 16 90 instead of 10
CMNT 50

Town vector:
TOUR 16 01 instead of 05
fixed

Wood vector:
WDPR 16 20 instead of 30
fixed

Basic vector:
GLAS 16 04 instead of 20
fixed

Basic vector for arctic:
GLAS 16 04 instead of 20
fixed

Files uploaded

There would be constant modifications necessary, whenever a new cargo has been invented or a cargo set changed.

Why?

I'm not going to tell what you should do, because you are not going to listen anyway ...

What made you to think so?

but there is a sure system that would work without having to make changes to TTDPatch or OpenTTD; i.e. any vehicle set can work with any industry/cargo set without any set having to be aware of the other.

What is it? I can't understand after reading your post, what do you suggest except bug fixing?

Now, you can start again, but do get it right this time ...

[sarcasm]Thank you for permitting us to do it, oh mighty OzTransLtd! But how can we do it right without you wise guiding?[/sarcasm]

[Zimmlock]

Mmm Its hard for me to follow this discussion, but maybe, i say maybe its time for a total different approch. At first, if this cant be solved i would say keep TTRS the way it is. But i am not unwilling to accept new ideas, we have to evolve.
I allways have some kind of problem with the enormouse variety of GRF's and would like to see many merge. For example TTRS and all light industry ECS GRF's. But then evolvement of towns have to be rewritten. When a town grows its industrys have to migrate to the out skirts excluding the industrys that are economicaly profitable, when not that particular industry closes down and migrates to the industrial zone. When a town is full grown i see different zone's, in the center you have the City (zone 4) with the zone 4 buildings, Banks, Hotels and Statues, in the next zone (zone 3) you find the zone 3 buildings, some Hotels, Petrolstations, a few small Statues, maybe one or two "old" surviving industrys that are serviced well (if the supply of material for some reason stops the industry closes and migrates). Zone 2, the zone 2 and zone 1 buildings, some Petrolstations the Shoppingmalls. And zone 1 the industrial zone here are all medium light industrys consentrated like factory, glassfactory, Timberyards.
All other "heavy" industry like coalmines, powerplants, steelmills, carfactorys and so on exsist/can be build in zone 0.

To have some kind of a system here discribed all TTRS an ECS grf's (Vectors) have to be merged i guess. I am not a coder even wors i do not understand this and do not know what can and or cant be done. But i know in OpenTTD more is possible and maybe Csaboka is right when he felt blocked in his development in the traditional TTDPsystem, we slowly grow to the end of the Patch.

After rereading what i wrote i dont know if i am still ontopic, we need a grand discussion where we want to go. There are many individuals and small groupes that make thinks for THE game. But more cooperation is needed, infact we need more a vision where to go, so we can weave a net and create a "new" game.

Best regards
Zimmlock

[DaleStan]

I could go on and on ... we leave that for another day, but that implementation of cargo classes must be re-engineered.

Suggest a list of cargo classes and a list of classes for ECS cargoes.

Here's a thought: Try not setting more than one of "piece", "bulk", and "liquid" for any given cargo.

Liquid cargos are, well, liquid. The other two are solids. Bulk can be stored in hoppers. Piece cannot.

I am really puzzled why crude oil, water, petrol, milk and honey are not distinguished; no wonder why there is so much food poisoning happening.

Another example, bulk products, like iron ore and coal, traditionally transported in open hoppers, really clash with cargoes like cement, cereal, potash, oil seeds, sulphur to name a few. All of them are defined simply as bulk, and would go into open hoppers together with the ore.

And as for you, we have six more cargo classes waiting to be defined. Get on it.

[OzTrans]

... If OzTransLtd would like to suggest some other values - fine he can simply change the wiki ...

If I were to do that, then every other cargo/industry set and/or vehicle set developer would be up in arms. Once the cargo classes have been defined, they are set in concrete; and once a cargo by its label has been defined with a particular cargo class then that too is set in concrete. Further adding a new cargo must match the cargo class of a similar already defined cargo, if such cargo already exists. The cargo class is the interface between industry/cargo sets and vehicle sets, change the class for a cargo and you'll upset the apple cart. That is precisely what seems to have happened; unfortunately I did not take a snapshot of the Cargo Table from the wiki when I did my cargo allocation scheme. Now I cannot prove it did actually happen.

... you could have simply pointed out what cargo has been defined wrongly in the wiki and which one in the GRF file. A request for a simple bug fix. ...

Of course, I could have done that, but that would not solve the problem. The foundation of your ECS sets are based on the ECS implementation, which is totally flawed. Whatever you do, the ECS sets will come crashing down sooner or later, unless vehicle set creators tailor their sets to your ECS sets and keep their sets updated.

... Suggest a list of cargo classes and a list of classes for ECS cargoes. ...

A discussion of a new Cargo Transportation Scheme [CTS] will continue here.

Note : ECS implementation and definition has little to do with ECS sets by George, there is nothing wrong (apart from a few bugs) with them. It's the implementation of the Extended Cargo Scheme [ECS] that is flawed, unless it is scrapped and re-engineered there will always be problems, and vehicle sets will never agree with cargo sets.