.

Hey El Loco Mono. I like the Fur thing, hopefully it will add a little spice to the early game. I've always tried to put myself next to an animal but in a very well defendable position, but now it will be more worthy to actually attack, so it opens up some decisions for the player. I think this might have been able to be done in python (using the onCombatResult python callback). I know you said you were worried that you might go overboard on the SDK stuff :P
Click to expand...

Cheers for the feedback Gerikes,

Hmmm, indeed, I might look at the python and see if I can shift out the function work as I would like to keep my work tidy and inline with the mod design (wahoo my first python code ever maybe...), but your right, this is the type of thing (changing the SDK instead of the python ) I'm liable to do at the moment. Is the general rule, if no new functions are needed, it can be done in Python?

I agree on the constant in the global defines file - I just got the SDK a few days ago and haven't got round to looking at all the files and how to link changes together yet (including this one - I only get 2 or 3 hours max to look into the mod stuff a day), it's why I was looking for a decent chuck of work to "explore" the code with.

So we are waiting on animosty - may I ask if this is being done by anyone yet? As long as I know the idea of how it will work I'm quite happy to go for it.
 
@E.L.M.

I would be happy if you gave it a start.:)
I think Olleus wanted to do most of the psychology but that didn't inlude animosity yet.
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.

Edit: btw thx for the animals and stacks- included in the latest patch. I'm going to test now:)
 
... just wanted to say, that i am very very happy, that we have you programmers on board, now the mod will get some more uniqueness in an even shorter amount of time than i ever dreamed of!!!

keep on the good work!!!
 
I'm wondering if we might be able to make that hardcoded 7 something that can be set in the global defines, that way people can change it without having to recompile.
Click to expand...

I set up the constant in the Global defines folder, by I won't upload the changes until I've got the basic Animosty code working (is about 40% done - but I should get some testplaying on v9 done first, that was what my orinal input was supposed to be ;) ). The changes were small so if anyone is interesting there here:

Spoiler :
In CvPlot::isUnitSpace function

ORIGINAL :: if (iNumUnits >= 7)

NEW :: if (iNumUnits >= (GC.getDefineINT("STACK_SIZE_MAX")))

Also in the Global Defines
<!-- Controls the stack size limit -->
<Define>
<DefineName>STACK_SIZE_MAX</DefineName>
<iDefineIntVal>7</iDefineIntVal>
</Define>


Why is there a maximum stack size?
Click to expand...

Sorry Lord Olleus, it was a continued discussion from the test feedback. In retrospect I should have posted the plans in this thread first and waited for some feedback. But with the Global define you could set a stupid huge number so it wouldn't matter. And yes, the domain (sea, air, land) is taken into consideration when counting the units in the stack (so you could have 7 galleys each with 7 units in the same plot)
 
@E.L.M.
I like that new type of "playtestfeedback":D

@Olleus
1.)Why should a stacklimit make collateral damage unattractive? I think on the contrary you really get a chance to wype a stack out.
2.)A city has 8 tiles surrounding it and this gives a maxnumber of 56 units being able to attack in one turn(not counted cavalry that can pass tiles after some units of the stack were killed-not to mention elves). I have no doubt capturing a city should be possible with this.;)
 
@Olleus
1.)Why should a stacklimit make collateral damage unattractive? I think on the contrary you really get a chance to wype a stack out.
2.)A city has 8 tiles surrounding it and this gives a maxnumber of 56 units being able to attack in one turn(not counted cavalry that can pass tiles after some units of the stack were killed-not to mention elves). I have no doubt capturing a city should be possible with this.;)
Click to expand...

I thought LO was talking more about how collateral damage and SF will make stacks unattractive already without having to implement a stack limit.

Personally, I don't like the idea of a stack limit, since I think capping a stack is a pretty drastic change. I think that if people want to have a SOD, then let them have it, but make sure that a player that has better management of their units by properly spreading them out and flanking and such will have an easier time. I think you'd be alienating all your hardcore SOD players by disallowing them to exist, when all you really want to do it make it tougher for them.
 
Ah ok misunderstood the first point then it seems. Still it's a good way to make the AI spreading out its forces imo.
Well whatever it will be configurable and I can write how to change the stacklimit into the mod's readme that should be enough don't you think?
 
The idea of Stack-limitations brings me to another idea (and it&#180;s really just an idea):

What about limiting the units on one plot to WH like Armies?
This would, as far as my opinion is concerned, not mean to limit one plot to a maximum number of units, but maybe limit one plot to percentages of units like they are defined in WH (Core, Special, Rare etc.) this may include a new tag for UnitInfos.xml like "<WHUnitType>Core</WHUnitType>"

That way we could maybe actually implement the idea of "Special, rare..." units?
 
Hm I think this would be to complicated for the player. He would be wondering all the time why he can't stack certain units and we'd get a lot of stupid bugreports.
But we indeed need a concept more flexible than national units to restrict building of certain units in general. I prefer seeing all troops of a player as the army (not a single stack) where rare and special choices should get a percentage count to trigger their buildability.
 
In this case we should make sure, that the units that are most-permanently stationed in the players cities are not only counting towards the core units (like only stationing Archers [which might be core-units] in cities) but also towards either special- or rare-units. So a player can&#180;t only attack with those special- rare-units like Silverhelms, Seaguard etc.

But I got no clue how we could do this?!?
 
yepp, I think you didn&#180;t really understand me here.

let&#180;s say A player builds 100 units - 10 % are rare - 20 % are special - 5 % are champions, heroes, whatever.

So he has 35% "unique" units.

65% of his units are core.

but 40% of his total units are stationed in his cities permanently (keeps them there for defence, happyness, reserve, whatever). But almost all of those units are Archer-types (because they are the best for city-defense).

Then the total % of "unique" units that the player actually uses on the battlefield/frontline will drastically increaese (because the normal units aren&#180;t used for warfare but only for city defense)!
 
Duke van Frost said:
yepp, I think you didn´t really understand me here.

let´s say A player builds 100 units - 10 % are rare - 20 % are special - 5 % are champions, heroes, whatever.

So he has 35% "unique" units.

65% of his units are core.

but 40% of his total units are stationed in his cities permanently (keeps them there for defence, happyness, reserve, whatever). But almost all of those units are Archer-types (because they are the best for city-defense).

Then the total % of "unique" units that the player actually uses on the battlefield/frontline will drastically increaese (because the normal units aren´t used for warfare but only for city defense)!
Click to expand...

Perhaps we need a new thread on this? I think it also kind of ties in the discussion of stack limits as well.
 
Sorry, I was away with work and didn't access to Civ or the code. Cheers Gerikes for putting the define and the fix in.

OK, should get some testing feedback tomorrow but first some comments on Animosity:

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.
Click to expand...

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 :crazyeye:

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.
 
Well, i really love those animosity ideas, they are all exactly whats in the orcs armybook, but i think that there should also be a chance to get a good result from animosity, say the affected unit get a temporary 'enraged' promotion which lasts untill he next attacks. this gives that unit some % of extra strength, or a blitz like ability. this promotion would mean that the animosity trait for orcs wont deter people from playing them, becaue thier units wont ALWAYS be arguing amongst them.

Which brings me to another point: when do orcs get affected by animosity? is it only during peace time? only during war? or all the time? i wold way only during peace, as it would make them more war like.

(i apologiseif thats already been said, i think it has, but oh well. :p)

@E.L.M. great work there, keep it up:thumbsup:, i think Show'em should only allow the unit to charge nay enemy in thier line of sight. so if the can see an enemy unit 4 squares away, and that is the only one they can see, they will charge that. but if there is another one, 2 squares away, they will charge that one instead because it is closer.
 
You must log in or register to reply here.

Similar threads

Gen.Washington
My solution to civ switching.
2 3
Replies
55
Views
2K
Crashdummy
C
disjointaccount
Leader Discussion - Friedrich, Oblique
Replies
5
Views
309
Calcifer
Calcifer
K
Need help with modding!
Replies
0
Views
91
Kaverin_Ramil
K
Mesix
Achievements difficult to trigger
Replies
3
Views
146
Mesix
Mesix
K
Civ-Switching
4 5 6
Replies
112
Views
4K
j51
j51
Back
Top Bottom