RevolutionDCM for BTS

[Fimbulvetr]

There is a mistake in the tech diffusion code. The problem is the m_iTECH_COST_FIRST_KNOWN_PREREQ_MODIFIER.

If you set in TechInfo.XML for a tech that requires A and B by

i) A as OR-tech and B as AND-tech
ii) A as AND-tech and B as AND-tech

it should make no difference for the research cost. But with a value != 0 for m_iTECH_COST_FIRST_KNOWN_PREREQ_MODIFIER this is not true. In case i) you get a bonus for A in case ii) you will get none.

The idea behind this was afaik that you should get a bonus if you research more than the absolutely required number of prereq techs, in which case the first OR tech should give no bonus.
All you need to do is set TECH_COST_FIRST_KNOWN_PREREQ_MODIFIER to 0, because giving a bonus to the first OR tech is exactly what this variable was meant to do. I agree it's not very intuitional but it's there to mirror standard BTS behavior.

 

[Thomas SG]

The idea behind this was afaik that you should get a bonus if you research more than the absolutely required number of prereq techs...

Yes. But one of the OR techs must be researched. To give a bonus is okay if you have researched more than one. But not for the first.

With your bonus there is e.g a difference between the research times of constitution and astronomy. Both require exactly two techs and both cost 2000 but because of your modifier constitution is cheaper.

 

[Fimbulvetr]

I can only repeat: standard BTS behavior. That's the only reason it's there, and you can easily get rid of it.

 

[glider1]

@Fuyu, ChrisAdams3997 and Mattygeist
Thank you for your contributions on the bombard issue! I have only had enough time to observe the problems but not enough time to see if they are real or not, let alone fix them. Chris and Fuyu, keep up the good work and Mattygeist thanks for at least confirming that there is no issue in Better BTS AI. It was suggested that latest Better BTS AI should be merged in and I can do that now and see what else needs to happen inside the RevDCM bombard AI. If any of you want more access to the SVN, mail me and we can discuss what you need. Yes please feel free to post code or ideas on this forum.

@ThomasSG
Thanks for staying in touch with this forum. At the moment I will not change the tech diffusion code. At least you have your ideas recorded down on this huge forum for later analysis if and when it is needed.

Thanks again
Cheers

 

[ChrisAdams3997]

I've spotted one oddity in a marathon test game that has probably been introduced before what I merged, as I don't recall any new UnitAI code dealing with this particular behavior. The Chinese have an attack stack(about 7 axemen, etc, no catapults available yet) outside a well defended Portuguese town (4-5 archers). The Chinese stack keeps walking back and forth between a forested hill adjacent to the city, then the next turn moves south to a developed pasture, again next to the city, then back up to the hill. Rinse, and repeat.

I'm calling all this from my recollection of the code from yesterday, haven't looked specifically today. Looks like from the hill (best plot to attack from?) it sees it's stack ratio isn't good enough to attack(less than 110), it obviously can't bombard, so it decides to pillage (seems I recall seeing some code for this?). But once it gets to the pillage plot, it checks for danger from the city, and decides it needs to head for better ground. Then... does it all over again.

I'll have to look at the code (umm... tomorrow) to see how those guesses look, but I thought it good to report it here for those who know the code better.

@ Fuyu

lol, trying to get caught up to speed here, how different is your code from the newest Better BTS AI. Is it basically the same just with Bug/Bull merged in, or are there significant AI additions/differences?

@ Glider

It'd probably be much better to have you do any officially merged code, for now, as you know it better , but I usually have two or three hours most days to fiddle around with code or playtest it, and I'd be happy to use that to help out here for a while.

Chris

 

[glider1]

Thanks Chris
I'm going through just double checking that the latest Better BTS AI code is in (Phungus did a great job on that merge). I'm lagging you which is good. After this I'll check the stack odds stuff and in the meantime you might come up with something. My intention is to follow Phungus's advise and just to fix this bombard issue plus whatever else turns up, and then release 2.8 soon.
Cheers

 

[Fimbulvetr]

I've spotted one oddity in a marathon test game that has probably been introduced before what I merged, as I don't recall any new UnitAI code dealing with this particular behavior. The Chinese have an attack stack(about 7 axemen, etc, no catapults available yet) outside a well defended Portuguese town (4-5 archers). The Chinese stack keeps walking back and forth between a forested hill adjacent to the city, then the next turn moves south to a developed pasture, again next to the city, then back up to the hill. Rinse, and repeat.

I'm calling all this from my recollection of the code from yesterday, haven't looked specifically today. Looks like from the hill (best plot to attack from?) it sees it's stack ratio isn't good enough to attack(less than 110), it obviously can't bombard, so it decides to pillage (seems I recall seeing some code for this?). But once it gets to the pillage plot, it checks for danger from the city, and decides it needs to head for better ground. Then... does it all over again.

I'll have to look at the code (umm... tomorrow) to see how those guesses look, but I thought it good to report it here for those who know the code better.

I believe it's a known problem, just noone has fixed it yet. I'm not sure if the stack actually wants to pillage or if it's simply trying to retrreat, but the stack comparison that tells the stack it has no chance attacking the city only happens when the stack is next to the city, once it has moved away the stack no longer knows that and moves in again to attack.

@ Fuyu

lol, trying to get caught up to speed here, how different is your code from the newest Better BTS AI. Is it basically the same just with Bug/Bull merged in, or are there significant AI additions/differences?

I wouldn't call my AI changes significant but there is a bit of AI code that is not in Better BTS AI.

edit: ok, one difference might have significant impact: I reduced the AI city razing to what it was before jdog increased it. But that really should be the only noticable change.

 

[ChrisAdams3997]

Thanks Chris
I'm going through just double checking that the latest Better BTS AI code is in (Phungus did a great job on that merge).

That's how it looked to me too, I was particularly glad he'd already merged in the new Civics AI best as I could tell , that looked like a doozy looking at Fuyu's SVN changes there.

My intention is to follow Phungus's advise and just to fix this bombard issue plus whatever else turns up, and then release 2.8 soon.

An excellent plan, no need to introduce anything too new--which would then need more testing... It's certainly time for a new official release.

I believe it's a known problem, just noone has fixed it yet. I'm not sure if the stack actually wants to pillage or if it's simply trying to retrreat, but the stack comparison that tells the stack it has no chance attacking the city only happens when the stack is next to the city, once it has moved away the stack no longer knows that and moves in again to attack.

Hmmm, and I can see why it hasn't been fixed. That basically means we need a whole new AI logic for what happens when the stack isn't powerful enough to attack, which is some work, especially to get right. With Glider handling the official merge, I'll look at this and do some brainstorming perhaps while I continue to test the bombardment formula.

I wouldn't call my AI changes significant but there is a bit of AI code that is not in Better BTS AI.

edit: ok, one difference might have significant impact: I reduced the AI city razing to what it was before jdog increased it. But that really should be the only noticable change.

That's kinda on the order of what I figured, thanks

Chris

 

[os79]

And add in Afforess whenever he have time, and this would be an awesome release! Good job, Glider1, for recruiting an excellent follow-up team this time around.

Here's to hoping that you all will have a satisfactory 2.8 release that will stand the test of one year's time ! Cheers.

 

[glider1]

Ok where I'm at is that I have decided to keep track with Fuyu's Better BUG AI as much as possible and so all Fuyu's work is in the RevDCM SVN. I've double checked the Better BTS AI merge and updated is where necessary and so now RevDCM is fully Fuyu and Jdog up-to-date as of this minute. I have added some modding level commenting to Fuyu's code where I think it wasn't commented previously and so RevDCM's Better BUG AI code is probably more up to date than Fuyu's code for a short instant in time. In this way, Fuyu's mod essentially summarises all the really important changes that are also required to be made to RevDCM, simplifying Phungus and my work having to independently track BUG, Fuyu, Better BTS AI, and BULL!

Once Jdog comes back into the project next year, it would be great if he and Fuyu can sit down and work out how their two code approaches mesh together. But that is for another time....

Now that the really hard slog has been done of gettting RevDCM up to date again since Phungus's last effort, I wait for Chris's findings on bombardment and AI behaviour (no hurry do it when you can). If I hear nothing within a reasonable amount of time, I will try to fix the bombardment issue myself and do an official release.

It is possible that the bombardment issue is fixed simply by doing this update that I have done. There is stack bombardment XML data in BBAI_AI_Variables_GlobalDefines.xml that might not have been read properly in previous RevDCM builds. Not sure yet.

Cheers

 

[phungus420]

Just tested the new SVN, and the AI is bombarding city defenses now.

 

[glider1]

Great Phungus
Thanks for testing that Another pair of eyes makes all the difference. Yep tested it at the same time as you on the other side of the planet and it looks fixed. Was just a very easy to happen merge issue somewhere with reading BBAI_AI_Variables_GlobalDefines.xml.

Now to wait and see what Chris and Fuyu have to say about adjusting the bombardment variables and/or fixing that confused AI attack stack bug. All Fuyu's code is now in RevDCM so it's up to him.

Thanks again.
Cheers

 

[Zogar]

Good mod. Something needs to be done with cultural borders. It's a lot easier for me to raze cities than to capture them. When you capture cities, after the initial rebellion stops, you get so few working tiles that your cities are always starving, and asking to join their former civ, then rebelling and popping new enemy units. It got so tedious I started to raze everything. It works a lot better.

 

[scu98rkr]

Something needs to be done with cultural borders. It's a lot easier for me to raze cities than to capture them

This is fine if you ask me CIV IV is all about compromises and what choice to take. Its not obvious to raise a city after you've captured it because you lose that city and the advantages it has.

Also surely the above talks about your playing style to a certain extent your no cultural pressure on this cities as the AI has more culture than you.

Or if you trying to take a city of a far continent what do you expect ?

 

[Hephaistion]

So glad to hear that work has progressed so far on updating and bug-quashing for RevDCM. I just wanted to let all you guys know that your hard work is very much appreciated by all of us modders out there who use your work and all the folks who play our mods and benefit so much for it. Everyone raise a glass

Very much looking forward to the next RevDCM release!

 

[ChrisAdams3997]

Given the problem and solution you found concerning bombardment Glider, it's highly improbable that there would also be a problem in the code I'd hypothesized could be causing the issue, so we can probably count that as fixed unless anybody sees any other issues with it fairly quickly.

As for the confused stack I reported, I made several incremental changes in AI_AttackCityMove to try to isolate what was going on, but to no avail--to the point that I'm somewhat convinced the stack was not following AttackCity AI logic. Looking in worldbuilder, there was one Swordman at the head of the unit that was AttackCity unit AI, then about 7 axemen that were all Counter AI, and I haven't looked closely enough to find out where the stacks decisions might else-wise be coming from.

At any rate, after a number of turns, the other civ was able to pull up some reinforcements, attack the stack when it was in the open, then what was left retreated to heal. Many turns later, the Chinese attacked with a real attackcity stack and was able to take the city, so it might not be enough of an issue to worry too much about.

I've also downloaded the new changes from the SVN and I'll play test it and pass on any problems .

Chris

 

[glider1]

Thanks Chris
Yes please check through the build on the SVN in as much detail as you can. I'll probably release this weekend if no-one finds anything in the next 48 hours. Totally relate to the challenges of working out AI stack behavior and appreciate that it's better to leave off than to create unintended side effects. It needs a lot of time, patience and an eye for detail to get into the nitty gritty of unit AI. You think you have nailed something and then find out that you have not!

I think what happens is that you absorb the AI mechanisms gradually over time. Nothing much happens at the coding level until something crystallizes in your mind and then the code pretty much pours out, like it did once Jdog got his head around it after a long period of contemplation and practice. If you get into Civ5 at some stage and it turns out that 1UPT is not an insurmountable AI problem, the way that Jdog learned the Civ4 AI was to start at the specific level trying to do something really small and concise like he had to do initially with the Revolutions code. This is essentially a learning curve period. Then gradually over time you go deeper and deeper. Jdog learned on the fly, starting with specific coding issues centred around Revolutions and then going to the general layer of a better AI from there. It helps if you have post grad degrees in computer science and physics that has to be said!
Cheers

 

[glider1]

Well I've played the build steadily through by hand for the last eight hours. I can't find a single problem yet. Looks nice on my side of the planet anyway. How about you?
Cheers

 

[Zeiter]

Hello all you wonderful revdcm modders,

I think my question might have gotten lost in the shuffle a page or so back.

Anyways, the only thing I need to know is what happened to this stuff:

I can't find a file in RevDCM 2.722 with these adjustable parameters. (RevolutionDCM.ini only has the config section now). Are these hard-coded now? If not, then where should I look?

Thanks!

 

[glider1]

Hi ya Zeiter
Ya no wonder you confused. It now exists in default BUG standard for mods. The file you need is:

\Documents\My Games\Beyond the Sword\RevolutionDCM\UserSettings\Revolution.ini

That is where it is under UserSettings under my documents, no longer in the program file directory. The good thing is that you can retain all your user settings that way from build to build without them being overwritten. That is why it is done that way.

Cheers

[EDIT: previous location was incorrect]