Solver's unofficial BtS 3.17 patch

EmperorFool said:
And then people continue requesting new features or changes that Solver has stated are out of the scope of his patch.
Click to expand...

Hey, I should be the first one to know that, right? Since I already said it several times myself?

But I don't see it that way. This is a CLEARLY BROKEN thing, whether you use it or not. Which is exactly what Solver said he WOULD do here; fix broken things in the current version. You get it?

Worker automation contradicts with any plan of a future national park, meaning if you want to have a national park in the future, and you want the trees there to grow (and I guess people have wanted that since BtS), you have to turn off automation.
I didn't ask for Solver to fix it right away. But I do think I'm entitled to throw it out there because it's clearly a broken thing in the current civ version. Automation doesn't work together with a national park plan.
 
Caboose said:
Do you get it?
Click to expand...

Yes I understand all that, I've read that post before. But do you understand that what you're asking for would be a major undertaking to implement? You're asking for a complete rewrite as to how Workers are controlled. And it will add changes that many players will not even consider to be worthwhile. And I'll say it again. Higher level players do not use automated Workers. Even mid level players don't use automated Workers. It is a worthwhile feature only for beginning players who do not fully understand how to play the game and make their own decisions. Once you get a feel for how you want your empire to grow, you will quickly find yourself trying to correct the many faulty decisions your automated Workers will make. In short, it will be too much of a task to be included in a patch made by someone in his own freetime with no pay for his efforts, for very little benefit to most of the people who play the game.
 
But your problem is that you don't see that I'm not asking for anything.

I only threw it out there. If it's hard to do, of course I don't expect him to implement it. Do you think I'm stupid? I'm just not a coder, so I don't know how hard that would be. If I knew it was hard, I wouldn't even have mentioned it. I already said many times here how much I appreciate Solver doing this work, so don't give me that. You really don't read me at all, do you.
 
Caboose said:
This is a CLEARLY BROKEN thing, whether you use it or not.
Click to expand...

I certainly agree that the Worker automation routines have lots of room for improvement, which is why most players don't use it. But it will take a gargantuan effort in order to create a truly effective system. I have a few ideas of my own that I would like to see implemented, though I realize that they don't fit into the scope of what Solver is trying to do here. So you're going to have to be satisfied with minor tweaks here and there and not expect a major reworking of the base code. Unless of course you'd like to pay Firaxis yourself to put two or three people on it and make things work the way you want them to. I doubt though that you can afford to do that.
 
Hey, man, I'm not hatin'. :) I'm just explaining why people have a short fuse, and yes you are included in that pack. :)

I see this more like a feature than a fix because automation works like it says it will and has always worked. Being able to mark tiles not to be improved would change how automation functions. The bigger reason, though, is that it would involve far more than just modifying the DLL.

  • Extend save game format to track which tiles are marked.
  • Extend DLL to provide Python APIs for marking/unmarking tiles.
  • Extend game engine (impossible via DLL or Python) to visually display which tiles are marked. You can use Python or the DLL to mark tiles using the same brackets that are drawn for air missions, but that's suboptimal and confusing.
  • Add button/mode to interface (Python) for marking/unmarking tiles.
I think this would be a fine addition to the game, though.
 
Then it is not worth mentioning anymore, and I am so sorry for bringing it up. You coulda just said that it was hard to do. But I guess it's more fun making fun of the guy who uses automation, right?
 
Caboose said:
But I guess it's more fun making fun of the guy who uses automation, right?
Click to expand...

It's not that we were trying to make fun of you for using automation. It's just that we realize how poorly the automated Workers make decisions sometimes and we've just discounted the whole automation process. Your idea is not a bad one at all, in fact I've had some ideas pop into my head along similar lines. But it's just way beyond the scope of what Solver is trying to do right now. Maybe in Civ 5. If we're lucky.
 
Solver,

you may want to add this to your unofficial patch. It's the work of another guy, but I found it interesting to include in your work.

It solves the graphic glitch with modern roads showing as ancient roads in 3.17.
 
ricardojahns said:
Solver,

you may want to add this to your unofficial patch. It's the work of another guy, but I found it interesting to include in your work.

It solves the graphic glitch with modern roads showing as ancient roads in 3.17.
Click to expand...

There's still some debate as to whether this was intentional or not. Alot of people have complained that the modern roads look too much like Railroads, making the two hard to tell apart. So there's some speculation that Firaxis may have changed things as an answer to those complaints, without adding it to their list of changes.
 
Willem said:
There's still some debate as to whether this was intentional or not. Alot of people have complained that the modern roads look too much like Railroads, making the two hard to tell apart. So there's some speculation that Firaxis may have changed things as an answer to those complaints, without adding it to their list of changes.
Click to expand...
Agreed. But I fixed this xml because some people have complained about broken roads. It might be added as supplementary optional feature.
 
Methos said:
Moderator Action: Come on guys, there's no need for insulting each other. You can respectfully argue with each other without insults. It's technically not a discussion without differing opinions.
Click to expand...

:D can we make fun of the Moderators then? :backstab:
 
Caboose said:
You know what would be GREAT? A button you could click on that makes you able to say to your workers: "Don't build any improvements on this tile."

Right now I have to turn off worker automation because they're ruining my future national park. Not removing trees, but building improvements where the trees can grow =(

If this could be done:
Button should be available when you have a worker selected and should count for all workers. Selection should be very similar to "bombing selection", if you know what I mean.

If you were able to do such a thing, I would bow down in awe.
Click to expand...

Caboose, I was with your idea from this first post!
I use "Build Trade Network" often especially after Railroads and always hated it when they spoiled my thoroughly thought out National Park plans. As a result I monitored that region and cancelled their orders when they intruded, sent them to the other corner of my territory and re-automated them--this sucks big time!

Here is my suggestion for a solution:
The main problem is: non-pillagable roads/railroads decrease forest/jungle-spread. So my idea is to recode CvPlot::doFeature() in Cvplot.cpp to ignore this spread penalty from those cardinal directions that have a forest preserve improvement:
Code: 
int iRouteModifier = std::max(0, (GC.getROUTE_FEATURE_GROWTH_MODIFIER() + 100));

for (iJ = 0; iJ < NUM_CARDINALDIRECTION_TYPES; iJ++)
{
	pLoopPlot = plotCardinalDirection(getX_INLINE(), getY_INLINE(), ((CardinalDirectionTypes)iJ));

	if (pLoopPlot != NULL)
	{
		if (pLoopPlot->getFeatureType() == ((FeatureTypes)iI))
		{
			if (pLoopPlot->getImprovementType() == NO_IMPROVEMENT)
			{				
				if (isRoute())
				{
					iProbability += ((GC.getFeatureInfo((FeatureTypes)iI).getGrowthProbability()) * iRouteModifier /100);
				}
				else
				{
					iProbability += GC.getFeatureInfo((FeatureTypes)iI).getGrowthProbability();				
				}
			}
			else
			{
				iProbability += GC.getImprovementInfo(pLoopPlot->getImprovementType()).getFeatureGrowthProbability();
			}
		}
	}
}
iProbability *= std::max(0, (GC.getFEATURE_GROWTH_MODIFIER() + 100));
iProbability /= 100;


So this basically allows forest preserves to spread their feature freely over roads and railroads. The natural spread from the feature alone will still be subject to the penalty.

Again, I don't really speak cpp, so the pros might find problems/errors.

Comments?
 
Caboose said:
You know what would be GREAT? A button you could click on that makes you able to say to your workers: "Don't build any improvements on this tile."
Click to expand...

I think it should work the opposite way, by which I mean you right click on a tile and choose the improvement you want to build there and an automated worker would get to it eventually. It has all the control of what gets built that you get from manual workers, but without having to pick which worker will do it and when and it what order. That's very much a civ 5 idea though.
 
Yeah, honestly, if someone could make it so that roads could be pillaged in your own territory as well, that would indeed be a start. There is no logical reason that I've heard as to why you can't do that. Well, maybe military units though, 'cause workers can't really pillage, only change one improvement to another.
 
I think self-pillaging roads can somewhat be exploited to make handling of resource availability easier and thus taking advantage of special production bonuses (overflow tricks) or building otherwise outdated units (privateers after oil). OFC you can do this with just a lot more workers too.
Besides--roads and railroads are good things to have. So ignoring the spread penalty seems to require the least effort of modification.
 
EmperorFool said:
Thus the title. ;) I find it extremely useful, and it's an option in BUG. BUG also adds a fist icon next to pairs of civs at war. </BUG-plug>
Click to expand...

Yes, my wording was no accident. ;) By the way, I'm one of the earliest users of your mod. :)

Woody1 said:
Why do you care? If you consider that a cheat, THEN DON'T DO IT. It's really that simple. You shouldn't need a patch fix to stop you from cheating. I don't expect you want a patch to remove the worldbuilder, to prevent you from giving yourself free units or cash, do you?

We could argue the pros and cons of whether the AI should accept missionary gifts during theocracy, but it's a moot debate. Even if you're right, only the human player would use that exploit. And he has to go to the effort of doing it that way, rather than using the normal approach to spread religion with his own missionaries. So just don't do it!
Click to expand...

It's very simple actually. The theocracy civic doesn't allow the spread of foreign religions by natural spread or foreign missionaries and the human player can easily circumvent this restriction by gifting the missionary. Seems like a restriction that isn't working and thus needs to be fixed.

DanF5771 said:
Here is my suggestion for a solution:
The main problem is: non-pillagable roads/railroads decrease forest/jungle-spread. So my idea is to recode CvPlot::doFeature() in Cvplot.cpp to ignore this spread penalty from those cardinal directions that have a forest preserve improvement:

(codestuff omitted)

Again, I don't really speak cpp, so the pros might find problems/errors.

Comments?
Click to expand...

I'm not familiar with reading cpp, but there is an xml-entry that governs the forest spread over routes. It's in GlobalDefines.xml and is called:

Code: 
	<Define>
		<DefineName>ROUTE_FEATURE_GROWTH_MODIFIER</DefineName>
		<iDefineIntVal>-50</iDefineIntVal>
	</Define>

Changing the -50 to 0 makes forests and jungles spread over roads normally (I think).
 
Roland Johansen said:
I'm not familiar with reading cpp, but there is an xml-entry that governs the forest spread over routes. It's in GlobalDefines.xml and is called:

Code: 
	<Define>
		<DefineName>ROUTE_FEATURE_GROWTH_MODIFIER</DefineName>
		<iDefineIntVal>-50</iDefineIntVal>
	</Define>

Changing the -50 to 0 makes forests and jungles spread over roads normally (I think).
Click to expand...

Yeah, this value is read out in the first line of my code modification and should IMHO not be changed so that the spread that occurs naturally is decreased when humans have built roads/railroads in the tile. The idea was to ignore this penalty for the spread enhanced by forest preserve improvements built by humans.
 
Well the PROBLEM is that workers ruin your plans of a national park. So if we can avoid changing such a game mechanic that would be desirable. The least intrusive fix (I think) is to make it possible to pillage your own roads. But you said something about exploits? I didn't quite follow. What's exploitable about removing your own resourses? I think I know what you mean, but I don't quite see how that can be classified as an exploit. And do you really think that is why Firaxis hasn't enabled it?

Well if you know of any such exploits then probably both ways will be somewhat intrusive to game mechanics, and of course then your solution is better.
 
You must log in or register to reply here.

Similar threads

T
The AI Horatius League
Replies
4
Views
84
Thrasybulos
T
K
New to Civilization 4
Replies
5
Views
745
f1rpo
f1rpo
Benualdo
Unofficial map editor (WIP)
2 3
Replies
44
Views
4K
Benualdo
Benualdo
F
Space samurai
Replies
0
Views
443
Fins
F
Keler
AI Survivor Switchheroo
2
Replies
37
Views
5K
Fippy
Fippy
Back
Top Bottom