Improvement Ideas and Discussion

Automated workers never make wise decisions anyhow. This is more about the player not realizing that a plot should still be re-improved because it's no longer up-to-date with the current improvements at their tech level. We should not be relying on automations to determine this for us either.

If we can't allow an upgrade from type A to type B because A might be better off upgrading to type B or C depending on the situation then we need to split up type A into two differing types, one that would go to type B and one that would go to type C when upgrading.

Thus these problems should have the following solutions:

Scavengening camp no longer upgrades.
This was done because the two bases one were merged, you have to rework it into the correct type based on the resource type it is sitting on.

Click to expand...

Then we need more Scavenging Camp types that correlate to the differing valid upgrades.

Grape Picking Camp does not upgrade into Winery because Winery removes various features.
Plant Picking Camp does not upgrade into Plantation because plantation removes various features.

Click to expand...

I could probably solve this by making it so that when they upgrade these improvements remove the features that the upgrades would remove if built. So long as this doesn't happen too excessively I think it would make sense to go about it this way.

The same reason is for why Special Stone Workshop not upgrade into Quarry, and Stone Tools Workshop not upgrading into mine.

Click to expand...

Not sure which of the above two reasons you're saying applied here or both but the adjustment I'd make would repair the second and the first should be addressed the way those would be.


The worker automations are a far more complex issue and would take a lot of time to disseminate. No two players will ever agree as to what their workers should be doing by default so I'm really confused as to why any player would automate them in the first place.

Somewhere after Transhuman they make OK decisions about improvements. Sometime after paved roads but before the next route they they make OK decisions about roads.

Thunderbrd said:

Automated workers never make wise decisions anyhow. This is more about the player not realizing that a plot should still be re-improved because it's no longer up-to-date with the current improvements at their tech level. We should not be relying on automations to determine this for us either.

Click to expand...

Then this is a problem with automated workers which needs to be fixed. Furthermore (assuming we fix it) why can't we rely on automations to determine this? Overall those decisions are not that hard, wouldn't that be more ideal in the long rnu resulting in less micromanagement?

If we can't allow an upgrade from type A to type B because A might be better off upgrading to type B or C depending on the situation then we need to split up type A into two differing types, one that would go to type B and one that would go to type C when upgrading.

Thus these problems should have the following solutions:

Then we need more Scavenging Camp types that correlate to the differing valid upgrades.

Click to expand...

That is how scavengeng camps used to be, there were two. But if upgrade chains were being broken because of the forest issues, I saw no reason not eliminate the redundancy of the unnecessary duplicate scavenging camp either.

Spliting up improvements like that though IMO is adding a level of unnecessary complication and duplication which only causes an increase in the tedious work to be done later for changes.

Again the real solution is to make automated workers smart enough to know how to rework the plot into the next better improvement when the tech becomes available.

I could probably solve this by making it so that when they upgrade these improvements remove the features that the upgrades would remove if built. So long as this doesn't happen too excessively I think it would make sense to go about it this way.

Click to expand...

Yes that is one possibility. Though you then might get others complaining about losing the forest anyway, and whatever gains the forest provides (health, pollution control...whatever..) Furthermore if your going to have an upgrade strip the forest/feature people are going to the production gain from it also.

Not sure which of the above two reasons you're saying applied here or both but the adjustment I'd make would repair the second and the first should be addressed the way those would be.

Click to expand...

It was the latter forest/feature reason. As for the first, again we shouldnt be forced to create uneeded duplication. I did think about merging the special stone workshop and stone tools workshop, but didn't. But I think we could get away with doing so and should if we fix worker automations.

The worker automations are a far more complex issue and would take a lot of time to disseminate. No two players will ever agree as to what their workers should be doing by default so I'm really confused as to why any player would automate them in the first place.

Click to expand...

Yes they are, and it will be hard but not impossible, and ultimately will make the mod better. (plus it will help the AI)

The upgrade split problem with scavenging camp is not a problem at all the resource determines exactly what it can upgrade to. It upgrades to either a camp or a pasture. There is no confusion or option since they can only be placed on resources and therefore each resource determines the upgrade.

Merging Stone Tools Workshop and Special Stone Tools Workshop is more problematic since the Stone Tools Workshop does not require a resource on the plot for it to be built.

Dancing Hoskuld said:

The upgrade split problem with scavenging camp is not a problem at all the resource determines exactly what it can upgrade to. It upgrades to either a camp or a pasture. There is no confusion or option since they can only be placed on resources and therefore each resource determines the upgrade.

Merging Stone Tools Workshop and Special Stone Tools Workshop is more problematic since the Stone Tools Workshop does not require a resource on the plot for it to be built.

Click to expand...

And that is the reason I didn't merge STW & SSW in particular. However as I said, if worker automation was reliable then they would rework (ie not an upgrade, but replacement via worker action) then you could merge them. This is because replacing the merged version of the stone workshop with a quarry will ONLY be possible if a quarry resource is below it, whereas in all other cases it would replace it with a mine.
It is a very simple rule.

Sine we are on the subject, here is a completely different idea regarding improvement upgrade chains:

Make them work like upgrading units instead.

There are no 'upgrades' chains in the sense of it being controlled via XML or being done via worker action replacement.

There is just a button on the city menu asking if you want to upgrade all improvements in this city radius, or a right click menu on the improvements at the map level that says "Upgrade improvement" and both tell you how much gold it costs to do so, and does so instantly if you do.

Plus it gives people something else to spend their excessively accumulating amount of gold on.

Here's the problem with both approaches...

It requires me to do it.

I'm swamped with bug reports and desperate to get somewhere with the projects I've already outlined for myself and honestly, worker automations are not ranking high in the 'I care' department. I prefer not automating workers as I've never seen an automation system work the way I'd develop my territory and I'm pretty sure if I set things up so that they did do things the way I'd always do them players would complain that they aren't doing things the way they do them. No matter who set up automations it would never be right for everyone. In fact, the way it is currently is probably quite ideal for the AI. Though it wouldn't be so good for a human player. Again, it's terribly complex and awesomely boring to work on. And if you think the "level of unnecessary complication and duplication which only causes an increase in the tedious work to be done later for changes" is bad, try working on the automation section of the worker AI.

The second idea is a crowd pleaser yes... and it would have to still rely upon XML to define what an improvement would upgrade into (or set of improvements it could upgrade into at least). BUT it represents another very huge endeavor. I'm more inclined to work on this but I promise it will fall into the vast pool of projects to be undertaken 'at some point' and potentially be years before it can be addressed. Maybe... I'll spend some thought on it anyhow and if I can envision how the project would go it might be more doable - the biggest problem will be the UI... I can setup a lot but I'm not skilled enough with the UI to provide the button (I've already got two buttons requested for the city screen and the art loaded and everything on the dll side done, waiting on someone to help in that department from the UI side (in the Python.))

So that's a good idea I think yes.

But in the meantime, a more immediate solution should be made possible... personally, I really liked being able to strategically set an improvement in a spot where it would eventually upgrade into an improvement that would normally, if built, destroy the feature on that plot, but since it upgrades does not. I felt that was a strategic foresight benefit a clever player could derive. Of ALL the options and pros and cons behind them, I have to say I liked the way it was on that matter better than anything we've proposed so far (though that last concept was a good one - just might take a while to be developed.)

Thunderbrd said:

I'm swamped with bug reports and desperate to get somewhere with the projects I've already outlined for myself and honestly, worker automations are not ranking high in the 'I care' department. I prefer not automating workers as I've never seen an automation system work the way I'd develop my territory and I'm pretty sure if I set things up so that they did do things the way I'd always do them players would complain that they aren't doing things the way they do them. No matter who set up automations it would never be right for everyone. In fact, the way it is currently is probably quite ideal for the AI. Though it wouldn't be so good for a human player. Again, it's terribly complex and awesomely boring to work on. And if you think the "level of unnecessary complication and duplication which only causes an increase in the tedious work to be done later for changes" is bad, try working on the automation section of the worker AI.

Click to expand...

For me, it would be a HUGE improvement if the "Build Network" automation is doing the following:

- Build the highest available route between cities.
- Build the required improvement over a resource to get it. If necessary, remove existing improvments.
- Do not build Forts (at all...)
- Don't do anything else beside this.

This would remove the annoying route management and finding new resources once researched. Routes will grow naturally between big cities. And if you need a specific route fast, you can still build it manually.

Faustmouse said:

For me, it would be a HUGE improvement if the "Build Network" automation is doing the following:

- Build the highest available route between cities.
- Build the required improvement over a resource to get it. If necessary, remove existing improvments.
- Do not build Forts (at all...)
- Don't do anything else beside this.

This would remove the annoying route management and finding new resources once researched. Routes will grow naturally between big cities. And if you need a specific route fast, you can still build it manually.

Click to expand...

Agree on most of this.

The one exception:

- Build the required improvement over a resource to get it. If necessary, remove existing improvments.

Click to expand...

Only if you do not already have that resource and this tile is a town.

I always thought Build Network was all about building connections, roads, between cities and to resources. That it at all incorporates Improvements is a disappointment to me.

Cheers

BlueGenie said:

I always thought Build Network was all about building connections, roads, between cities and to resources. That it at all incorporates Improvements is a disappointment to me.

Cheers

Click to expand...

I was a bit disappointed when I learned that too... that's really all it should be - that might actually be useful provided it doesn't send workers out beyond the borders to be gleefully eaten by a pigeon.

Build Network is 'build a trade network' it will build improvement that will hook up a resource, but isn't supposed to build any other improvements. (but because forts are able to hoo up improvements they do get included when ontop of improvements)

I think it may send workers outside borders though

I just got the 'discover oil" event in the prehistoric era. I think we should allow tar gatherer on this resource.

I just wanna tell that I do appreciate the work you do guys.

It's just me or someone share the same problem with me... I play v 33. I usually play at Noble level, without revolutions, giant map, Mansa Musa. I reach Sedentery life style era around 12k BC with at least 5 cities, dominate the continent around 400-300 BC with at least 20 heroes, sometimes sooner. Is it difficulty problem?

holyavenger said:

I just wanna tell that I do appreciate the work you do guys.

It's just me or someone share the same problem with me... I play v 33. I usually play at Noble level, without revolutions, giant map, Mansa Musa. I reach Sedentery life style era around 12k BC with at least 5 cities, dominate the continent around 400-300 BC with at least 20 heroes, sometimes sooner. Is it difficulty problem?

Click to expand...

It's improved a bit since then.


Ok, so I had an idea today as to how we can get around this problem with upgrading improvements taking out features and no good way to address a solution.

So what if when an improvement has qualified to upgrade, rather than automatically doing so, if it will destroy the feature on the plot to have a valid upgrade there, it will instead throw up a popup prompt to ask the player if he wishes to accept the upgraded (and thus destroy the feature), accept an alternative upgrade if an alternative is available (new tag to define this) or simply reject the upgrade and leave the improvement as it is (which will freeze the improvement from further upgrades until/unless reworked.)

What do you think?

Thunderbrd said:

It's improved a bit since then.


Ok, so I had an idea today as to how we can get around this problem with upgrading improvements taking out features and no good way to address a solution.

So what if when an improvement has qualified to upgrade, rather than automatically doing so, if it will destroy the feature on the plot to have a valid upgrade there, it will instead throw up a popup prompt to ask the player if he wishes to accept the upgraded (and thus destroy the feature), accept an alternative upgrade if an alternative is available (new tag to define this) or simply reject the upgrade and leave the improvement as it is (which will freeze the improvement from further upgrades until/unless reworked.)

What do you think?

Click to expand...

Sounds workable. Although the improvement upgrade is done in the dll so it is more work for you.

It's my idea... I'd LIKE to implement This would be a good easy practice at popups which is something I'm getting more and more comfortable with but would like the occasional easy practice with it to keep sharp on the process between larger projects that utilize them.

The AI of course would simply just select the primary upgrade and run with it. Should usually be a pretty good choice to do so but we don't want the player to feel like he's equally forced into it.

There are some improvements that upgrade in a special way. Ie their upgrade triggers python to do something.

The early forest planting by ModifiedA4, the beacons on reefs and coral by me and maybe the terraforming ones. None should cause the pop-up. They are not working at the moment.

The terriforming ones that add features etc actually plant an improvement that should immediately "upgrade" to the feature. ModifiedA4's version has the improvement grow first.

The beacon and lighthouse improvements cause the underlying feature to change so that it can do less damage and take less time to traverse safely.

Not all improvements would trigger a popup - only on special conditions being met. And the way the upgrade is called shouldn't differ from the manner in which it takes place now - rather I'll use the same coding I find there that carries out the actual upgrade and just port it over to upgrade to whatever is selected if there's a popup response needed. So if there's a py trigger on that I'll make sure to include it so it's an equally valid action point for python.

I've long noticed those young forest planting missions don't seem to be carrying out that 'upgrade to a feature'. Perhaps they should take their valid amount of time to do so then when they do upgrade at that point - is this something you've sorted out since they were first introduced or are they still not 'upgrading to a feature'? I might be able to do this (or create a tag driven method to do this) directly in the code while I'm at it.

The beacon and lighthouse improvements cause the underlying feature to change so that it can do less damage and take less time to traverse safely.

Click to expand...

How well is this working right now? I've not played enough to witness it lately.

It did work for awhile but then it stopped working and that module is not firing at all. I keep meaning to get back to it. There are three python modules that do something when an improvement "upgrades" which is the same as being built. The other two are working.

Since I am doing Python at the moment I will have another look at the code.