I want to help this mod

[MattCA]

yesterday I had an idea that might be ok - but only if it gets used so idk just a thought. it would be easy to make a bunch of globals for the python stuff. just replace a value in the code with the option (words) then throw together a file just like the ScreenEnums one witch has nothing but whatever = whatever. leave the file python and add to imports where needed.

Spoiler :

original code:
nPartisan = (citysize / 7) + 1
new global:
CITY_SIZE_PER_PARTISAN = 7
new code:
nPartisan = (citysize / CITY_SIZE_PER_PARTISAN) + 1

maybe a bad example. I just wanted to show its simple

 

[Toffer90]

yesterday I had an idea that might be ok - but only if it gets used so idk just a thought. it would be easy to make a bunch of globals for the python stuff. just replace a value in the code with the option (words) then throw together a file just like the ScreenEnums one witch has nothing but whatever = whatever. leave the file python and add to imports where needed.

Spoiler :

original code:
nPartisan = (citysize / 7) + 1
new global:
CITY_SIZE_PER_PARTISAN = 7
new code:
nPartisan = (citysize / CITY_SIZE_PER_PARTISAN) + 1

maybe a bad example. I just wanted to show its simple

Not sure what you are suggesting... Would help if you were a bit more verbose.

Are you suggesting that we make many new global defines for the GlobalDefines.xml file?
So that python code instead of using an internal value, have to call the dll and asks it what the value is?
The value would then always be cached in the dll code, and it would make sense to cache it in the python code too so that one can skip doing the call to the dll more than once during a game.

It would either way eat up a little RAM (depending on how many new global defines we make) or steal away a dozen of nanoseconds every time the python code in question is processed.

Edit: I think you are suggesting that we make a GlobalDefines.py file that holds hundreds of constants that can be imported by all the other python files so that those constants are available to all python code and centralized in a manner that makes it easier for folk to tweak those values... It would be better to just keep those constants within the python file that use them, so that other python files don't have to import a bunch of variable names that they never use but have to search through every time a variable is used in that python code. One shouldn't import more than what is needed.
So in the partisan.py file you would then add a "g_CitySizePerPartisan = 7" at the top of the file. It would then be easy enough for folks to understand what the number mean and to tweak it if they wanted.

 

[MattCA]

I wanna keep my posts short so they may end up a bit vague.
the second part is exactly what I mean. There could be hundreds or there could be a dozen. keeping them in their files kinda defeats the purpose.
ram used + time used to make modding easier... hmm...
moving on
I hope your not done with Bug in ppio. Bug seems to be 3/4 unused or unnecessary like the setdefauts in BugGameUtils. whats the point of those?
Im going to send what's left of those calls I was talking about before to the file that handles them and cut out the 2 pointless files that just bounce stuff to the next file
just gotta change 1 name in the CvDefines.h (and ill probably do a couple searches while im there - I've never come across a couple)

CvDefines.h

Spoiler :

// python module names
#define PYDebugToolModule "CvDebugInterface"
#define PYScreensModule "CvScreensInterface"
#define PYCivModule "CvAppInterface"
#define PYWorldBuilderModule "CvWBInterface"
#define PYPopupModule "CvPopupInterface"
#define PYDiplomacyModule "CvDiplomacyInterface"
#define PYUnitControlModule "CvUnitControlInterface"
#define PYTextMgrModule "CvTextMgrInterface"
#define PYPerfTestModule "CvPerfTest"
#define PYDebugScriptsModule "DebugScripts"
#define PYPitBossModule "PbMain"
#define PYTranslatorModule "CvTranslator"
#define PYGameModule "CvGameInterface"
#define PYEventModule "CvEventInterface"
#define PYRandomEventModule "CvRandomEventInterface"

BugGameUtils.py

Spoiler :

self._setDefault("isVictory", True)
self._setDefault("isPlayerResearch", True)
self._setDefault("getExtraCost", 0)

CvGameUtils.py

Spoiler :

def isVictory(self, argsList):
return True

def isPlayerResearch(self, argsList):
return True

def getExtraCost(self, argsList):
return 0

 

[Toffer90]

I hope your not done with Bug in ppio. Bug seems to be 3/4 unused or unnecessary like the setdefauts in BugGameUtils. whats the point of those?

I've barely started working on the BUG python code in PPIO, there's a lot more to do there, it's a spaghetti code that has to be untangled carefully as not to break actual useful functionality within it.

BugGameUtils.py is meant to modularize the code that in vanilla is only located in CvGameUtils.py, so that many different python files can contain a e.g. isVictoryTest() function.
The BugGameUtils.py can register all the different files that have that function and call them one after the other, as long as one of them returns "False" it will call the next until one of them returns "True" or every function has been called. This can be useful if we want to modularize entire game options and contain them in their own python files that are unused if the option is turned off. When the option is turned off the python file that contain the code specific for that option would uninitialize stuff and unregister it's gameutils specific functions from the BugGameUtils register.

The same functionality can be seen in the BugEventManager.py which allows for event calls to python to be distributed across many different python files. In vanilla all those event calls would only go to CvEventManager.py. Examples are events like "unitKilled" meaning each time a unit is killed the dll will notify python through BugEventManager and it will again bump the event over to all the different python files that is designed to do something every time a unit is killed within a certain condition check. Sometime it makes sense to centralize this to one function within one python file but other times it makes more sense to isolate a specific game mechanic/functionality to a dedicated python file that has other code that deals with stuff that is related in some way.

In PPIO I have reduced the usage of this functionality from BugEventManager, and the functionality is as you noted barely used with the BugGameUtils.
The question I ask myself is: can this functionality be usefull enough to keep at some point and is that true for both of these cases, should it be used more or less; I have still not concluded with a definitive answer myself; and I don't want to remove something prematurely only to figure out later that we really do need it for some special project down the road.
So I keep optimizing python code until I feel sure about the answer, which may very well depend on the optimizing result.

 

[Dancing Hoskuld]

I have been looking at Platyping's UI for my mod, just to check it out. It cleans up a lot of the basic UI code but it doesn't have the stuff that BUG, with BULL etc., has. In particular it cleans up the links between Python the dll and exe to do with user input. Platyping also figured out how you could change the Python code while you are running a game and have it active immediately, ie without it crashing the game or requiring you to exit and start the game again. These, and others, may be useful to examine and see if they can be incorporated into C2C's code (or PPIO).

Having the ability to have modular Python is very useful if you have a number of people trying to add (Python) functionality at the same time as happened early on in C2C's development. It allows for each to create and update independent of others as well as a staged release to other modders and eventually players. Naturally once it is core it should be merged into a more efficient form. This latter there was never time for.

 

[Dancing Hoskuld]

BtW you do know that there is Python code in the XML, don't you? It is mostly to do with missions which would normally be done in the Event code which is another bottleneck as far as development goes since it is one file that many people needed to update for different things at the same time. It was bad enough when only events were being worked on.

 

[MattCA]

I've barely started working on the BUG python code in PPIO

good. im curious to see what you do with revolutions too after ur last post about large options.
although I wouldn't worry about splitting calls or multiple files when only 3 or 4 out of like 50 are being used. but u might be talking more about the events. I was thinking about switching all the event calls that go to only 1 file into the GameUtils style and go straight to their file. I think its safe to assume its faster. I know u guys like flexible modding over speed tho. if u ever come up with something with BugUtils it might be good for the other event calls. any events can easily be switched to the other style. easy to switch the names of python modules in the c++ or make globals from them too.

you do know that there is Python code in the XML, don't you?

outcome missions im aware of. if thats not it im not aware

Platyping also figured out how you could change the Python code while you are running a game

recalc has never worked for me but i always assumed you could use the addEventHandler or w/e bit of code it is anytime. if you cant load stuff mid game that might be worth some time lookin into I think. a good future direction might be to have all kinds of little python stuff being loaded and unloaded all game to help make the eras unique and you can cram more stuff in the mod if its not running all game. like bandits and pirates - around for an era or 2 then gone

 

[MattCA]

theres more but itll hit true first every time

Spoiler PlayerAI.cpp :

bool CvPlayerAI::AI_captureUnit(UnitTypes eUnit, CvPlot* pPlot) const
{
CvCity* pNearestCity;

return true;

if (pPlot->getTeam() == getTeam())
{
return true;
}

this is the 1 place its used. if any 1 of the 3 comes back true the line passes

Spoiler Unit.cpp :

if (GET_PLAYER(eCapturingPlayer).isHuman() || GET_PLAYER(eCapturingPlayer).AI_captureUnit(eCaptureUnitType, pPlot) || 0 == GC.getDefineINT("AI_CAN_DISBAND_UNITS"))

 

[Dancing Hoskuld]

... to help make the eras unique and you can cram more stuff in the mod if its not running all game. like bandits and pirates - around for an era or 2 then gone

I have suggested this many times but it always gets rejected as people want everything in in all eras. eg crime and disease, why should they, the properties, even exist until people figure out they can do something about them? At some point Disease should entirely disappear except as biological warfare which is a different thing.

The first Era is about survival, anything beyond that should not be showing up, including large warfare. The next Eras are about stability this is where crime, espionage* and large warfare start.

Another example, from "Animal Riding" to "Gunpowder" all forts should exhibit a Zone of Control (realistically only if they have a mounted unit in them). During this time you can't afford to bypass forts. After gunpowder they start to become irrelevant. They can of course be countered by siege forts but that does not break the ZoC just adds a new one they can't bypass

 

[raxo2222]

I have suggested this many times but it always gets rejected as people want everything in in all eras. eg crime and disease, why should they, the properties, even exist until people figure out they can do something about them? At some point Disease should entirely disappear except as biological warfare which is a different thing.

Disease pseudobuildings (and pests) are obsoleted in Nanotech era - Smart Medicine and Environmental Economics.
Two pests don't obsolete, but their replacements never obsolete too.

 

[JosEPh_II]

but it always gets rejected as people want everything in in all eras. eg crime and disease,

Who is this "people" you speak of? Players? Modders? Who?

 

[Dancing Hoskuld]

If it was more than 5 I gave up. Modders and players both. I did manage to get Hydro to be a bit more realistic with many of his diseases and pests but it was an uphill battle.

 

[MattCA]

Disease pseudobuildings (and pests) are obsoleted in Nanotech era - Smart Medicine and Environmental Economics.

that's what I thought. someone just needs to figure out how to stop the c++ code at those techs. and what about the popup for choosing techs? it supposed to popup at gamestart right?

 

[MattCA]

there's m_PropertySolver.doTurn(); on cvGames game turn. the properties would be frozen. do u guys think the display part needs to be taken down?

 

[Thunderbrd]

that's what I thought. someone just needs to figure out how to stop the c++ code at those techs. and what about the popup for choosing techs? it supposed to popup at gamestart right?

That's only going to be true for the core. Outbreaks and Afflictions will use disease and crime all the way through, even if diseases start being more like computer viruses than just biological ones.

I have suggested this many times but it always gets rejected as people want everything in in all eras. eg crime and disease, why should they, the properties, even exist until people figure out they can do something about them? At some point Disease should entirely disappear except as biological warfare which is a different thing.

The first Era is about survival, anything beyond that should not be showing up, including large warfare. The next Eras are about stability this is where crime, espionage* and large warfare start.

Another example, from "Animal Riding" to "Gunpowder" all forts should exhibit a Zone of Control (realistically only if they have a mounted unit in them). During this time you can't afford to bypass forts. After gunpowder they start to become irrelevant. They can of course be countered by siege forts but that does not break the ZoC just adds a new one they can't bypass

I'll admit to completely disagreeing with almost all of these points.

Crime is not crime because it's defined as a crime, it's a crime because it's damaging behavior to the society. Whether you call theft bad or not doesn't mean it doesn't cause problems to do it,likewise with any other criminal behavior. The reason to label a crime is to give us a means to fight those negative effects. Thus, crime has always been with us. And in some kind of format, it always will be. Pretty much the same can be said about disease. Without early disease considerations, why bother with herbs? War? People were paranoid and xenophobic and displaying tribal hostilities to one another since long before human modernity - that's how we had eliminated so many rival hominid species even before the beginning of this game setting.

Obviously, all three play roles in different ways and to different degrees through various eras, with different problems coming to the forefront, but all have and always will, be an intrinsic part of the struggle of mankind - and without struggle there is no story and with no story there is no game. Just motions without purpose.

Afforess's explanation of Zones of Control were that they exist because you'd be shot if you crossed vulnerable open spaces in target sights from the fort position, which would suggest that ZoC's should only show up once distance weapons make it possible.

 

[Toffer90]

Afforess's explanation of Zones of Control were that they exist because you'd be shot if you crossed vulnerable open spaces in target sights from the fort position, which would suggest that ZoC's should only show up once distance weapons make it possible.

A fort doesn't occupy a whole plot, perhaps closer to 0.01% of one plot on the biggest map size. So to be within shooting distance of a fort one would have to be on the same plot as the fort.
So zone of control as it is now should only be viable for the plot the fort is built upon until modern artillery and missiles becomes a thing. This is why I don't see why C2C should have a "zone of control" feature at all.
As long as it's an option I'm ok with it though. ^^

 

[Thunderbrd]

A fort doesn't occupy a whole plot, perhaps closer to 0.01% of one plot on the biggest map size. So to be within shooting distance of a fort one would have to be on the same plot as the fort.
So zone of control as it is now should only be viable for the plot the fort is built upon until modern artillery and missiles becomes a thing. This is why I don't see why C2C should have a "zone of control" feature at all.
As long as it's an option I'm ok with it though. ^^

I also balk at it being a factor because if you want to take on the fire they can throw at you, you should be able to, therefore, simply not being allowed to move seems unfit in comparison to provoking a free distance attack instead.

 

[Dancing Hoskuld]

"Zones of Control" are not "Fields of Fire". I think they have been confused. Gunpowder greatly increases the "Field of Fire" but drastically reduces "Zones of Control".

Example: during the first (English) civil war, The Anarchy as it is called, there was a lot less fighting that was thought. Most of the maneuvers were about fort location and how they controlled the landscape. It was more like chess, with one side building a fort to counter the other sides fort. Either that or negotiations to get the fort to change hands. There were still a large number of battles but only about 10-20% of what we thought. (Dang! I lent that English archaeology mag to a friend who has just headed North for the winter. Europe this year.)

Without paved roads, or better, it is very hard to move people from one place to another giving the locals ample time for ambush and guerilla attacks from a fortified position. Most campaigns had to be over in less that six months so that the soldiers could get the planting done in spring and harvest in autumn. In northern climes that just lest summer and winter as the months that land was solid enough for an army to travel over.

Crime is not crime because it's defined as a crime, it's a crime because it's damaging behavior to the society.

This makes no sense. A crime is only a crime when it is defined as a crime otherwise there can be no enlightenment, no progress or moving forward on morals. In fact by your definition society can't progress at all because progress is change and change is damage to the existing society. Though it does explain why thinking is a crime.

 

[tmv]

A crime is only a crime when it is defined as a crime otherwise there can be no enlightenment, no progress or moving forward on morals. In fact by your definition society can't progress at all because progress is change and change is damage to the existing society. Though it does explain why thinking is a crime.

Slippery slope? What about the idea that lawmaking is more about recognizing rather than creating law (which was a very popular idea in e.g. Ancient Greece, in fact creating laws was considered despotic). I would think that kind of thinking is even more about emphasizing the aspect of progress, since it doesn't just call any movement a progress, and can even (at least in retrospect) call some changes a degeneration instead.

 

[Dancing Hoskuld]

While in the shower had a wild idea on Zoc/FoF.

1. Only active during war.
2. Only active against enemies.
3. Only fortifications including cities not armies (unless fortified?)

Definition of terms

1. A plot is in the zone of control if it is next to a fortification or city.
   
2. Land and Sea plots behave differently.
   
3. Uncontested ZoC is a plot only has friendly (neutral or allied) forts next to it.
4. Contested ZoC has unfriendly forts next to it.
5. Forts can have enemy (siege) forts next to them making those forts in ZoC
6. The neutral player can inflict damage on anyone via this without declaring war. (Naturally they can give aid to anyone also and do diplomatic stuff on behalf of anyone also.)

Wild suggestions

1. Each turn a unit is in enemy uncontested ZoC it takes 10% damage per enemy fort modified for the units in the fort(s) next to the plot
   • melee or pre-gunpowder ranged then +1% for each 5 units in the fort(s)
   • mounted or gunpowder then +5% ditto
   • siege and other units no effect
2. In contested ZoC forts on your side can provide aid.
3. Units in Forts bounding a contested ZoC will suffer a 1% damage per turn for the duration of the war. (Easily overcome with a healer or taking the other fort).
4. Units in Forts will take a 1% damage from passing armies only if the armies are much larger.

Slippery slope?

Probably intentionally taking the extreme opposite to make a point. But by TBs definition there can be no progress. I just dislike having my people having problems due to internet crime before I have copper working.

Lawmaking is another factor entirely. When some Prophet says "you should treat others as you wish others to treat you" it opens up a great deal of activities that may have been considered OK to be being thought of as wrong and later as a crime. It does not require a law for a crime to be defined.