Pie's Ancient Europe

In a lot of ways, the vassal system will work better for the Delian league than Civ 5's city states. Civ 5 city state alliances were based on how much they "liked" you, whereas vassalage permits forced allies that don't necessary like you, have the possibility of "revolting", etc.
Very true, and the PAE enhancements of the vassal system go surprisingly well with what Thucydides reports.

The 18 civ limit would be a bit tight, since most cities will be their own civ, but 30 with that dll should be do-able.
We Mac users would be happier however, if you did it in the 18-civs confinements, because the 40-civs-DLL is, sadly, not Mac compatible. Last year I created a wine version of Civ BTS and tested it successfully, but I deleted it later, since it was pushing my computer too far to the limits, and I'm using the same machine for work, as well. It might appear silly to you, that I argue as a single person… …but if you take a look, how few people have come here recently compared to, say, 2010, one has to admit, the audience for Civ IV mods is in the decline, and the audience for a beautiful, no nonsense historical scenario even more so. In other words, I would really be p*****, if I missed your Peloponnesian scenario because of that damn 18-civs limitation;).

BTW, Keinpferd, if you're really interested in the Peloponnesian War, Donald Kagan has an incredible 4 volume work on it--he's a military historian and a good writer, I really enjoyed it. Also, there's an edition of Thucydides called The Landmark Thucydides that is the original work but with detailed maps of the action every few pages, notes in the margins, etc.
Donald Kagan is certainly the most referential figure. But four volumes, are you kidding:p? Though it would be interesting to see, in what ways his work differs from other less referential guys – for one very obvious reason: Thukydides is on most of the events during the course of the Peloponnesian war the only historical witness and reporter we have, and the credibilty of his has been discussed, positively, for centuries. I see little space for disagreements, bold thesises in the "radical" fashion, that historians like so much. And as a confirmation of that, I found the only secondary literature I read on the topic, Bleckmann, Der Peloponnesische Krieg, in all agreeable and almost boringly non-controversial. Bleckmann is a one volume compendium style little book, something for the ipad…

I looked at John's map. It's not bad, but I'd make a lot of changes if I used it as a starting point. I'm really more interested in geo-political and strategic than geographic accuracy
:thumbsup:

And it sounds like I'll need to do some work on the vassal system to make revolting a little easier for them[…]
Military failures already do go into the calculation of vassal revolt. Pie can tell you all details about it.

Our event man is Thorgal, who rather seldomly shows up on these forums, but if you need his support or advice, we can bring him here easily. And he speeks English very well, so no communication barriers here:).

Excited about your project!
 
Pie,

I've been looking around in the Python for the mod a bit to get an idea about how your handling Vassals, and I found something that didn't look right. In CvEventManager.py, OnCityAcquired(), line 9551, it's got:
Code:
iLoserPower = pLoserTeam.getPower(True) # False: ohne Vasallen
iLoserPowerWithVassals = pLoserTeam.getPower(True) # mit Vasallen
iWinnerPower = pWinnerTeam.getPower(True) # mit Vasallen
Shouldn't that first line be False, not True? Otherwise, later "if iVassalPower > iLoserPower:" should never be true, since iLoserPower is including iVassalPower, and "if iVassalPower + iWinnerPower > iLoserPower and 1 == self.myRandom(3, None):" is comparing against iLowerPower with the Vassal included?

Also, just a suggestion, it might be nice to include the Vassal's relative attitudes to it old hegemon and potential new one in the calculation--i.e., less likely to abandon a hegemon it likes for one it hates and vice versa.
 
Time for?
oh, just for seperating PAE features and explain them for mod import. but, you're certainly as busy as

me. I would do that, when PAE is finished, but I'm afraid, then it's too late ;)


P.S.
Gigapack has 5000+ lines :D
oh, as isenchine said, I have lots of blank, explanations and outcommented lines ;)

You should probably take some time to review your codes for old features.
As you code more and more stuff, you learn new ways of doing things, or catch bugs in unexpected

situtations never thought of before.
Then when you look back at stuff you coded one year ago, some of them can be coded in new ways which

are more efficient or avoid the unexpected situtations.
Yes, that's true. I do. But I have my proof readers ;) also in the German forum, who look for

optimizing (stolenrays, Boggy, Flunky). I think, PAE is in good hands and up to date in most things.


I like the large map, but I think it lacks some expanse of Shara, Nile valley,

Arabia, Persia, and Indus valley, so I started making an extended map starting from it. This is close

to the area of the "mini" map. I attached a first rough view, I am interested in advice :)

I also have no idea how the starting positions work for this mod, is there a documentation somewhere,

or someone willing to add them when the map is done ?

Of course, new well done maps are always welcome!
For starting points: don't worry, I'll do that for you.
For me it's simple to implement. For you, I don't know, I explain:
1. first give your scenario on plot x,y=0 a Name (ScriptData=YourMap), which is not used by another map.
2. go into PAE/Assets/XML/Misc/ and copy and unname a StartingScript.XML and place the CIVs to the correct x,y coordinates.
3. go into PAE/Assets/Python/Eventmanager.py and search for StartingPoints. Add your Scenario and file into the correct section.

But, you don't need to do that. The python stuff, I will do for you. Just create the StartingPoints.xml for your scenario.

Pie,
Of course you can quote me.
Thanks! I really hope, I can get some new players with your great praise!
:thanx:

You did all this in Python? I just assumed you had DLL changes. I haven't looked at Civ 4 yet, but

Civ 5 was pretty lacking in terms of the events it exposed to Python. That's great--it was only

because I thought we'd have conflicting DLL changes that I didn't think a modmod would work.
Yes. So make a modmod and use your own dll for whatever you want!
If you handle everything with a dll then you even don't need a modmod. people can put your dll to play the scenario with your rules. Whatever you want.

But it is to say, that I will add more features into PAE. One new feature, I don't want to reveal at the moment, has also happened in old Greece.... ;)
(it will only be a python thing, so this can easily be copied into a modmod every time)

When you say

by "power", do you mean just population, or does it take military power into account?
Miltary power. It's just the calculation of getPower().

Pie,

I've been looking around in the Python for the mod a bit to get an idea about how your handling

Vassals, and I found something that didn't look right. In CvEventManager.py, OnCityAcquired(), line

9551, it's got:
Code:
iLoserPower = pLoserTeam.getPower(True) # False: ohne Vasallen
iLoserPowerWithVassals = pLoserTeam.getPower(True) # mit Vasallen
iWinnerPower = pWinnerTeam.getPower(True) # mit Vasallen
Shouldn't that first line be False, not True? Otherwise, later "if iVassalPower > iLoserPower:"

should never be true, since iLoserPower is including iVassalPower, and "if iVassalPower + iWinnerPower

> iLoserPower and 1 == self.myRandom(3, None):" is comparing against iLowerPower with the Vassal

included?
oh, thanks. I don't know why I set it to true, perhaps I had a reason, but I don't remember now. So, I change it to False. ;)

Also, just a suggestion, it might be nice to include the Vassal's relative attitudes to it old hegemon

and potential new one in the calculation--i.e., less likely to abandon a hegemon it likes for one it

hates and vice versa.
Good idea. Tell me the calculation factors. It has to be a primary or secondary part the higher the factor. e.g.: is the difference between two powers very high, shall the bad attitude be stronger in calculation, so that it comes to a war or not?
hm, but maybe it's not good, if it concerns a small state which has no chance of a resistance, but declares war only because of a bad attitude.
 
BEST news for PAE fans:

I FOUND THE OOS reasons!!!! Stay tuned for a very important new patch...

It was:
-) Units that have iCombat needs to get a COMBAT TYPE (eg UNITCOMBAT_MELEE) and not NONE. That causes an OOS error!
I had this with the workboat, Trojan horse and deer.
-) Ships that can carry units can't be a SPECIAL_UNIT type because of its CarrierUnitAI tags. This causes an OOS error too.
I had this from begin on with the merchant ship.

For all modders out there. Keep those two facts in mind!
Or quote me and post it in the appropriate threads.
Now, it looks like it works well! Till you find another OOS.... but I really hope, you don't ;)
 
Congratulations for the OOS error!

But what's special about your deer, is it a Trojan Deer? :)

All animals in BtS have an iCombat but NONE as Combat.

Edit: oh, I see, it's a very special deer: it can see INVISIBLE_SUBMARINE! :D
 
oh, just for seperating PAE features and explain them for mod import. but, you're certainly as busy as

me. I would do that, when PAE is finished, but I'm afraid, then it's too late ;)

If the mod is working fine, there is no real need to separate the various features into smaller files. Separating them is just to make it easier for modders interested to help in your mod or attempting to make mod mods to understand stuff easier.
 
Yes, I use the INVISIBLE_SUBMARINE tag for invisible units in general. eg Pirates. Scouts had it. But yes, it's unimportant for deers. ;)

Platy: that's true ;)
 
oh, thanks. I don't know why I set it to true, perhaps I had a reason, but I don't remember now. So, I change it to False. ;)


Good idea. Tell me the calculation factors. It has to be a primary or secondary part the higher the factor. e.g.: is the difference between two powers very high, shall the bad attitude be stronger in calculation, so that it comes to a war or not?
hm, but maybe it's not good, if it concerns a small state which has no chance of a resistance, but declares war only because of a bad attitude.

Well, you might want to wait until you have a chance to look at it closer before just setting it to false, because iWinnerPower does include vassals, and if iLoser has more than 1 vassal, the other vassals should probably get counted for him.

Maybe best would be to delete "iLoserPower = pLoserTeam.getPower(True) # False: ohne Vasallen" @ 9551, and instead @ 9569, right below iVassalPower = pTeam.getPower(True), add:

iLoserPower = iLoserPowerWithVassals - iVassalPower

That was the comparison is being done for each vassal against the LosersPower including add its vassals except the one considering changing hegemons.

You'd probably also want to look at VassalHItoHI() to make sure it's consistent.

Attitude could be brought in separate from the power comparison by having it instead modify the 1 in 3 chance for the vassal to consider changing at all:

(9576) if iVassalPower + iWinnerPower > iLoserPower and 1 == self.myRandom(3, None):

maybe becomes:

if iVassalPower + iWinnerPower > iLoserPower and 10 > ( self.myRandom(30, None) + pPlayer.AI_getAttitude(iPreviousOwner) - pPlayer.AI_getAttitude(iNewOwner) ):

or some such. Probably not a high priority, though, just an idea for when (if) you get some time to think it through.
 
Yes. So make a modmod and use your own dll for whatever you want!
If you handle everything with a dll then you even don't need a modmod. people can put your dll to play the scenario with your rules. Whatever you want.

I'll probably just go with a modmod in python since it looks like everything I'd need is exposed there, unlike Civ 5's pretty limited LUA.

On the modularizing discussion--I agree just splitting things into more files for the sake of splitting things into more files probably isn't worth it.

However, for modmod'ing, a few things would allow modmod'ers to override your classes and add/change functionality without having to change your files at all.

For instance, create a separate file PieEventManager.py containing a class PieEventManager and move all your code currently under the CvEventManager class there. Then in CvEventManager.py, import PieEventManager.py and just have:

class CvEventManager(PieEventManager):

Then for my mod, say, rather than merging my changes with yours in CvEventManager.py, and re-merging every time you made changes I want to include, I can just create a PWarEventManager.py with class PWarEventManager(PieEventManager): and override methods I need to override, and change class CvEventManager(PWardEventManager):

Of course, for that to work well, you'd need to also break functions out a bit more to allow overriding of specific functionality. For instance, rather than put the vassal changing code directly in onCityAquired(), make a function like vassalCityAcquired() and call it from within onCityAcquired. Then a modmod'er can just override vassalCityAcquired() to change it's functionality while leaving everything else in onCityAcquired() functioning as normal.
 
So I tested that a bit. I copied the PAE5 mod, copied the original CvEventManager.py from the BTS directory and named it BaseCvEventManager.py and it's class to BaseCvEventManager, then I copied PAE's CvEventManager.py to PieEventManager.py and changed it's class to PieEventManager(BaseCVEventManager), then finally I made a CvEventManager.py with nothing but import statements and an empty CvEventManager(PieEventManager) class. Then I went through PieEventManager and removed all the methods that were identical to BaseCvEventManager, so they would fall through to the base class, and replaced all the code within other methods that reproduced the base code with calls to BaseCvEventManager.function_name(). The result was a PieEventManager class that contained no duplication of the original BaseCvEventManager code, and which could easily be overridden by a 3rd superclass--and it seemed to work fine.

So, am I missing something here? Inheritance and overriding are basic OO principles specifically designed for the kinds of things mods do--selectively overriding the functionality of existing code. Is there some reason that's not the default way of doing mods? I've noticed some original Civ 4 python code isn't encapsulated in classes at all, making bulk file replacement the only option--why?

I'm not a python coder, but I've used OO principles in many languages, and python seems to support them sufficiently to use here--could a python expert explain to me why Civ wouldn't have used this by default? Really, except for maybe a class factory py file, which could well have been an extensible XML file, it would have negated the need to replace files altogether, and made stacking mods on top of mods in particular much easier, and even first level modding clearer since only the changed methods would be overridden in the mod files, no?
 
Because every modder has his own style of doing things.
Some mods are using the BUG or WOC style of modular python, which is quite similar to what you are doing, where there are multiple files for different features where each file only contains a few sections to replace the original ones in event manager.

The downside is you will never get a full overview of what's going on if you just open the main event manager file. For instance, my gigapack is done in same way as PAE, where codes for all 200+ python wonders are coded directly in the main file. This way, I can tell straight away what is the outcome when a unit is built for instance, since all the codes are done onUnitBuilt.

If I do it the WOC way, I end up with 200+ files and I will never know what is the final outcome unless I open all the 200+ files to check if they modified that section.

Also, it is pretty clearcut that order of codes matter in python.
When everything is still in one file, it is clear which line is executed first.
Try telling me which is first when separated in 200 files.

Then for simple mods, it is seldom that there will be conflicts among codes.
But when you have 200+ python wonders in same mod, then it is highly possible that some will conflict. Thus, it is easy to spot which ones will cause problems for others and necessary steps are needed to merge them.

Overall, separating python into smaller files have advantages for new modders joining the team to analyse what is going on or spot bugs, but it brings more problems than benefits.
 
FYI WoC does not do modular python only XML BUG on the other hand does and I believe the order of python execution is the order defined in the init.xml file in the config folder. However as you say it does get confusing when you get a lot of python modules.
 
It is easy when each module only contains one modified section.

What if I have 2 modules, both modifying onUnitBuilt and onUnitKilled.
I want the order such that for OnUnitBuilt, module A comes first, but for onUnitKilled, module B comes first.

Not possible I believe.
Thus, modular style is only for simple python merging. When it gets complicated, you will kill yourself with this method.
 
Well, you might want to wait until you have a chance to look at it closer before just setting it to false, because iWinnerPower does include vassals, and if iLoser has more than 1 vassal, the other vassals should probably get counted for him.

Maybe best would be to delete "iLoserPower = pLoserTeam.getPower(True) # False: ohne Vasallen" @ 9551, and instead @ 9569, right below iVassalPower = pTeam.getPower(True), add:

iLoserPower = iLoserPowerWithVassals - iVassalPower

That was the comparison is being done for each vassal against the LosersPower including add its vassals except the one considering changing hegemons.

You'd probably also want to look at VassalHItoHI() to make sure it's consistent.

Attitude could be brought in separate from the power comparison by having it instead modify the 1 in 3 chance for the vassal to consider changing at all:

(9576) if iVassalPower + iWinnerPower > iLoserPower and 1 == self.myRandom(3, None):

maybe becomes:

if iVassalPower + iWinnerPower > iLoserPower and 10 > ( self.myRandom(30, None) + pPlayer.AI_getAttitude(iPreviousOwner) - pPlayer.AI_getAttitude(iNewOwner) ):

or some such. Probably not a high priority, though, just an idea for when (if) you get some time to think it through.

That's quite ok. I do both changes. ;)

iLoserPower is used a bit later and I replaced it now with iLoserPowerWithVassals

So I tested that a bit. I copied the PAE5 mod, copied the original CvEventManager.py from the BTS directory and named it BaseCvEventManager.py and it's class to BaseCvEventManager, then I copied PAE's CvEventManager.py to PieEventManager.py and changed it's class to PieEventManager(BaseCVEventManager), then finally I made a CvEventManager.py with nothing but import statements and an empty CvEventManager(PieEventManager) class. Then I went through PieEventManager and removed all the methods that were identical to BaseCvEventManager, so they would fall through to the base class, and replaced all the code within other methods that reproduced the base code with calls to BaseCvEventManager.function_name(). The result was a PieEventManager class that contained no duplication of the original BaseCvEventManager code, and which could easily be overridden by a 3rd superclass--and it seemed to work fine.

So, am I missing something here? Inheritance and overriding are basic OO principles specifically designed for the kinds of things mods do--selectively overriding the functionality of existing code. Is there some reason that's not the default way of doing mods? I've noticed some original Civ 4 python code isn't encapsulated in classes at all, making bulk file replacement the only option--why?

I'm not a python coder, but I've used OO principles in many languages, and python seems to support them sufficiently to use here--could a python expert explain to me why Civ wouldn't have used this by default? Really, except for maybe a class factory py file, which could well have been an extensible XML file, it would have negated the need to replace files altogether, and made stacking mods on top of mods in particular much easier, and even first level modding clearer since only the changed methods would be overridden in the mod files, no?

hm... wouldn't it be the same to let the original EventManager as it is and only import a PAE class (deleting all identical functions of the original file)?

But as Platy said: those onNetMessage things are located in EntryPoints/CvScreensInterface.
So, some features needs two files.

but even seperating into a stand alone PAE class, it's the same untamed code. nothing would change. So, that's why I keep it as it is.

Only a "HOW TO" thread would be useful, if someone wants to add a feature from PAE.
 
Moderator Action: Ancient Europe Mod forum created per request. Thread moved to new forum.
 
Wohooo! PAE has it's own subforum now at the civfanatics!

So, now's the time to seperate things and I will create some threads for that....
 
First I really have to congratulate you for this amazing mod! The final version seems to be even more sophisticated and polished than Beta 2.

My question concerns the game speed and tech tree balance. I am currently playing Gaul/Europe large/Emperor/Marathon. Somehow, just like when I played the last version, all civilizations seem to massively lag behind the suggested (historical) technical evolution. Around 1200 BC I'm still researching technologies around the 2000 BC mark. At the same time I am far ahead of any other civilization as far as points and also seem to be technologically advanced.

What is the cause for this? What am I doing wrong?

Thanks so much for your great work!
@pie Grüße aus Wien ;)

Edit: After playing another couple of rounds and researching lettered writing (technology trading) it is becoming obvious that all my opponents utterly suck technologywise. I can offer 6 techs to rome (2nd place), 10 techs to the vandals (3rd place) ...
In the year 1015 BC I am 4 techs away from iron working myself and still miss a large amount of bronze age techs.
 
hi Uli, greets back to Vienna ;)

oh, I didn't balanced the marathon speed. everything is balanced for normal speed and maybe epic speed. but for marathon it seems, I don't have set the correct properties into the SpeedInfos yet.

so thanks for your suggestion, I will decrease the research penalty for marathon speed a bit.

And try normal or epic. It's really epic/marathon enough ;)
 
First of all congratulations to the new subforum! I installed your mod just today and haven't played much, but from what I can see it's really awesome!

Anyway there's two things I thought I should mention:

In one of the PAE concepts articles in the Civilopedia, the one that lists all the mercenaries to be exact, you have 'Indischer Söldner' where 'Indian mercenary' should be.

Another thing that bugs me is that on the XL Europe map the Roman Settler is one off the coast and settling in place would would cut off a Fish and a Clam. Is this intended? Granted, I have barely played past 3000BC and not even researched the tech for settlers, so it could be that the minimum allowed tile distance between cities has been reduced like in RFC or that cities can work their third ring too, but it still bothers me.
 
Ok, thanks for the reply. I usually always go for the longest game available, but I guess I'll try epic in that case.
 
Back
Top Bottom