Transport Tycoon Forums

I have recently tried to adapt one of my older scenarios to ECS, but found it quite hard to locate some industries - for example breweries, orchards, construction industries, forests etc. These have various limitations (should be built far from towns, close to water, in towns, in towns of a specified size...), which are useful in game itself but become quite problematic when placing an industry to an exact spot in a reality-based scenario is needed.

Is there a way, how to temporarily turn off these limitations for scenario construction and if it is not, may it be possible to have it implemented (probably via a switch)?

Prebral wrote:I have recently tried to adapt one of my older scenarios to ECS, but found it quite hard to locate some industries - for example breweries, orchards, construction industries, forests etc. These have various limitations (should be built far from towns, close to water, in towns, in towns of a specified size...), which are useful in game itself but become quite problematic when placing an industry to an exact spot in a reality-based scenario is needed.

Is there a way, how to temporarily turn off these limitations for scenario construction and if it is not, may it be possible to have it implemented (probably via a switch)?

As far as I can see there is no way to turn the limitations off short of recoding the grf. The best one can do (I did this) is to set up a scenario with one town and experiment with the placements so that you can get a feel for them and perhaps make a note or two.

wallyweb wrote: The best one can do (I did this) is to set up a scenario with one town and experiment with the placements so that you can get a feel for them and perhaps make a note or two.

Or just start random map and watch how industries are set.

Unfortunately the current version of ECS has poor description about placement of industry. Some times the defenition 'can be build near water' or 'near city' is too common. 4-5 squares from the center of a city is not 'near' ... but 'near' can be 7-8 and so on (supposed from the size of the city).

I'd really appreciate if ECS developers could provide more information on that in industry generation window.

T-pix wrote:Or just start random map and watch how industries are set.

This takes too long and you still have to figure out the maximum distance as the ai won't always build at the limit.

T-pix wrote:I'd really appreciate if ECS developers could provide more information on that in industry generation window.

I second the motion.

For give me for changing the subject, and espically if this has been discussed before, but I'm getting in late in this disscussion. I did skim through the topic before posting this.

I was wondering, Im using a version of the ECS that has the Food, and Beer cargos. I belive I read about this disscussion somewhere, but the beer tends to be a very hard cargo to get rid of, espically with towns that have a very fast rapid growth rate, to the little stadiums.

Food can also be a bit tricky to get rid off too, but not nearly as bad as the beer. Would it be possible to make indistries that only consume the beer? Like a NASCAR/Indy/F1 race tracks, or "proffesional" sports arenas (a dome arena for universal compatability with other expansion packs) that don't randomly pop up and remove themselves with the normal expansion of a city? possibly even give tourists, or normal passengers as a secendary cargo, or waste product. Other ideas could be a Casino, or grand hotel. for only in town buildings like the banks. Maybe make the casino use both beer and food. and I read somewhere about textiles? maybe the hotel could consume the Food and Textiles.

again sorry if this has been discussed before. Just wanted to get some oppinions.

> beer tends to be a very hard cargo to get rid of, espically with towns that have a very fast rapid growth rate, to the little stadiums. [...]

"Beer" isn´t a ECS cargo (at least not anymore), instead "beer" is (will be) a "sub-cargo" to "food".

I´ll change that in the NewCargo Set (my current implementation of ECS) with the next release version.

O/c, problems with "food" would stay to some degree, at least with the original TTD buildings.

regards
Michael

So brewerys would produce food? I'll have to go back and read through this tread again, Must have missed that part. I'll look forward to the next release.

By the way I wanted to say you guys do great work.

> So brewerys would produce food?

Yes, "food(beer)".

There are other sub-cargoes to "food" as well: "food(meat products)", "food(canned fish)", "food(frozen fish)", ..., and you may be able to refit freight vans according to your needs.

> By the way I wanted to say you guys do great work.

Thanks for your interest.

regards
Michael

Idea for the Town vector.

Cities (or even some industries, f.e. chemical) should 'produce' trash.

1. It should be transported to trash dumps outside the city or to some kind of trash burning facilities (it must be far from cities (as forests and fruit plantations)).
2. It also could be transported to chemical plant (as supplies or just for processing without affecting production level).

The amount of 'generated' trash depends on monthly delivered food&goods.
Its level should be displayed in city properties window.

Also the higher persentage of transported trash from the city should affect cities prosperity.

Belive thats been talked about before, and rejected, but for some reason I still like the idea would denafatly be unique looking cargos, Imagine a Trash barge, going to a ocean dump site lol.

I tried to re-code Serbian rail set to support ECS, but I had all time steel and water as hopper cargo. Then I thought I did something wrong, and then disabled all cargos except bulk. Same error! I downloaded again all ECS files again and same errors. Then I fastly checked through all ECS files and found following errors:
Machinery vector:
STEL coded Action 0 prop. 16 10
Basic tropic vector:
WATR 16 10; CERA 16 04
Agricultural vector:
WOOL 16 04; FERT 16 10; OLSD 16 10; FICR 16 20
Construction vector:
CMNT 16 90
Town vector:
TOUR 16 01
Wood vector:
WDPR 16 20
(Maybe there are other errors, I checked all vectors fastly.)

EDIT: two more errors:
Basic vector:
GLAS 16 04
Basic vector for arctic:
GLAS 16 04

I added the ECS Wood file, but it tells me i need to load ECS Town first, and when i do that snow comes..

I dont want snow Can i some how get the industries in ECSwoodw without getting the snow?

> I dont want snow

According to http://www.tt-forums.net/viewtopic.php?p=531504#531504 you want snow.

(if not, get rid of your snow-in-temperate file)

regards
Michael

More snow questions

Patchman's snowline.grf and DanMack's Canadian Set have parameters to set snowline height.
ECS has a snow feature for when the patch's tempsnowline switch is on.
As far as I can tell, ECS has no parameter setting for this and sets the snowline at the ttdx default.
If ECS and either snowline or canset are set to on, ECS will overide the other's parameter with the ttdx default snowline.

Is anybody aware of an ECS parameter setting or a workaround that will allow the other grf's parameter settings to prevail?

Note that as far as I know ECS must be loaded before any other grf, especially those that handle cargo.

Snowline height or even snowline at all isn´t a feature of ECS.

O/c, it could well be an (additional) feature of a .grf implementing ECS cargoes in the first place ...

regards
Michael

michael blunck wrote:Snowline height or even snowline at all isn´t a feature of ECS.

O/c, it could well be an (additional) feature of a .grf implementing ECS cargoes in the first place ...

regards
Michael

By ECS I meant the vector grf's by George.

I checked by doing a test game with all grf's off except the ECS grf's and snow was created in Temperate. I believe it is a feature of the ECS town vector. I believe there is a post much earlier in this thread that mentions that.

wallyweb wrote:ECS has a snow feature for when the patch's tempsnowline switch is on.
As far as I can tell, ECS has no parameter setting for this and sets the snowline at the ttdx default.
If ECS and either snowline or canset are set to on, ECS will overide the other's parameter with the ttdx default snowline.

AFAIK, George's GRFs define a variable snowline. The snowline is pretty low during the winter months, while only high mountains are snowy during the summer. It would be a good idea to allow turning it off, though.

Csaboka wrote:

wallyweb wrote:ECS has a snow feature for when the patch's tempsnowline switch is on.
As far as I can tell, ECS has no parameter setting for this and sets the snowline at the ttdx default.
If ECS and either snowline or canset are set to on, ECS will overide the other's parameter with the ttdx default snowline.

AFAIK, George's GRFs define a variable snowline. The snowline is pretty low during the winter months, while only high mountains are snowy during the summer. It would be a good idea to allow turning it off, though.

Thanks Csaboka,
When I get home from work later today I'll let it run through a year to see what happens. If it is indeed the seasonal effect then I can live with that, I think.

EDIT Further testing has been done with the following results:

ECSTownw.grf provides snow coverage in the Temperate climate that varies with the seasons, ranging in coverage from a dusting at level 15 during the summer to typical snow coverage down to level 4 in winter with levels 1, 2 and 3 above sea level being snow free all year.

Any grf's that offer snow coverage parameters will be overiden by ECSTownw.grf making it impossible to set a minimum year round snow coverage other than the dusting at level 15. It matters not whether those grf's are placed before or after ECSTownw.grf.

Conclusion: A suggestion to anybody making future revisions to ECSTownw.grf : Provide a parameter that allows the feature to be 1. turned off thus allowing other grf's to prevail with their own snow parameters and 2. Allow for a minimum year round snow coverage to be set as a parameter, thus allowing for player determined year round snowy peaks and seasonal coverage at lower levels.

michael blunck wrote:> I dont want snow

According to http://www.tt-forums.net/viewtopic.php?p=531504#531504 you want snow.

(if not, get rid of your snow-in-temperate file)

regards
Michael

Well, yes. But the snow in the ECStown can not be changed to different hights, which wallyweb pointet out.

But thanks for giving me an answer ppl.

wallyweb wrote:Any grf's that offer snow coverage parameters will be overiden by ECSTownw.grf making it impossible to set a minimum year round snow coverage other than the dusting at level 15. It matters not whether those grf's are placed before or after ECSTownw.grf.

Conclusion: A suggestion to anybody making future revisions to ECSTownw.grf : Provide a parameter that allows the feature to be 1. turned off thus allowing other grf's to prevail with their own snow parameters and 2. Allow for a minimum year round snow coverage to be set as a parameter, thus allowing for player determined year round snowy peaks and seasonal coverage at lower levels.

Let me refer to the second point only, because the first one should be addressed directly to George.

A rather similar suggestion had already been issued by Wile some time ago:

mb wrote:@Wile E. Coyote

> Most realistic IMO there would be 2 parameters: one to set lowest snow height in winter, and one to set lowest snow height in summer. But it'd be probably huge amount of work (if it's possible?).

It would be possible but need some additional work because I´d have to include more than one snow height table which would be selected according to the used parameters. Don´t know if this would be of any broader interest, though.
[...]

To have parameterized max and min snow height would be a lot of work resp a lot of overhead in the .grf.

In fact, to cover the whole spectrum of min and max snow heights would require n*(n+1)/2 snow height tables, i.e. for n=15 (max height), you´ll need 120 different snow height tables from which one would be used then according to the settings of those two parameters.

Personally, I won´t do it, at least not ATM.

regards
Michael