Requesting following features

If you think it will be too dificult then do the rest and we can work on that later :D
 
Its actually OK since I haven't really done much work at this particular end, yet. So things can basically be setup any-which-way you like. But I may still end up with something that works, that makes sense and is based on your design. If that doesn't work well enough, then we can rework it in testing.
 
There might be some problems in the Ethnic Buildings Mod.
Not sure I can cover all of the building's appearances, as some of the calls are done directly from the EXE so I can't add the 'which player are we talking about' parameter.

I still need to investigate though, cause I may be able to add this parameter in the places we need them.
Which are important to you?
Building model in the world map.
Building model in the city screen.
Building button in the city orders screen
Building button in the city bar in the world map
civilopedia (button / 3d model).
Anything else?

I still need to check which of these I can control, but if I can't in something that you need, I might better not do this.
 
you should try... I don't mind about the civlopedia or the buttons... just the world map and in the city screen
 
one rebellion at a time and after 5 turns the civ can receive a new rebellion (even if the former has not ended) multiple rebellions can happen at the same time but only in different players

roman and gaul can both have a civil war spawn at the same turn!
Ok, I'm writing something related to this now, so these is my initial thoughts.

Having 10 major playable Civs (right?) which are valid for rebellion (right?) lends itself to only checking one player per turn for rebellion. This, coupled with exiting the code once a rebellion does happen (so that all cities aren't checked), would mean that any one player can only have a rebellion once every ten turns. But if we check two Civs every turn (not as convenient, but doable) then we don't have to keep track of when the last rebellion occurred (since the player isn't checked again for 5 turns) - which is very convenient. And this is what you need, right?

But, I need to make sure that Rome and Gaul are always checked on the same turn, right? Math is not my strong suite but I need to find a way to check the Civs in pairs in a fashion that checks players 0 and player 3 on the same turn. (0 and 4 would have been extremely convenient.) Or I could just hard-code the sequence in some way that pairs the players together in some fashion or another.

If you like, you could just pair up all the rebellion valid players two and two. Rome and Gaul would be one pair, Greece and Egypt could be another, Briton and Germania, and so on. Anything you like, really. Then it would be easy for me to put all these values into a data structure of some sort:
Code:
tRebellionTurnPlayers = ([COLOR="Red"](0, 3)[/COLOR], (1, 2), (4, 5), (6, 9), (7, 8))
That solves the problem in a somewhat elegant fashion, but you could simply switch the player's places in the WBS so that the first and fifth player make up the first pair, the second and the sixth is the next one, then the third and the seventh, and so on. Then it would simply be a matter of mathematics to check the appropriate players each turn.

I don't know if any of this makes any sense to you. But what I'm doing is to write code that loops as few cities as possible every given game turn. Because checking all cities every turn would result in lag - at least once the game progresses and the map is filling up with maps.
 
8 playable civs and yes all are eligible for rebellion... sounds good pair them up if you want just as long as it works i'm fine with what you suggest
 
No, it turns out I was wrong on the math. :rolleyes: Would it be possible for you to move Gaul to player slot 4 instead of 3 (in the WBS)? Because this would allow for a simple operation:
Code:
iIndex = iGameTurn % 4
tGameTurnPlayers = iIndex, iIndex + 4
This way the values in the tGameTurnPlayers array would always be the pairs 0 & 4, 1 & 5, 2 & 6, and 3 & 7. No need to hard-code anything at all. And then the code would only check these two players on any given game turn, which means 1/4 of the potential lag compared to checking each and every players on every single game turn.

By the way, is the Byzantine player also valid for rebellions? In that case it would be convenient if you could put in slot 8... (Perhaps we should check three players each turn, making the interval between checks 3 turns instead of 5?)

edit: This is the actual prototype for the code responsible for checking and initiating rebellions as to your specifications:
Spoiler :
Code:
def checkRebellion(iGameTurn):
    iIndex = (iGameTurn + iRandomSeed) % 4
    for pCivPlayer in (instance(iIndex), instance(iIndex + 4)):
        if not pCivPlayer.get(CyPlayer).isAlive(): continue
        lCities = pCivPlayer.get(PyPlayer).getCityList()
        lCities.reverse()
        for pCity in lCities:
            if checkClasses(pCity):
                break

def checkClasses(pCity):
    for rebellionClass in tRebellionClasses:
        if eval(rebellionClass + ".checkConditions(pCivPlayer, pCity)"):
            eval(rebellionClass + ".initRebellion(pCivPlayer, pCity)"):
            return True
What it does is it figures out on its own what two players to check each turn (assuming you move Gaul from slot 3 to 4, of course) and dynamically checks all cities against the various types of rebellions (defined as sub-classes of the parent Rebellion class template) for validity. If a valid city is found the code will initiate the current type of rebellion and stops looking up any further cities. Repeat with the second player's cities.

This reminds me that the various types of rebellions will need to be put in a hierarchical order at some point. This will be the order in which they are checked against player cities. This matters since the code will exit once any city is valid for any type of rebellion - making the type listed first more likely to happen than the last one. But this will be really easy to adjust once we get to the testing phase.
 
Wait a minute... Players 8 and 9 (the independent ones) are also valid for the rebellion feature? :confused: Because this would make 10 players + Byzantium, possibly.
 
no the independant ones are not valid... I will not move gaul :lol:, just pair rome up with greece etc, it doesn't matter who is paired with who... I will probs have to add in all civs? I definatly have to add byzantium, but will I have to add in the 9 rebel factions?
 
Perhaps we don't need to pair any players up? This would mean that each player is checked every 8 (or 9 counting Byzantium) turns. Sounds good?

You should add all players into the WBS because then they will get pre-defined index numbers, which is very convenient for me. If Byzantium is rebellion valid you should add it as player 8 (the ninth player). Also, the various kinds of rebel players should be entered into the WBS in the same order as their proper counterparts. Because then I will be able to pair them up with simply adding 8 (or 9) the main Civs player ID. So, in other words:

0-7: playable civs
8: Byzantium (if rebellion valid)
9-17: civ specific rebels
18: Slaves civ
19-20: independent minor civs

So I'm counting 21 players/teams in your mod, then?
 
I was looking at your design to see what the default way of setting the number of rebel units might be. I came across this updated entry:
Type - Occupational Rebellion

Sample Conditions - Occupation (not too common)

Civ Claimant - Original owner

Number of Units - original calculations

Type - Original owner's tech level

Termination - None

Misc - Revival of civ, Chance of rebellion ends (therfore turning into domestic rebellions) after some turns after capture (not sure how many though...)
By "original calculations" you mean "the highest of the number of foreign nationals - or the city's unhappy level minus city garrison size"? Because this is what the current Rebels module says:
Code:
iNumRebels = max(iForeigners, pCity.unhappyLevel(0) - pCity.getMilitaryHappinessUnits())
 
I guess... that is a lot of players lol! :lol: Byzantium is not valid for rebellions...

the calculations we decided on before I wrote that post are the originals...
 
Ok... I'm not finding the "original calculation" though. :blush: Perhaps you could just add it to the occupation entry in main post for reference?
 
stupid me: iPopulation / 2 * iUnhappyLevel + iDistance I thought that this was the original calculation but this is for domestic... Um... any ideas for the occupational calculations then?

EDIT: added in the above calculation into the domestic spoiler as an OR (just if the other is unbalanced...)
 
Another thing: I've added three different in-game messages (dynamically color-coded depending on what the Civ the human player is controlling) to the new-and-improved Rebellion module:

The first one is when the Rebellion breaks out, something like "The city of <city name> is experiencing a rebellion!"

The second one is when rebel units are spawning - other than the initial event (in case you wanna go this route, with continuous spawns during the duration of the event). Like "Rebel units are forming outside of <city name>!"

And the third one is when the rebellion ends (when all rebel units are destroyed, by default), like "The rebellion in <city name> has ended!"

Now, you will be able to edit these messages yourself with ease. Also, you can have unique messages for each type of rebellion if you like (otherwise the default will be shown). It is also possible to not have any message for any specific type of rebellion.

Furthermore, I suppose that any messages need to be restricted to cities known by the human player? (Well, not for testing but at least for release, right?)
 
I guess cities unknown should not appear... later we will make these into a sperate text XML file so that languages can be used but nice with the colours!
 
About the text messages: I restricted them to only known cities. Support for translations is already in place. :D

About the number of rebel units for occupation rebellion: I already explained the present calculation - that doesn't work? Because you wanted to cap the number somehow, right? (The rebel units weren't supposed to be able retake the city, or something.)

As for a "default" calculation I've used this for the template Rebellion class:
Code:
    def setNumUnits(self):
        pCity = self.getCyCity()
        iUnhappyLevel = pCity.unhappyLevel(0)
        iPopulation = pCity.getPopulation()
        self.iNumUnits = max(1, min(iUnhappyLevel, iPopulation))
In plain English it means that the number of rebel units is equal to the unhappy level of the city - capped by the city size. (Because the unhappy level can be larger than the actual city size.) But, there will always be at least one rebel unit even if the city's unhappy level would be zero (not likely but anyways).

Each rebellion will of course have its very own setNumUnits() definition containing the calculation specific to that type. With your current setup this default method will actually never be used - its more of a place holder at the moment. But its available if you wanna use it - or we could change the default calculation to something more useful (preferable something that can be used for several types of rebellions, if possible).

edit: But as stated earlier - its probably best to have alternate calculations or some sort of caps (upper/lower) for most rebellion types as far as numbers of units are concerned. These are best described as the highest/lowest of calculation 1 and calculation 2 - or whichever is higher/lower of calculation and a fixed value (cap). Or a combination like "city size OR number of angry citizens - whichever is lowest - but at least 2 units". Then its just a matter of writing the code to match - don't feel restricted by how the calculation would be formatted. Let me worry about that. :p
 
Other stuff I've already built into the new module is support for one free unit promotion for each rebellion type, and also the option to set the unitAIType of the spawning units (UNITAI_ATTACK_CITY is the default).

We don't have to mess with any of this now but since the code is already done its not really much more work if you do add these parameters to your design.
 
Ok, I'm testing the default rebellion class now with varied results. Since the code is already several hundred lines long it will take some time to find all mistakes.

But it did dawn on me that one city probably shouldn't be hit with several rebellions at the same time. Not that it really happens as such, but since the same city will be checked again 8 turns later, its conceivable that it will be valid for some flavor of rebellion that time around also - even if the first one is still ongoing. (It could of course be the same type also.)

So is there a need to keep track of which cities are currently in rebellion and automatically exclude those from any further checks? Or should these things not be allowed to drag on for 8 full turns? (Because another option would be to terminate all ongoing rebellions in a city if one is already in progress. This could mean that all lingering rebel units are deleted and replaced with new ones.)

edit: I believe that I fixed it. Any city should now only experience one rebellion at a time. But this also means that there probably needs to be some default termination condition - other than that all rebel units are killed. Like a turn limit upon which a rebellion is over - killing any remaining rebel units.
 
sounds good! I recently added a new colour to the interface and music so will be in for a surprise next time you test on it!
 
Back
Top Bottom