First release

[SimCutie]

Thanks for the tips guys, thats a rather usefull thing I will have to start using it.

The Release post is updated with the Spoilers, what do you think of it now?

I will see if I can get thouse Demos seperated (should be able to just move thouse Python files out, thats the whole point of SimCuties Eventmanager after all)

Good idea, but we dont have to put demo files in separate ZIP. We cound put the demo in same ZIP but in different folder like Document folder with direction on how to install the demo to Assets folder.

I did notice an odd behavior with SimCuties changes, at the corner of the screen the Pedia and MainMenu links disapear when the two < > city cycling buttons are pressedand then re-apear after selecting a unit or unit. Its anoying but not debilitating.

It is normal behavior of the game. when you press < >, then a city is cycled and selected. If you select any city (via clicking on the city), then Pedia and MainMenu should disappear.

Also changes made in the options panel dont seem to take effect untill I end the turn or do something else to cause a screen update, could the change effect be linked to the closing of the options menu that would ensure things update imediatly.

This option value go into effect imemdatly when you close the option screen. Main screen need redarw to see the effect. I found redrawing main screen too intrusive and inconsistent with other options that is not related to main screen. Any other option that changes screen behavior should redraw at event of "OptionEnd" event. SHould I redraw main screen, is it better behavior? It is simple one liner. Give your opinion.

When I removed the Custom Buttons things worked fine, that Pink center unit button is still their. I realy like the effect and think it should be perminent as it is but it needs some Art pronto. Can someone scroung up an artist?

I have ugly button for it but I fear that every one will laugh at that. So it is not included. But if you wish, I will include it as just "demo".
Is there any one who will donate better buttons image for it?

 

[The Great Apple]

Agreed with the release timing.

I think we should be a bit more strict with the timing next time around. When the deadline arrives, code gets merged, and any code which isn't ready doesn't get in. It should be alot easier this time as we have a server to work with. We also should do a brief test cycle beforehand, as discussed earlier in this threadm, to ensure that the stuff we've added goes together, and the interface (modding, and game) is good enough.

 

[The Great Apple]

This option value go into effect imemdatly when you close the option screen. Main screen need redarw to see the effect. I found redrawing main screen too intrusive and inconsistent with other options that is not related to main screen. Any other option that changes screen behavior should redraw at event of "OptionEnd" event. SHould I redraw main screen, is it better behavior? It is simple one liner. Give your opinion.

Can you not just set the relavent bits of the interface to be dirty, rather than the whole screen?

I have ugly button for it but I fear that every one will laugh at that. So it is not included. But if you wish, I will include it as just "demo".
Is there any one who will donate better buttons image for it?

What does the button do? I might be able to knock something up, or, failing that, I know a few people who I can probably bully into doing it.

 

[Impaler[WrG]]

Its a center screen on unit button, works just like the little Cicley pointer thing you get at the edge of the screen but because its consistently at the bottom of the screen and now racing all over the ege its a lot easier to click on. A simple bulls eye like Icon would work fine.

An alternative would be just displaying the Units own Button but this may become confusing to the player, what do yall think?

I think refreshing the display is advisable, its not that expensive. Infact that tiny pause blip you get is how you know its working (like the burning sensation you get from rubbing alcohol on a cut). It will also require less overhead for mod makers in the future as they wont have to pass any dirtybit information. If people feel its degrading performance we can always change it later.

At this point I am hopeing we can have next version out in a day or two, Is their any way for one of you to edit my release post with the new material as I will be working tonight and tommorrow. Wednsday is good for me though and I will update and start debugging then, I already found and corrected problems with my VoteModifier not passing the incressed votes to Python.

 

[The Great Apple]

Its a center screen on unit button, works just like the little Cicley pointer thing you get at the edge of the screen but because its consistently at the bottom of the screen and now racing all over the ege its a lot easier to click on. A simple bulls eye like Icon would work fine.

An alternative would be just displaying the Units own Button but this may become confusing to the player, what do yall think?

I think the unit's button would be confusing - too much like promotions. Can't you do something like this by double-clicking on the unit model in the bottom right or something. Maybe it's not the model, but I did think something down there did it.

I think refreshing the display is advisable, its not that expensive. Infact that tiny pause blip you get is how you know its working (like the burning sensation you get from rubbing alcohol on a cut). It will also require less overhead for mod makers in the future as they wont have to pass any dirtybit information. If people feel its degrading performance we can always change it later.

Good points. All of them.

Is their any way for one of you to edit my release post with the new material as I will be working tonight and tommorrow. Wednsday is good for me though and I will update and start debugging then...

Nope - not possible. It can wait until Wednesday though.

 

[12monkeys]

I would like to bring back SimCuties discussion about enable/disable python hooks back on top. During my tests I recognized that some the python hooks (especially those within the CvUnit class) results in a remarkable performance loss. On large scenarions with lots of units, you can loose up to 50% between two turns.

Because this is not acceptable I would like to make them enable/disable in any case, independently if the correct python files are there or not. We can also add such a feature to the original python hooks to gain some game performance, allthough the gain may be not that big.

I remember that SimCutie added in one of his very early versions an automatic detection of the python hooks.

SimCutie : I'm not sure if this feature is still part of your current adoptions, but if so can you tell some more details about it, please? Especially I would like to know, if the existance of the python part is checked each call or only once during initialization.

12m

 

[SimCutie]

This is button I had made. How about that?
....
You! Dont laugh! I know that it is crude...

 

[SimCutie]

I would like to bring back SimCuties discussion about enable/disable python hooks back on top. During my tests I recognized that some the python hooks (especially those within the CvUnit class) results in a remarkable performance loss. On large scenarions with lots of units, you can loose up to 50% between two turns.

Because this is not acceptable I would like to make them enable/disable in any case, independently if the correct python files are there or not. We can also add such a feature to the original python hooks to gain some game performance, allthough the gain may be not that big.

I remember that SimCutie added in one of his very early versions an automatic detection of the python hooks.

SimCutie : I'm not sure if this feature is still part of your current adoptions, but if so can you tell some more details about it, please? Especially I would like to know, if the existance of the python part is checked each call or only once during initialization.

12m

bool hasPythonAttr(LPCSTR module_name, LPCSTR attr_name )
Check existence of Python attribute value.
param module_name Python module name string.
param attr_name Python attribute key name to check.

This is API of the call.
It is not good idea to check existance of the entry point before each call.
It is better to check at StartGame/OnLoad time and use it afterward.
'OnInit' event time is bit too early. Because python MOD can add entry point routine dynamically at OnInit time.

Or I can provide a function that returns same result with above call but that caches check result. Then Python entry point caller will check everytime before calling the entry point but actually it is checked only once at game startup / on load time.
It will remove burden of the each caller to keep track of the check result.
There are three choice.
1) bool CallGameEntryPoint("canUnitMoveInto", PyArgs argsList, long & lresult );
It will check existance of the entrypoint automatically.
If the entry point exist, it will call the entry point for you. It return true as function return value and Python call result is in &lresult.
If the entry point doe not exist, it will return false and lresult value is unchanged.

2) bool hasGameEntryPoint("canUnitMoveInto");
Only returns existance of entry point as bool.

3) Both 1) and 2)

 

[SimCutie]

12Monkey's GameIntarface entry point are great contribution to our project.
But some of the entry point name seems to be little bit not so intuisive or inconsistent.
Some name sound like as if it is action-performing funcrion, but it is actually a predicate or pre-conditioning hooking function.

ex: razeCity()
It sound like a directive or command that orders Python to perform razing city, but it is not.
Better : willPlayerRazeCity() :
Player is about to raze city, will player actually raze the city? if return true, player will. if return false, player will not.

So I suggest some entry point name to have more consistant name.

My opnion on Python entry point name sugestion:

razeCity ==> willPlayerRazeCity (it is consistent with canPlayerRazeCity())
playerFoundReligion ==> willPlayerFoundReligion()
groupStartMission ==> willGroupStartMission()
doUnitCommand ==> willUnitDoCommand()
unitUpgradePrice ==> calculateUnitUpgradePrice()
spreadReligionToCity ==> willSpreadReligionToCity()

OR

razeCity ==> doPlayerRazeCity
playerFoundReligion ==> doPlayerFoundReligion()
groupStartMission ==> doGroupStartMission()
doUnitCommand ==> doUnitCommand() (NO change)
unitUpgradePrice ==> calculateUnitUpgradePrice()
spreadReligionToCity ==> doSpreadReligionToCity()

OR better yet...
Combind canXXX wit willXXX

like canWillXXX( args, bOriginalResult, bWillXXXX );

Example:
canXXX(args)
{
     bOrigRes =  canXXX_Orig(args);
    return canWillXXX(args, bOrigRes, false  )
}

doXXX(args)
{
    if !canWillXXX(args, canXXX_Orig(args), true)
         return;
    ....... do XXX actually.
}

How about that?

 

[chrusion]

It is useful to write self commenting code, code that has class, function, and variable names that refer to their place in the code functionality or at least give a good allusion to it.

Sometimes it is easy to name things in a way that I am familiar with but many others would misunderstand.
I try to read my code from other people's shoes and see if they would understand it.

Heck! I like to be able to pick up my own code later and understand it!
​

 

[12monkeys]

bool hasPythonAttr(LPCSTR module_name, LPCSTR attr_name )
Check existence of Python attribute value.
param module_name Python module name string.
param attr_name Python attribute key name to check.

This is API of the call.
It is not good idea to check existance of the entry point before each call.
It is better to check at StartGame/OnLoad time and use it afterward.
'OnInit' event time is bit too early. Because python MOD can add entry point routine dynamically at OnInit time.

Or I can provide a function that returns same result with above call but that caches check result. Then Python entry point caller will check everytime before calling the entry point but actually it is checked only once at game startup / on load time.
It will remove burden of the each caller to keep track of the check result.
There are three choice.
1) bool CallGameEntryPoint(&quot;canUnitMoveInto&quot;, PyArgs argsList, long & lresult );
It will check existance of the entrypoint automatically.
If the entry point exist, it will call the entry point for you. It return true as function return value and Python call result is in &lresult.
If the entry point doe not exist, it will return false and lresult value is unchanged.

2) bool hasGameEntryPoint(&quot;canUnitMoveInto&quot;
Only returns existance of entry point as bool.

3) Both 1) and 2)

All sounds good!I would prefer option 3 (always better to have more possibilites). We then could also change the stadnard API hooks. In general we than could simply coment each hook in CvGameInterface.py (the standard ones as well) and the perfromance will get a boost. Did you already implemented such a function?12m

 

[12monkeys]

12Monkey's GameIntarface entry point are great contribution to our project.
But some of the entry point name seems to be little bit not so intuisive or inconsistent.
Some name sound like as if it is action-performing funcrion, but it is actually a predicate or pre-conditioning hooking function.

ex: razeCity()
It sound like a directive or command that orders Python to perform razing city, but it is not.
Better : willPlayerRazeCity() :
Player is about to raze city, will player actually raze the city? if return true, player will. if return false, player will not.

So I suggest some entry point name to have more consistant name.

My opnion on Python entry point name sugestion:

razeCity ==> willPlayerRazeCity (it is consistent with canPlayerRazeCity())
playerFoundReligion ==> willPlayerFoundReligion()
groupStartMission ==> willGroupStartMission()
doUnitCommand ==> willUnitDoCommand()
unitUpgradePrice ==> calculateUnitUpgradePrice()
spreadReligionToCity ==> willSpreadReligionToCity()

OR

razeCity ==> doPlayerRazeCity
playerFoundReligion ==> doPlayerFoundReligion()
groupStartMission ==> doGroupStartMission()
doUnitCommand ==> doUnitCommand() (NO change)
unitUpgradePrice ==> calculateUnitUpgradePrice()
spreadReligionToCity ==> doSpreadReligionToCity()

OR better yet...
Combind canXXX wit willXXX

like canWillXXX( args, bOriginalResult, bWillXXXX );

Example:
canXXX(args)
{
     bOrigRes =  canXXX_Orig(args);
    return canWillXXX(args, bOrigRes, false  )
}
 
doXXX(args)
{
    if !canWillXXX(args, canXXX_Orig(args), true)
         return;
    ....... do XXX actually.
}

How about that?

Mmmh. I named the function corresponding the their counterpart in the SDK. The standard API function did have similar namings but even without a calss info in the name.
Its the choice now, if we want to lean the naming to Firaxis stadnard or to our own standards.
I would like to keep them as they are now, because they are more similar to Firaxis stadnard, they version is alrady released and the function itself is clearly documented to that their is no misunderstanding.
What do the others think about that?

 

[SimCutie]

Mmmh. I named the function corresponding the their counterpart in the SDK. The standard API function did have similar namings but even without a calss info in the name.
Its the choice now, if we want to lean the naming to Firaxis stadnard or to our own standards.
I would like to keep them as they are now, because they are more similar to Firaxis stadnard, they version is alrady released and the function itself is clearly documented to that their is no misunderstanding.
What do the others think about that?

Firaxis seems to use second convention in their CvGameIntarface. (doXXX)

Another good news. I have succeed that DLL works well on empty Assets (DLL Only) and game does not finished with "You have defeated" behavior.
It needs more test but seems to work for now.

 

[The Great Apple]

This is button I had made. How about that?

I actually quite like it!

 

[chrusion]

Yes the button SimCutie has made is nice.

 

[The Great Apple]

At the risk of being really annoying, I'm going to complain about the style of the mod thread again

Needs more spoilers. You have 'bug fixes' and 'gameplay options' in spoilers, but not any of the first 4 catagories. IMO they should all be in spoilers, as each part is individual, and a particular reader may only care about one particular part. At the moment it doesn't really look like a list, as there is a huge gap between 4) and 5) with a bunch of spoilers in between.

In other news - I'm getting home in ~ 1 week, so I may actually start being able to make some contributions.

 

[Impaler[WrG]]

I have been getting an odd error that I belive is linked with SimCuties Custom Button modual not being fully loaded before the Dawn of Man screen comes up. I usaly get this if I try to click play very quickly after DoM screen comes up or if I am clicking durring the later stages of the load bar just before. If I wait and pont make any inputs for a second or two I wont get the error. The Python acception apears so imediatly that I never get to see any of the DoM screen, I can drag the python exception and close it but their seems to be an infinite stack of them, perhaps their being generated non-stop. It hasen't occured at any other time or part of the game, if I keep still durring thouse first seconds I can play the game fine with out any other errors.

Heres a Screeny

 

[SimCutie]

I have been getting an odd error that I belive is linked with SimCuties Custom Button modual not being fully loaded before the Dawn of Man screen comes up. I usaly get this if I try to click play very quickly after DoM screen comes up or if I am clicking durring the later stages of the load bar just before. If I wait and pont make any inputs for a second or two I wont get the error. The Python acception apears so imediatly that I never get to see any of the DoM screen, I can drag the python exception and close it but their seems to be an infinite stack of them, perhaps their being generated non-stop. It hasen't occured at any other time or part of the game, if I keep still durring thouse first seconds I can play the game fine with out any other errors.

Heres a Screeny

Hmm.. it seems that player clicked screen before action buttons are fully inited. It is kind of race condition due to CPU is very busy while starting new game. I will fix it soon so that clicking action button is ignored before it is fully inited.

 

[The Great Apple]

Is this fixed yet SimCutie? If I'm not mistaken this is the only reason left why we haven't updated the mod currently posted to include your changes.

 

[Impaler[WrG]]

I'm going to upload my Unique Units for Leaders mod, it also includes some fixes to the TraitVote mod. The UU shows up everyware you would want it except the Leader pedia page (it was crashing me badly so its comented out and will be completed someday). I didn't want to change the getCivilizationUnits() function due to the great variety of places and ways it was called. Instead I had to replace all calls to getCivilizationUnits with a new LeaderHeadInfo function which took the Civ as argument (you cant get the Civ from within the leaderHead). The Python export was re-routed to a new function that calls the ActivePlayer and then Civ and Leaderhead units. This makes it work with any and all Screen interfaces without modification.

TGA why dont you post the next release when its ready, this way you can maintain the thread to high standards (also I think we get benifit of more views/reads due to your greater name recognition)

On the whole I think we need to get more moders involved and interested in our work, I think if we could get Lopez to adopt the SimCutie eventmanager/Option screen and rework his mod library for it that would give us a lot of publicity and interest. I've been a bit disapointed with the response so far from the first release dosn't seem to be getting many testers.

With UU ready I am going to put my Univerasl Building Modifier onhold and move right into exploring modular XML loading. I will also try to get around to using SimCuties backcompatable savegame reader and updating all my current mods with it.