Animosity

To not further spam the pythonthread please dicuss Animosity here.



It would be cool to have animosity as a boolean tag in the promotions xml. With another tag there to set the percentage chance for it to take effect. And a third to define single units(unit_goblinarcher and unit_goblinspearman etc.) that could provoke animosity for the unit which has that promotion.

Promotions info because: I can define a lot of changes on unit combats, firststrikes there etc.
The game should check each turn onunitmove if one of the units defined are in an adjacted square. If yes the percentage chance should be checked and if the result is true the promotion should get active(only there all of the boni/mali defined in the promtionxml should apply) and the unit affected by animosity does the following by chance:

1.)1-80% stand immobile this turn(a message in the log about the internal squabble should pop up)
2.)81-90% the unit attacks the friendly unit that caused animosity.(Get'em!)
3.)91-100% the unit immediatly attacks the nearest enemy unit(or just rushed towards it if cannot reach) receiving an additional +1Movement during this process.(We'll show 'em!)

This chances could be modified to:
1.)1-80%(Squabbling)
2.)81-100%(Get'em!)
if the civ is at peace with everyone.

Results so far: I've got Squabbling working fine. Get'em works OK, but I've got a couple of issues when 2 stacks of 2 units or more are near each other, as after the First Get'Em, another unit trys to attack where the old unit was. Doesn't crash but in a debug popup you get an unknown C++ exception. Show'Em hasn't been started because I wanted some more info. All animosity actions force a finishmoves() on a unit

Questions:
Show'em - Should there be a limit of how far away a unit is for Animosity unit to charge it? Say, max moves + animosity bonus move + 1?
If that unit is in a neutral territory, do we attack and declare war against the neutral?

Notes:
I set the Animosity trigger to be based off Promotion rather than unit class, or else an Orc would only be affected by that exact same type of orc (Axemen would ignore non Axmen)
Also, I don't trigger Animosity for units in the same plot as attacking the square you are in is a problem at the moment
I'm triggering the animosity check for everyunit on every turn (made a custom event on CvUnit::doTurn), as a unit that is not moving should still have to "roll" for animosity no? Also trigggering at onUnitMove (unless someone can tell me) gives me problems finding out where the unit came from to send back on a Squabble action.

This took a bit longer than I wanted (wanted to finish it today) but I'm trying to get most of it in Python and I ran into quite a few beginer errors in my First Every Python Script. Especially finding out onBeginPlayerTurn is in fact at the end of the last turn

Anyway, any feedback will be highly appreciated. I'll post an upload once I have the kinks out of the Get'em Effect if everyones happy. The Show'em can come later.

Click to expand...

E.L.M. I think you're doing nice no critics for how you code here. About the diplo thing I didn't think yet since we only have one orc civ yet but as soon we also have gobbos as civ that seriously is a problem. I think units that get affected by animosity shouldn't start a war even if they attack units of another civ(which they in fact should do!) since orc and goblin civ should be able to cooperate but this shouldn't disable animosity at all.
We'll show 'em charge attack should be limited to 2 tiles distance imo.

A promotion that quells animosity would be a good idea. I'm thinking here this should be a promotion that quells animosity for all units in the same tile simulating strong fearstriking Leaders that can make the squabbling stop by their mere presence. (For Black Orcs and Heros- I vote against prereqs and giving this promotion to other ordinary orcs as well)

I support the idea of having a building in a city that reduces the chance for animosity to take effect.

EDIT: UPDATE POST CURRENT ANIMOSITY STATUS

EDIT: ISSUES POST BUG POST

ANIMOSITY is now complete at version 2, please see the above posts for information (EDIT: Whoops - links now go to the right posts!)

Do we want to totally restrict animosity from cities at the moment. I have found the unfortunate circumstance that a unit will charge out of the city square to attack a friendly unit and if it is the only unit the city is left defensless. Or are we just considering this as a risk of animosity?

Do we want a replace to "Show'em" during peace time or just make "Get'em" twice as likely?

Also, as a note all the Get'em attacks occur at once - that's why I get the Attack plot == NULL exception in the Python debug, so you will get a message for every animosity Get'em and will see maybe more than one orc group running around and attacking. I might turn zoom on next time just to see what will happen.

I'll put a check in the Python to look for a promotion on the same square that prevents animosity (but comment it out for now until the promotion exists). Do we want a hardcoded promotion, or a new entry on the promotion options? Also, same square, or adjacent and same square?

A show'em attack of units that are max 2 plots away will mean the unit will always get the target. This is because of the +1 movement from a Show'em charge. It's listed in the Python as a global so we can set it to zero if we want a chance of the unit charging but not making it.

Expect a lot of test results and uploads in the next couple of days, work has calmed down and I also had to study from an exam I had today (not a real one, the super "life in the UK" citizenship test - I'm a Kiwi in the UK) so once again I have not finished everything I wanted.... Will be back on it tomorrow...... promise!

El Loco Mono said:

Do we want to totally restrict animosity from cities at the moment. I have found the unfortunate circumstance that a unit will charge out of the city square to attack a friendly unit and if it is the only unit the city is left defensless. Or are we just considering this as a risk of animosity?

Click to expand...

funny! I'd say that'll teach players not to relie on a single goblinarcher-keep it risky!

El Loco Mono said:

Do we want a replace to "Show'em" during peace time or just make "Get'em" twice as likely?

Click to expand...

twice as likly should suffice or got a good idea for replacement?

El Loco Mono said:

Also, as a note all the Get'em attacks occur at once - that's why I get the Attack plot == NULL exception in the Python debug, so you will get a message for every animosity Get'em and will see maybe more than one orc group running around and attacking. I might turn zoom on next time just to see what will happen.

Click to expand...

At once?! Sounds like trouble. Way of having them one after the other?

El Loco Mono said:

I'll put a check in the Python to look for a promotion on the same square that prevents animosity (but comment it out for now until the promotion exists). Do we want a hardcoded promotion, or a new entry on the promotion options? Also, same square, or adjacent and same square?

Click to expand...

the less hardcoded there is the better. Same square only!

El Loco Mono said:

A show'em attack of units that are max 2 plots away will mean the unit will always get the target. This is because of the +1 movement from a Show'em charge. It's listed in the Python as a global so we can set it to zero if we want a chance of the unit charging but not making it.

Click to expand...

Make it so that the orcs allways try to reach the next enemyunit up to 3, 4 or 5 tiles away. No problem with the 2 tiles that it reaches the enemy.

El Loco Mono said:

Expect a lot of test results and uploads in the next couple of days, work has calmed down and I also had to study from an exam I had today (not a real one, the super "life in the UK" citizenship test - I'm a Kiwi in the UK) so once again I have not finished everything I wanted.... Will be back on it tomorrow...... promise!

Click to expand...

Wonderful! Keep up the good work!

At once?! Sounds like trouble. Way of having them one after the other?

Click to expand...

Well, they're are not actually at once, but it's like the civil disorders in the cities. Each city is done in turn at the start of the turn but the player does not have control until after all the animosity checks. So according to the player, it all happens at once. Not sure yet, but I think the code triggers the fight animation, but does not check it is finished before moving to the next units turn. In this case the unit is still in plot X, but once the previous fight is completed, it triggers the new fight, but the previous unit may have moved after winning the earlier fight. I'll try and get the first stage animosity (Squabble and Get'em and Show'em without the check on same plot) finished tonight or tomorrow so I'll look into it a bit deeper soon

EDIT: Version 2 complete, current status of v1 will no longer be updated

OK, I've got a basic animosity working but I thought I would post what it does first before I upload the files. Just incase anyone has objections or ideas for last minute adjustments I can make. I've only done Worldbuilder tests so far, but I am going to spend some time tomorrow testing it in a game environment before uploading also.

WHAT IT DOES:


WHAT IT DOES NOT DO (yet):


THINGS THAT SHOULD BE DONE:



NOTES:
MaxCharge, Squabble% and Get'EM% are globals in the python script. Everything above the Get'Em% is considered Show'em. If there is no unit the player is at war with nearby, this becomes a Get'Em action also.



Hope this all makes sense.


Version 2 (to be uploaded):

Added the code to the DLL thread. A document attached there shows example entries in the promotions and unit xml as how to use animosity.

looks very interesting. Is this all done in c++ or is the SDK just used to redirect to python? I would download it but I cant atm.

Click to expand...

I managed to get most of it in Python (trying to make it as adjustable as possible without needed to recompile the mod). I needed to create a new generic event call and a new function to force friendly attacks, plus the new XML reads. but bar that, it's just a horrible amount of nested loops with some basic calls - which I hope to rewrite much more tidy when I've finished getting the scope finished.

I think it took a week, when it should have only taken a few days, but I'm new to the python world so I had a few basic hic-ups along the way. I probably won't get round to expanding it further until Friday, so for now it's the standard working version.

Just for info, had no time this week but hopefully this weekend I can plough through and tidy this up to a better finished product.

Nice to see the animosity progress
Would love to test it now but can't do much here.

Only 2 tweaks to make before i can upload the finished animosity (minus buttons and sound of course)

Wahoo! Animosity is complete. I will spend a few hours doing in game tests, but hopefully today I will be uploading the complete version

Animosity is now complete! Check the DLL thread for the code
EDIT Current Version 2.1 now integrated

Basic Rules of Animosity according to code
If a unit is adjacent to or in the same square as a unit that has the Promotion that triggers animosity for this unit, an animosity check will occur

Die Rolls
Animosity Percent = The % chance that animosity will cause the unit to perform an uncontrolled action. This is checked against EACH unit in the adjacent squares. That means , the bigger the stack or number of surrounding units, the more likely you will have animosity.

Action: (controlled by Python globals)
1 - 80% Squabble - The unit cannot move next turn
81 - 90% Get'Em - The unit will attack the unit that caused the animosity
91 - 100% Show'em - The nearest valid enemy unit that is with a specific distance and in a valid plot to attack, will be attacked by this unit. If there is none, a Get'Em action is performed.

Controls


Effects



Code Effects


Notes


Need
I still need some buttons to display during the animosity event and maybe a sound as well

As Bugs arrive, I will list them here and the progress on the fixes.

Also I attached an example Promotion XML as how the animosity flags were used, and the example PROMOTION_SHOWEM in my testing.

Bugs v2

PRIORITY HIGH

PRIORITY MED

PRIORITY LOW

camera zoom on the Get'Em / Show'Em will only display once, so you may not see the battle with camera zoom one. Cosmetic.

Good job. I'll try to get a button and sound within the next days

@Elm
I'm currently integrating animosity to the game.
thing I'd like to have changed:
-the promtion to quell animosity should only affect units in the same tile. Blackorcs leading a stack should quell all squabbling in their stack but shouldn't prevent being attacked by neighbor stacks.


other than that feel free to make changes to animositychances according to your playtesting. It's your baby and I trust you fully about that

Edit:
Err can you please also post some example lines of unitinfos. I'm not sure where exactly I have to put the lines and what kind of content I can give

Edit2:
Ah forget it I think I found what I was looking for. But a question. Is it possible to give not one but 3 animosityprotagonists? We will need this for daemonanimosity for the chaos civ.

the boolean tag for quell animosity seems not added yet. I encountered a tag in the prominfo under regenerate and got an xml error.

Ploeperpengel said:

the boolean tag for quell animosity seems not added yet. I encountered a tag in the prominfo under regenerate and got an xml error.

Click to expand...

Yeah I noticed that when I didn't put it in the right place. Not being a guru in XML I didn't understand why, but I actually put it in the same promotion, but at the point below:

<FeatureDoubleMoves/>
<bQuellAnimosity>1</bQuellAnimosity>
<UnitCombats>

When I put it elsewhere it threw an error. Thought you would understand that error better than me. Also, do you have the schema change for the new tag? It was in a new copy of the unit shema XML.

Ah forget it I think I found what I was looking for. But a question. Is it possible to give not one but 3 animosityprotagonists? We will need this for daemonanimosity for the chaos civ.

Click to expand...

No problem, but I will have to change the code to deal with up to 3 returns though. Give me a day or two

I'm currently integrating animosity to the game.
thing I'd like to have changed:
-the promtion to quell animosity should only affect units in the same tile. Blackorcs leading a stack should quell all squabbling in their stack but shouldn't prevent being attacked by neighbor stacks.

Click to expand...

I was thinking this also, but it's easier to change back to single plot, than expand the code to adjacent plots. Will only take an hour or 2 to do and test, but I'll probably upload with the triple protaganist.

El Loco Mono said:

Yeah I noticed that when I didn't put it in the right place. Not being a guru in XML I didn't understand why, but I actually put it in the same promotion, but at the point below:

<FeatureDoubleMoves/>
<bQuellAnimosity>1</bQuellAnimosity>
<UnitCombats>

When I put it elsewhere it through an error. Thought you would understand that error better than me

Click to expand...

No I'm sorry just an editor of xml. I don't understand its structure. I'll try at that position again

No, still get that error. I think you must define that tag in the unitschema but I don't know how.

Ploeperpengel said:

No, still get that error. I think you must define that tag in the unitschema but I don't know how.

Click to expand...

Man your quick on the reply! here's the schema change

EDIT: Forgot the second part of the schema change