Normally, I post new features in the Download thread. This time, however, it's a large enough shift that I'd like suggestions on how exactly to balance it. ;)


First, let me describe the basics of the new system: Rather than a chance each turn to spawn an Adventurer, something that is highly random and unpredictable, we now have a counter that increases each turn.

Think of it as a return to the steady, predictable GP system, without the limitation of being unable to use other GPs. ;)


Some details:

Here's the Adventurer Counter formula:

iGrigoriSpawn = iGrigoriSpawn + ((iNumPalace + iNumMuseums +iNumTaverns + iNumGuilds + iCivicMod) * iGrigoriMod)
iGrigoriSpawn - This is the variable used to keep track of the total.
iNumPalace - Will always be one after you found a city, just used to prevent it from running on the first turn.
iNumMuseums - Number of Museums you own.
iNumTaverns - Number of Taverns.
iNumGuilds - Number of Adventurer's Guilds.
iCivicMod - If you are following Apprenticeship, this is equal to 2. Otherwise, 0.
iGrigoriMod - This is the variable used to increase the cost with each Adventurer. Initially set to 1, it is decreased by 10% each time you spawn an Adventurer.
This does NOT mean by 0.10. Rather, it's a percent... Will decrease like this: 1 -> 0.9 -> 0.81 -> 0.739, etc

Now, this is just what I used to test it. I'm willing to listen to any reasonable suggestions as to how to balance this. ;) I'm hoping to have it well balanced for the first version, rather than needing to rebalance it multiple times.


Edit: One thing I could change easily would be to change the way iGrigoriMod works... Rather than modify the formula itself, I could use it to increase the amount needed to spawn an adventurer directly. So rather than always needing 100, I could increase it to 110, 120, so on. Would have to think on how to show this correctly in the display, though. ;)

Let's see.

The first adventurer will come at roughly FfH speeds. You start with 1/100 per turn but education, a top priority tech, will triple that(apprenticeship is an early no brainer) and you can cancel out the slower start with a push from mysticism - with 2 cities and a few hammers you can get to 5/100.

After the first one things kick into really high gear. The second standard GP costs 3 times as many points as the first, but under this new system, in order to triple the cost of an adventurer compared to the first one you need to spawn like 7 of them. Meanwhile iGrigoriSpawn will keep increasing at rates well beyond normal FfH. Each city you get will add 1 more with a museum, and then you hit currency, spam guilds, and double this bonus. With 6 cities and no apprenticeship - a reasonable midgame estimate - you can have 13 points per turn, which gives you quite a steady stream of heroes, something like once every 15 turns if you have already popped 5 of them.

Oh, and you get regular GPs at a normal rate independent of this.

I can't draw a direct comparison to the current random system because I don't know the code and I only just downloaded RfE, so I have no emprical data. (I found a post of yours containing precise figures for the random system, but it's old and from before the system was implemented - the values have probably been revised since.) But it's quite the buff compared to the FfH/FF version, all told.

But the grigori are crap right now, so I'm okay with this, especially because the buff becomes really big around midgame where the grig are terribly deficient at war.

Let's see.

The first adventurer will come at roughly FfH speeds. You start with 1/100 per turn but education, a top priority tech, will triple that(apprenticeship is an early no brainer) and you can cancel out the slower start with a push from mysticism - with 2 cities and a few hammers you can get to 5/100.

After the first one things kick into really high gear. The second standard GP costs 3 times as many points as the first, but under this new system, in order to triple the cost of an adventurer compared to the first one you need to spawn like 7 of them. Meanwhile iGrigoriSpawn will keep increasing at rates well beyond normal FfH. Each city you get will add 1 more with a museum, and then you hit currency, spam guilds, and double this bonus. With 6 cities and no apprenticeship - a reasonable midgame estimate - you can have 13 points per turn, which gives you quite a steady stream of heroes, something like once every 15 turns if you have already popped 5 of them.

Oh, and you get regular GPs at a normal rate independent of this.

I can't draw a direct comparison to the current random system because I don't know the code and I only just downloaded RfE, so I have no emprical data. (I found a post of yours containing precise figures for the random system, but it's old and from before the system was implemented - the values have probably been revised since.) But it's quite the buff compared to the FfH/FF version, all told.

But the grigori are crap right now, so I'm okay with this, especially because the buff becomes really big around midgame where the grig are terribly deficient at war.

Well, the values I listed were simply for testing purposes... This is the first global variable I've added using python. :lol:

Although I'm already adding the variables themselves to CvPlayer, as pure python isn't saved if you completely exit Civ.... :mischief:

Anyway. Actual values will likely be lower. I think the Civic/Palace values will stay the same... Others will be reduced in value based on how early/cheap they are. I'm also leaning towards having the mod change the amount required, rather than amount gained... Can display it like this:
GrigoriSpawn / GrigoriMod
GrigoriSpawn would be the total points you possess, as now. GrigoriMod would be rewritten to be the amount of points required. So say you have 48 points, and require 120... Next to the Mana Bar you'll see:
[Adventurer Button Icon] 48 / 120
I think that will be clear enough, yes?

And yes, overall it's a boost from FfH... It might actually be a nerf from the previous system in RifE, depends on how you look at it. On the one hand, currently you have the potential for a large amount early on... On the other, the random number generator can also screw you, giving you nothing. :lol: This system is predictable.

Since I wasn't clear at first: Yeah, I like the concept of handling it this way. It makes the mechanic stronger than in base FfH for a civ that desperately needs it, removes from RfE the current random style that makes me hate playing Scions, and is easy enough to display in the UI like you described. I was just mulling over the specifics.

On how exactly the grigmod works: It doesn't really matter balance wise, does it? It does the same thing either way, with only the specific values mattering. I guess if having it increase the cost makes it easier to display, go for it.

If you make museums and guilds less effective, you'll nerf the spawn rate fairly evenly throughout the game, since early empires have apprenticeship to pick up some of the slack and lategame ones have taverns. This strikes me as the best solution if you're going to nerf the mechanism from your original outline, because they still keep the big mid-to-late boost, since costs still scale up pretty gently. That's the most important thing the grig need to get out of this, imo.

Since I wasn't clear at first: Yeah, I like the concept of handling it this way. It makes the mechanic stronger than in base FfH for a civ that desperately needs it, removes from RfE the current random style that makes me hate playing Scions, and is easy enough to display in the UI like you described. I was just mulling over the specifics.

Actually, you were very clear. Glad you like the idea. ;)

One thing that's bugged me in your posts, as trivial as it is: The correct acronym is RifE. Not RfE. ;) Only reason I mention it is the name just changed, so I'd like to get people in the habit as quickly as possible. :lol:


On how exactly the grigmod works: It doesn't really matter balance wise, does it? It does the same thing either way, with only the specific values mattering. I guess if having it increase the cost makes it easier to display, go for it.

Actually, it's potentially VERY important. Whereas simply reducing the amount works, it doesn't work well when you get to higher numbers of awakened... While increasing the cap is a much more intuitive mechanic, easily visible, MUCH easier to balance, and all around better. Only reason I didn't go with it originally is I hadn't thought of how to display it... While setting it up, the display was the last thing I did. Was working on it still when I made the thread. :lol:


If you make museums and guilds less effective, you'll nerf the spawn rate fairly evenly throughout the game, since early empires have apprenticeship to pick up some of the slack and lategame ones have taverns. This strikes me as the best solution if you're going to nerf the mechanism from your original outline, because they still keep the big mid-to-late boost, since costs still scale up pretty gently. That's the most important thing the grig need to get out of this, imo.

I agree, seems like the best setup to me too.

Alright. The variables are now stored in CvPlayer, in the DLL, so they persist across save games. ;)

I've also changed the system, like discussed above... iGrigoriSpawn is the total of the value of your buildings/civics, and iGrigoriMod is the required amount to spawn. Works nicely. ;)

For modders looking to steal the setup: I used int tags rather than float, so the both values must be modified thusly: iGrigoriSpawn = int(iGrigoriSpawn * 100). When calling it, simply use (pPlayer.getGrigoriSpawn() / 100) to get the correct value. ;)

Aside from that little note, everything is easy to understand and clearly marked in the DLL... Will be posting an updated source in just a few minutes, and if anyone wants the python now I'll upload it. ;)

One thing to add: With this new setup, I can modify the total based on events. Will probably put a few of those in eventually, if not right away. ;)

the event guy within me loves the last part of the idea ^^

Have you though about linking it to a trait?

As things are, it's not obvious how adventurer spawning works with things like Tolerant. If Grigori got Adventurers as a result of a civ trait it would be obvious.

Great idea Valkrionn!!! Really great.
I just yesterday explained to Opera why I do not like current method of spawning adventurers/awakened.
And it can be easily adopted for awakaned, right?
It is dll mostly, right? I really want to get rid of it from python.

Regarding increasing cost, I beg you to go the way that allows more precise setting. While I quite like the asymptotic reduction of points generated, increasing required amount seems like the way to go. More intuitive and easier to link modifiers with predictable results.

Odalrick is right, linking it to trait or even better to civ info would be great for providing info to players.
Civ info I think is better as both adventurer and awakend are very civ specific - no need to add separate trait that does just that.
Maybe a trait that increases the rate though? I.E. for Menec from LENA (and Orbis)

Waiting for the complete code to dig into :)
If you need any help, feel free to ask.

Perhaps every exploration of a dungeon or whenever the Grigori borders encompass a dungeon or epic lair the number would rise.

Have you though about linking it to a trait?

As things are, it's not obvious how adventurer spawning works with things like Tolerant. If Grigori got Adventurers as a result of a civ trait it would be obvious.

It could be, yes. At the moment everything but storing the variables is done in python. I put those in DLL in order to maintain them when you exit/reload the game.... Eventually I'll probably make two new tags for civs: 'SpecialUnitSpawn' and 'SpawnUnit'. One is a bool, simply turn on/off, other is used to list the type of unit.

Then add some new tags to buildings/events/civics/religions to allow you to modify the amount stored each turn.

Won't be doing any of that until after the patch though. As it is, I was planning on using just python.... The bit of DLL work snuck up on me. :p

Great idea Valkrionn!!! Really great.
I just yesterday explained to Opera why I do not like current method of spawning adventurers/awakened.
And it can be easily adopted for awakaned, right?
It is dll mostly, right? I really want to get rid of it from python.

Regarding increasing cost, I beg you to go the way that allows more precise setting. While I quite like the asymptotic reduction of points generated, increasing required amount seems like the way to go. More intuitive and easier to link modifiers with predictable results.

Odalrick is right, linking it to trait or even better to civ info would be great for providing info to players.
Civ info I think is better as both adventurer and awakend are very civ specific - no need to add separate trait that does just that.
Maybe a trait that increases the rate though? I.E. for Menec from LENA (and Orbis)

Waiting for the complete code to dig into :)
If you need any help, feel free to ask.

Why don't you like awakened spawning? Not planning to change that one myself. :lol:

It's still python that does the actual work... But the spawn code is vastly simplified. Mostly because there's no need for so many modifiers anymore... It's not a random chance, it's a stored variable. ;)

Yeah, I've already gone that route with the costs. Rather than reduce the points you generate, I increase the costs. I did it the other way at first because I wasn't thinking about how I'd display it yet, and was thinking I'd have just the one number... I'll post a screenie of the new display soon.

An entirely DLL-based system is something I want to do, like I mentioned above, but don't have the time before this weekend... When I'm going on a vacation for a week or two with some friends I haven't seen in a while. Essentially, a drunk roadtrip, until we're out of money. :lol: Main reason I want the patch out this week. ;)

Perhaps every exploration of a dungeon or whenever the Grigori borders encompass a dungeon or epic lair the number would rise.

That could be interesting....


And one thing I neglected to mention, is that one of the main reasons I want it in python for now is the ease with which it can be balanced. Once we've got it right, it can be moved to the DLL. ;)

As promised, here are some screenshots....

http://i217.photobucket.com/albums/cc310/Valkrionn/Civ4ScreenShot0004.jpg

http://i217.photobucket.com/albums/cc310/Valkrionn/Image1-2.jpg


Now I'll post the relevant bits of python... Ahwaric, these just overwrite what should already be in CustomFunctions and MainInterface.

As of now, I'm not using any buildingmods, just the number of buildings... Those will be added back, so it's just commented out. Same goes with the gamespeed adjustment. I'm not sure on whether or not to include a modifier for the AI... Probably should, but I won't drop the human rate to do it. I've also left the original formula in a commented out section, as reference. Using php tags in order to highlight the commented sections.

CustomFunctions.py
# Start Grigori Adventurer spawning

def doTurnGrigori(self, iPlayer):
pPlayer = gc.getPlayer(iPlayer)
pCapital = pPlayer.getCapitalCity()
iAdventurer = gc.getInfoTypeForString('UNIT_ADVENTURER')

iGrigoriSpawn = pPlayer.getGrigoriSpawn()
iGrigoriMod = pPlayer.getGrigoriMod()

self.doChanceAdventurerSpawn(iPlayer)

if iGrigoriSpawn >= iGrigoriMod:
spawnUnit = pPlayer.initUnit(iAdventurer, pCapital.getX(), pCapital.getY(), UnitAITypes.NO_UNITAI, DirectionTypes.DIRECTION_SOUTH)
pPlayer.changeGrigoriSpawn(0 - iGrigoriSpawn)
pPlayer.changeGrigoriMod(1000)




def doChanceAdventurerSpawn(self, iPlayer):
if iPlayer == -1:
pPlayer = gc.getPlayer(gc.getGame().getActivePlayer())
else:
pPlayer = gc.getPlayer(iPlayer)

iGrigoriSpawn = (pPlayer.getGrigoriSpawn() / 100)

if pPlayer.getNumCities() > 0 and pPlayer.getCivilizationType() == gc.getInfoTypeForString('CIVILIZATION_GRIGORI'):

iAdventurer = gc.getInfoTypeForString('UNIT_ADVENTURER')
iAdventurerClass = gc.getInfoTypeForString('UNITCLASS_ADVENTURER')
iMuseum = gc.getInfoTypeForString('BUILDING_MUSEUM')
iTavern = gc.getInfoTypeForString('BUILDING_TAVERN_GRIGORI')
iPalace = gc.getInfoTypeForString('BUILDING_PALACE_GRIGORI')
iGuild = gc.getInfoTypeForString('BUILDING_ADVENTURERS_GUIL D')
iNumMuseums = pPlayer.countNumBuildings(iMuseum)
iNumTaverns = pPlayer.countNumBuildings(iTavern)
iNumGuilds = pPlayer.countNumBuildings(iGuild)
iNumPalace = pPlayer.countNumBuildings(iPalace)

# Different buildings give different modifiers. Aristocracy gives a +66% mod. (
# iPalaceMod = iNumPalace
# iMuseumMod = iNumMuseums * 0.5
# iTavernsMod = iNumTaverns * 0.15
# iGuildsMod = iNumGuilds * 0.25
iCivicMod = 0.00
iCivicMult = 1
if pPlayer.getCivics(gc.getInfoTypeForString('CIVICOP TION_LABOR')) == gc.getInfoTypeForString('CIVIC_APPRENTICESHIP'):
iCivicMod = 2
iCivicMult = 1.25

# Modifies the rate based on gamespeed.
# iSpeedMod = 1
# estiEnd = CyGame().getEstimateEndTurn()
# if ( estiEnd >= 1500 ):
# iSpeedMod = 2.0
# elif ( estiEnd >= 750 ):
# iSpeedMod = 1.5
# elif ( estiEnd >= 500 ):
# iSpeedMod = 1.0
# elif ( estiEnd >= 330 ):
# iSpeedMod = 0.67
# else:
# iSpeedMod = iSpeedMod


# Difficulty level modifier
# iHumanmod = 1
# iAImod = 1
# if pPlayer.isHuman() == True:
# iDifficulty = gc.getNumHandicapInfos() + 1 - int(gc.getGame().getHandicapType())
# iHumanmod = .5 + (iDifficulty * 0.1)
# iAImod = 1
#
# if pPlayer.isHuman() == False:
# iDifficulty = gc.getNumHandicapInfos() + 1 - int(gc.getGame().getHandicapType())
# iAImod = .7 + (iDifficulty * 0.1)
# iHumanmod = 1

# default adjustments of gamespeed training are M =2, E = 1.5, N = 1, Q = .67
# iGrigoriSpawn = round(((iPalaceMod + iMuseumMod + iTavernsMod + iGuildsMod + iCivicMod + 2) * iCivicMult * iGrigoriMod * iHumanmod / iSpeedMod * 0.01 / iAImod),2)

iGrigoriSpawn = iNumPalace + iNumMuseums +iNumTaverns + iNumGuilds + iCivicMod
iGrigoriSpawn = int(iGrigoriSpawn * 100)
pPlayer.changeGrigoriSpawn(iGrigoriSpawn)

return iGrigoriSpawn
# End Grigori
MainInterface.py
#Adventurer display
elif pPlayer.getCivilizationType() == gc.getInfoTypeForString('CIVILIZATION_GRIGORI') and pPlayer.getNumCities() > 0:

#figuring spawn chance

fGrigoriSpawn = (pPlayer.getGrigoriSpawn() / 100)
fGrigoriMod = (pPlayer.getGrigoriMod() / 100)
#/figuring spawn chance
if fGrigoriSpawn > 0:

SRstr = u"<font=2i>%s</font>" %(str(" ") + str(fGrigoriSpawn) + str(" / ") + str(fGrigoriMod) + str(" "))
screen.setImageButton("Adventurerchance", "Art/Interface/Buttons/Units/Adventurer.dds", 182, 7, 16, 16, WidgetTypes.WIDGET_GENERAL, -1, -1 )
screen.setText( "SRText", "Background", SRstr, CvUtil.FONT_LEFT_JUSTIFY, 194, 5, 0.5, FontTypes.GAME_FONT, WidgetTypes.WIDGET_GENERAL, -1, -1 )
screen.setHitTest( "SRText", HitTestTypes.HITTEST_NOHIT )
else:
screen.hide( "Adventurerchance" )
screen.hide( "SRText" )
#/Adventurer display

Slight change... Don't have a screenshot, but I've moved the display up where gold is displayed, rather than next to the mana.

Interesting. I suppose that in order to do the Meritocrat Trait that I had planned for Goodreau, I would need to add a new tag iLeaderMod = 0 or x1.5?

Would be easy to setup like the Spiderkin trait for the Archos.

fMeritocrat = 1
if pPlayer.hasTrait(gc.getInfoTypeForString('TRAIT_ME RITOCRAT')):
fMeritocrat = 1.30

Then change add it to the formula like so:

iGrigoriSpawn = ((iNumPalace + iNumMuseums +iNumTaverns + iNumGuilds + iCivicMod) * fMeritocrat)

Alternatively, you could make it additive....

iMeritocrat = 1
if pPlayer.hasTrait(gc.getInfoTypeForString('TRAIT_ME RITOCRAT')):
iMeritocrat = 3

iGrigoriSpawn = (iNumPalace + iNumMuseums +iNumTaverns + iNumGuilds + iCivicMod + iMeritocrat)

The first method has a smaller effect early on, with a higher effect later. The second method has a higher effect early, less effect later. Or you can do a mix, and balance it out. ;)


Once it's all in the DLL I'll make sure to allow for traits to modify it.

looks promising :goodjob:

if you write it into the DLL you might want to modify it so the whole mechanic can be unlocked not just by civ, but also by trait or tech or similar things.

Oh, I'll be sure to make it widely usable. I may not have plans for using it a certain way, but someone else may come up with something good. ;)

Tentative Formula:

iGrigoriSpawn = round(((iPalaceMod + iMuseumsMod +iTavernsMod + iGuildsMod + iCivicMod) * iCivicMult * iAImod / iSpeedMod), 2)
iGrigoriSpawn = int(iGrigoriSpawn * 100)
pPlayer.changeGrigoriSpawn(iGrigoriSpawn)



iPalaceMod - Number of palaces.

ALWAYS one, after you settle your first city... Makes sure the screen doesn't try to update before anything exists to check. ;) This is the base amount added each turn.

iMuseumsMod - Number of Museums, multiplied by 0.33

As the first Adventurer-modifying building available, effects are low. Keep in mind it's relatively cheap... Will be spamming these in all of your cities. ;) Need three to increase the rate by a whole number.

iGuildsMod - Number of Adventurer Guilds, multiplied by 0.5

Second available building. Slightly higher effect. Need two to increase the rate by a whole number.

iTavernsMod - Number of Taverns

This one should be your best friend. One by itself will increase the rate a whole number.

iCivicMod - Depends on Civics.

Currently, 0 naturally and 2 if following Apprenticeship. Could be expanded to other civics as well.

iCivicMult - Same as above.

1 naturally, 1.25 if following Apprenticeship.

iAImod - Flat value of 1.5

Essentially gives the AI half again as many adventurers as a human player. They never use them WELL, so having lots of them should help. ;)

iSpeedMod - Based on gamespeed. Keep in mind the value is divided by this number... Higher = Slower.

Marathon - 2
Epic - 1.5
Normal - 1
Quick - 0.67



These values are put into the formula, the result is rounded to two decimal places, the result of THAT is multiplied by 100 and converted to an int... Allows it to be stored properly. That value is then called and compared to the amount needed, in the following formula...

if iGrigoriSpawn >= iGrigoriMod:
spawnUnit = pPlayer.initUnit(iAdventurer, pCapital.getX(), pCapital.getY(), UnitAITypes.NO_UNITAI, DirectionTypes.DIRECTION_SOUTH)
pPlayer.changeGrigoriSpawn(0 - iGrigoriSpawn)
pPlayer.changeGrigoriMod(2000)

iGrigoriSpawn is the value the last formula gave. iGrigoriMod is the amount needed. If the first is greater than or equal to the second, the following things happen:


Adventurer is spawned in the Capital.
GrigoriSpawn is set to 0. Used a 'change' function... Easier to add/subtract the amount stored, more difficult to reset. Ended up 'changing' the value by zero minus itself... Which results in a new value of 0.
GrigoriMod is increased by 2000. Keep in mind that the values stored are 100 times as high as those displayed/used... Made an int to store them in, as that's what I'm used to. :lol: Increasing the variable by 2000 has the result of increasing the cap by 20. I feel that's a reasonable increases... Doubles in cost after your fifth adventurer, but by then enough time has passed that you're earning 2-3 times the amount of points.




All of these values are still subject to change, but I'm reasonably happy with it.

Slight change to the second formula... Bolded the difference.

if iGrigoriSpawn >= iGrigoriMod:
spawnUnit = pPlayer.initUnit(iAdventurer, pCapital.getX(), pCapital.getY(), UnitAITypes.NO_UNITAI, DirectionTypes.DIRECTION_SOUTH)
pPlayer.changeGrigoriSpawn(0 - iGrigoriMod)
pPlayer.changeGrigoriMod(2000)

Realized that due to the way the code is run, often times you'll get the adventurer and have the counter reset the turn AFTER you reach the amount needed. Rather than wipe GrigoriSpawn, I now reduce it by the current cap... Allows you to maintain any extra you accrued. ;)


Now, for a screenshot of the finished display.... It shows the correct, decimal amount, no major rounding, and then displays the cap. I'm satisfied with it... Easy to read, out of the way unless you need it.

Two drawbacks to it's placing.... While not immediately obvious, it is in fact part of the Mana display widget. This means if you close the mana bar, the Adventurer display will also close. The background also makes it difficult to make out the Adventurer icon. I can live with both of those hiccups, though. ;)

Original, unmagnified image:
http://i217.photobucket.com/albums/cc310/Valkrionn/AdventurerDisplayOriginal.jpg

http://i217.photobucket.com/albums/cc310/Valkrionn/Civilization/AdventurerDisplay.jpg

awesome idea, I hate the randomness of the awakened spawning. this will be the first major step towards Grigori+ I guess :p

Looks like a good concept.
Any chance of making Scions Awakened spawning go the same way?

None whatsoever. ;)

I like the randomness of the awakened.... And the Scions hold a rather special place. First thing that got me on the forums was playtesting them. ;)

Should be easy enough for someone to make a module out of it when I move it to the DLL, but I doubt I'd EVER do it in the main mod. :p

Edit: Also, one of the main reasons I didn't like the random spawning for the Adventurers, was it had already been done for the Scions. I want them to function differently, not the same.

Should be easy enough for someone to make a module out of it when I move it to the DLL, but I doubt I'd EVER do it in the main mod. :p

Edit: Also, one of the main reasons I didn't like the random spawning for the Adventurers, was it had already been done for the Scions. I want them to function differently, not the same.
You are right. But I still do not feel comfortable with current awakened mechanics. It causes issues, especially if more than one scions player is in game. Not that common, but still. Of course, the same applies to current adventurer spawning method.

I still want the mechanism moved to dll ASAP, but will wait till you are comfortable with it. If I can have someone do the work, who am I to interrupt ;)
JK, as I said, will try to help.

For now, is there any chance to get my hands on the files? I feel weird adding new functions from forum posts ;)
Just please make sure to mark things tomake them easy to look for :p

You are right. But I still do not feel comfortable with current awakened mechanics. It causes issues, especially if more than one scions player is in game. Not that common, but still. Of course, the same applies to current adventurer spawning method.

I still want the mechanism moved to dll ASAP, but will wait till you are comfortable with it. If I can have someone do the work, who am I to interrupt ;)
JK, as I said, will try to help.

For now, is there any chance to get my hands on the files? I feel weird adding new functions from forum posts ;)
Just please make sure to mark things tomake them easy to look for :p

Like I said on #Erebus ( You people should get on there, you usually here things you wouldn't on the forums. Like certain upcoming projects... Talked about some of the new animals this morning, and a more secret project a few days ago. ), I have plans for how to move it to the DLL.

I'm thinking of allowing the process to be activated by civilization, trait, civic, and maybe religion. Then have it increased (Added to, subtracted to, whatever... Addition/Subtraction only here) by Buildings, Events, Civics, Traits, Religion. Have it modified (division/multiplication) by buildings, events, civics, traits, religion. Wide open field. The starting tags will allow you to set the initial cap, the amount the cap is increased by each time, the initial rate (usually 0 or 1... Something low), what unit is being spawned, and one special boolean tag... AI only.

If AI-only is set to 1, the process will ONLY be started if the player it is attempting to fire off for is an AI. I'll be using that for the Scions, as the AI doesn't understand the random mechanic... Players will still have random spawning though. ;)

All of this will likely wait until a certain other project is finished, but that hopefully won't take me too long. ;)



As for the files, I assume you mean the python? Attached the three necessary files to the post....

CvEventManager I doubt you'll need. It just checks if the player is Grigori, if so fires of doTurnGrigori. Same as before, so you should have that already.

CustomFunctions is where the main changes are, but the changes are to two functions you already have.... doTurnGrigori and doChanceAdventurerSpawn.

CvMainInterface is for the display, but is only one block of code, altered from what you have.

All python is marked by either '# Start Grigori Adventurer spawning' or '# Grigori Adventurer spawning start'.



For the DLL, check these links:

DLL
DLL Spreadsheet

The affected files are CvPlayer.cpp, CvPlayer.h, CyPlayer.cpp, CyPlayer.h, and CyPlayerInterface2.cpp.

The DLL doesn't do anything at this point beyond store the variables... Necessary for save games to function correctly. ;)

This is in the patch, so have fun playing with the new system. ;)

I'm hoping for some balance suggestions over the next few days. :goodjob:

Started a game. Had trouble with the animals (/understatement), so went to hunting rather than beelining education/mysticism. Was only getting 1 point towards that first hundred for the first 50 turns or so, and then building a museum around turn 60 got me a grand 1.3 points. Definitely a large step back, having to wait nearly a hundred turns for the first adventurer.

From what we had before, yes. But it's still better than FfH's version, in my opinion. ;)

It needs something for an early Adventurer, something that doesn't require bee-lining a certain tech path. Grigori don't have anything else worth mentioning, so they have to be strong early on. Otherwise they can't capitalize on an early advantage, and without an early advantage the Grigori don't have much of any advantage at all.

This is true. Like I said earlier, this is a preliminary version with values that seemed okay in my (very limited) playtesting. Counting on feedback to get the balance right.

An early boost is VERY easy to do. I could increase the value of the Palace, and then either up the cap slightly to compensate or up the amount it increases by, as the Palace would be worth more throughout the game.

A better method, IMO, and something I meant to add for the AI at least later on, is a modifier based on the number of Adventurers you currently have. Say, +3 a turn when you have none, decreasing by one for each additional adventurer? The problem is you then have to loop over all Grigori units each turn....

Maybe add another variable to the Player in the DLL (SpecialUnitCount? Could be used for others, after all) and when an Adventurer is spawned the count goes up... When killed/captured/lost in some way, it goes down. Then I just have to call the value of the variable, rather than looping over all units.

Actually, that could work pretty well... May do that for the next patch now.... :lol:

That sounds good. And, of course, you can always mix both; a small boost for the palace, and a more significant one based on number of adventurers.

Enhancement modifiers are nice, but forcing a bee-line to be on par seems like a bad path.

Yeah.

Ideally, the Grigori would get modifiers on far more buildings, and have the scale made larger (1000 rather than 100?). You then have more control over the amounts buildings get... Maybe even improvements as well, though that would HAVE to be done in the DLL.

Say, out of a scale of 1000, give palisades a value of 1 or 2? (tenth of a point, current setup)

Would represent bored soldiers on the palisade, wishing to go exploring... Or telling children stories, inspiring THEM to go exploring. Either works.

Basically, I want to expand it to be a more fundamental thing, rather than just using a few scattered buildings. Could have some events affect the counter as well...

If necessary, we could have a NEGATIVE modifier based on the number of adventurers you have. The more you have, the less glamorous it is for the generation of children growing up watching, after all.

Would the Grigori World Spell reset the threshold for the adventurer counter then and leave GP alone?

Either reset it, or do something similar... Opera had an idea for it, might track that down again. :lol:

Yeah.

Ideally, the Grigori would get modifiers on far more buildings, and have the scale made larger (1000 rather than 100?). You then have more control over the amounts buildings get... Maybe even improvements as well, though that would HAVE to be done in the DLL.Improvements? Well, our lore scholars have always insisted that the Grigori under Cassiel were semi-feudal farmers, though nothing quite supports that in-game.

A special type of farm for the Grigori, each giving a .X when worked? Of course, you'd have to scroll through every single farm and city in your empire...

I think the Grigori could use a distinct civic to reflect them, and would aid the counter.


Say, out of a scale of 1000, give palisades a value of 1 or 2? (tenth of a point, current setup)

Would represent bored soldiers on the palisade, wishing to go exploring... Or telling children stories, inspiring THEM to go exploring. Either works.Well, I don't bother with palisades in general, so useful buildings would be better IMO. Soldiers are just as bored in baracks, where they have little else to do but tell wild stories.



If necessary, we could have a NEGATIVE modifier based on the number of adventurers you have. The more you have, the less glamorous it is for the generation of children growing up watching, after all.I'd fundamentally disagree. The exploits of the previous generation are what motivate the next, and even FFH has entire national wonders (Heroic Epic, Tomb of the Champion) reflecting that.

A negative counter is tricky, but I think it would be best not to make any philosophical justification for it and just stick to mechanics.

Improvements? Well, our lore scholars have always insisted that the Grigori under Cassiel were semi-feudal farmers, though nothing quite supports that in-game.

Well, that or an Anarcho-Communist Sydicate, but that's abit to Monty Python.

I sometimes like to call the Grigori system Anarcho-Feudalism, a term usually used by leftists mocking Anarcho-Capitalism.


Kael has established that Cassiel idealizes the Yeoman farmer and does not trust the mercantile interests that tend to dominate elected governments. His is a feudal system where the "nobles" don't really have any special privileges. They are appointed for life, typically chosen from the most average citizens although farmers are more likely to be chosen than city dwellers, I would not be surprised if most were chosen by lot. They never pass on their positions to their children. They receive no salary, no special lodgings or possessions, and have no right to tax anyone. They often act like Justices of the Peace and Notary Publics, but I think their main function is organizing the local volunteer militias. Obviously, that means they spend a lot of their times running bake sales, raffles, and other fundraisers in order to get the funds to pay for the defense of the community. I assume they also lead barn raisings and collect money to help care for widows and orphans, at least for those whose husbands and fathers died serving with them in the militia. Overall they are more community organizers than governors. Although not officially stated, I'm pretty sure that they can be forced out of office by petition.



What would you think about making it so that Grigori farms have a chance of spawning limited duration militia units when invaded? I'm thinking probably warriors most of the time, nothing on par with professional armies of their enemies at their tech level but enough to slow down invasions a bit. Or, what if these militia units were of decent strength but had promotions making them AI controlled, to represent how badly organized their militia is.

Improvements? Well, our lore scholars have always insisted that the Grigori under Cassiel were semi-feudal farmers, though nothing quite supports that in-game.

A special type of farm for the Grigori, each giving a .X when worked? Of course, you'd have to scroll through every single farm and city in your empire...

What would you think about making it so that Grigori farms have a chance of spawning limited duration militia units when invaded? I'm thinking probably warriors most of the time, nothing on par with professional armies of their enemies at their tech level but enough to slow down invasions a bit. Or, what if these militia units were of decent strength but had promotions making them AI controlled, to represent how badly organized their militia is.


How about having Villages and Towns provide the bonus/militia, instead (possibly have them give different amounts/troop quality, too)? It would make sense, since they would have more of a population to draw from (in the case of the militia) and more people who could be inspired to become Adventurers (in the case of adding to the Adventurer counter), and it would mean that you can't just add a new improvement and expect instant results.

Villages and Towns would be a no; Too close to the Bannor. A Grigori-specific Farm upgrade could work though. ;)

I sometimes like to call the Grigori system Anarcho-Feudalism, a term usually used by leftists mocking Anarcho-Capitalism.


Kael has established that Cassiel idealizes the Yeoman farmer and does not trust the mercantile interests that tend to dominate elected governments. His is a feudal system where the "nobles" don't really have any special privileges. They are appointed for life, typically chosen from the most average citizens although farmers are more likely to be chosen than city dwellers, I would not be surprised if most were chosen by lot. They never pass on their positions to their children. They receive no salary, no special lodgings or possessions, and have no right to tax anyone. They often act like Justices of the Peace and Notary Publics, but I think their main function is organizing the local volunteer militias. Obviously, that means they spend a lot of their times running bake sales, raffles, and other fundraisers in order to get the funds to pay for the defense of the community. I assume they also lead barn raisings and collect money to help care for widows and orphans, at least for those whose husbands and fathers died serving with them in the militia. Overall they are more community organizers than governors. Although not officially stated, I'm pretty sure that they can be forced out of office by petition.

And then Auric invades, and they have to start a system something that works. :p



What would you think about making it so that Grigori farms have a chance of spawning limited duration militia units when invaded? I'm thinking probably warriors most of the time, nothing on par with professional armies of their enemies at their tech level but enough to slow down invasions a bit. Or, what if these militia units were of decent strength but had promotions making them AI controlled, to represent how badly organized their militia is.Something like a far-more likely chance of a Treant in an ancient forest?

It could be good, but ixnay on the AI. AI controlled units only serve as xp fodder, and you need player control to mass them for any effect.