First release

[SimCutie]

OOPS! My CHANGELOG is not ready to be released.. It is full of error and under extensive editing.. Don't trust it. *blush*

Surely this should not be runtime config? Event behaviour should be consistant throughout an individual mod, and should be controlled by the modder and not the player.

I see, So it has no custom option screen check box to be changed by player.
But I will consider to modify it to be configured only on boot time. (Python Mod should set it on 'OnInit' event time.)

... Documentation may be a bit lacking - I'd quite like to see examples of how to incorperate a new event manager,

Yes, lack of docs. I am working on it. But too short time until first release time. So I will do major work to supplement lacking docs after first release.
I am not English-native so it may be slow process, please be patient.

as well as define new options for the options screen. It would seem that you have to define them in an .ini file, and then in CvCustomOption.py, right?
.

No. Only places you should edit are your "EventHandlerRegister()" and handler code in *your* MOD. No editing of .ini file or CvCustomOption.py.
This is driving design objective of this implementation.

For example in *YOUR* MOD file...

import CvUtilCustom

def EventHandlerRegister( evt_mgr, unused = None ):
	
	import CvCustomEvent	
	return { 	CvCustomEvent.EVENT_OPTIONBEGIN : onDrawOption, }


def onDrawOption(argsList):
	optscr, canvas, Unused = argsList[:3]

        CvUtilCustom.useSection("MY_SECTION")
	# Show Checkbox on Option Screen

	optscr.addGenericCheckbox( canvas, "MYOption1Checkbox",
		"TXT_KEY_OPTIONS_MYOPTION1_LABEL", "MY_SECTION", "my_option1", False )

            # show Drop down box...
	aszDropdownElements = ( 
		"TXT_KEY_OPTIONS_MY_OPT2_DD0",
		"TXT_KEY_OPTIONS_MY_OPT2_DD1",
		"TXT_KEY_OPTIONS_MY_OPT2_DD2",
		"TXT_KEY_OPTIONS_MY_OPT2_DD3" )
	
	optscr.addGenericDropdown( canvas, "MYOPT2Dropdown", 
		"TXT_KEY_OPTIONS_MYOPT2_LABEL", aszDropdownElements, "MY_SECTION",
		"my_option2", 0 )


def Your_MOD_function():
       .........
       if CvUtilCustom.getCutomOption("MY_SECTION","my_option1", False) == True :
            do do  something acction to user choice....

     optVal =  CvUtilCustom.getCutomOption("MY_SECTION","my_option2", 0)
    if optVal == 0 :
      .............
     elif optVal == 1 or optVal == 2 :
     ............
      elif optVal == 3:

That is all... And add appropiate TXT_KEY_'s like "TXT_KEY_OPTIONS_MYOPTION1_LABEL"
and "TXT_KEY_OPTIONS_MYOPTION1_LABEL_TT" (for tool tip), "TXT_KEY_OPTIONS_MYOPT2_LABEL",
"TXT_KEY_OPTIONS_MYOPT2_LABEL_TT", "TXT_KEY_OPTIONS_MY_OPT2_DD1" ,
.... "TXT_KEY_OPTIONS_MY_OPT2_DD4" in text XML file.
NO editing of .ini file or CvCustomOption.py. is required.

You also seem to have alot of redundant files. From what I can tell the main interface changes aren't in effect, nor the civilopedia changes. We should really get rid of the files which don't actually do anything before the release.

Yeah, some Python files and XML files are included in ZIP file unintentionally. Ignore them ..
Civilopedia is not required to work properly. It is mistake.
But Main interface is included to demonstrate Action button faciliy. It should work to see action button. and Show grid/Show resource fix.

 

[SpoiledFruit]

The FTP server is back up and should work now. Let me know if you have problems in the server helpdesk thread. If you need a login name and password as well as the IP address, just PM me

Oh and TGA, could you get Thunder to Stickey the Helpdesk thread?

 

[The Great Apple]

OOPS! My CHANGELOG is not ready to be released.. It is full of error and under extensive editing.. Don't trust it. *blush*

Ooops. Sorry

Yes, lack of docs. I am working on it. But too short time until first release time. So I will do major work to supplement lacking docs after first release.
I am not English-native so it may be slow process, please be patient.

No problem - take your time.

No. Only places you should edit are your "EventHandlerRegister()" and handler code in *your* MOD. No editing of .ini file or CvCustomOption.py.
This is driving design objective of this implementation.

For example in *YOUR* MOD file...

<snip>

That is all... And add appropiate TXT_KEY_'s like "TXT_KEY_OPTIONS_MYOPTION1_LABEL"
and "TXT_KEY_OPTIONS_MYOPTION1_LABEL_TT" (for tool tip), "TXT_KEY_OPTIONS_MYOPT2_LABEL",
"TXT_KEY_OPTIONS_MYOPT2_LABEL_TT", "TXT_KEY_OPTIONS_MY_OPT2_DD1" ,
.... "TXT_KEY_OPTIONS_MY_OPT2_DD4" in text XML file.
NO editing of .ini file or CvCustomOption.py. is required.

Aaaah, I get it! That's actually really neat!

Yeah, some Python files and XML files are included in ZIP file unintentionally. Ignore them ..

Ok, will ignore. I had assumed some of them were junk anyway.

 

[The Great Apple]

The FTP server is back up and should work now. Let me know if you have problems in the server helpdesk thread. If you need a login name and password as well as the IP address, just PM me

Oh and TGA, could you get Thunder to Stickey the Helpdesk thread?

Works great! I shall PM Thunderfall.

Ok guys - scrap the plan with the uploading to CFC, let's get FTPing.

 

[12monkeys]

@ SimCutie
I had a look on your files and its a impressive mass of changes which you implemented. But there are several points which makes me think that we should not use them that way for the release.

a.) I did check nearly each non SDK file for its contents and I found a lot of files with questionable contents, sense or format. Its hard to determine which file is an example, which file is used and which has been added accidently.
b.) There is general lack of comments and documentation. The comments which are found does not match our specifiation.
c.) The changed SDK files (cpp and h) still contains #ifdefs, allthough we decided not to use them. BTW : I was not able to compile the project. It may be because I didn't used your project file and simply copied the cpp an h files into my version. I got fatal errors while linking. Did you maybe forgot an h file? Anyway that makes it impossible for me to test anything from your package.
d.) The single changes and files in the non SDK part, can't be assigned to the modification they belong to. As a modder, I would like to know what the code is doing and for what changes the modifcations are.
e.)The list of modifcations you implemented is impressive, but, to be honest, I would prefer a third of them if they are completed, documented and tested. The current situation is, that they are not documented and badly commented.
f.) you seems to removed several events. If so, this is not a good strategy. this may make existingmods incompatible. Better would be to add events and than to remove or replace them.

SimCutie, please don't take this personal, but you need to do your modifications more carefully. I don't talk about the quality of your change, in fact I think you're a brilliant developer. Only looking on the Action Button changes and the Event Handler, tells me that you a way better developer than me. Its even hard for me to understand what and way you are doing things the way you did. But exactly that may become a problem for the project. The project has the target, to deliver a common core (you may also tell it a framework) for the complete community. But this presupposes that the people need to UNDERSTAND the framework. If nobody understand how the changes works, or at least how to USE it, they won't use the framework.
I think I'm a average programmer with average skills. But I'm working in the software developement (actually as project manager, former as developer) for nearly 18 years now and I saw a lot of people, problems and projects come and go. Out of my expereince, there is not much more important than to keep code simple. I agree that sometimes code must be complex out of the problem. But if you need to make it complex you have to balance this with a good documentation and/or sample implementations. You may did so, but I can't identify them as this, because you send us a bunch of bad documented files.
Please let me make a suggestion: looking at your list of changes, we should reduce the list of implemented features to a smaller amount. Than you can concentrate on those features to implement them consequently, to document them and maybe to create sample implementations (eg. for the action buttons and/or event handler).

Especially for the first release, the parole shold be "quality is better than quantity".

Attached you will find a ist with comments to your non SDK files and the list of the errors form the linker.

12m


PS : I haven't merged my changs because it makes no sense without being able to compile it.

 

[SimCutie]

@ SimCutie
I had a look on your files and its a impressive mass of changes which you implemented. But there are several points which makes me think that we should not use them that way for the release.
.......[snip]
Especially for the first release, the parole shold be "quality is better than quantity".

Attached you will find a ist with comments to your non SDK files and the list of the errors form the linker.

12m


PS : I haven't merged my changs because it makes no sense without being able to compile it.

Oh! Thank you very much for kind comment and criticism... This comments would be invaluable advice for my work..

Some XML files are errornously included in ZIP file.. Please ignore them...I am sorry for confusing you.

There is genuine lack of documentation indeed but this is just alpha or beta stage of the project and just 1.0 at best. It is changing and evolving so fast; moving target is hard to document.
You are too much to expect complete document for 1.0 of this kind of hobby project of just little over a month. You must be very demending boss or manager, I guess
I need some more time to build up docs. I am not English-native and not even belong to Latin-languge group. Pardon me for a while for lack of documents.
Example usages in working souce code is currently best document.
But think of how much of docs/comments the Firaxis code has?
I boast much higher density of comment and docs compared with Firaxis code or other averge Modders in Civfanatics commiunity.

#ifdef thing is currently under use for regression/component testing.
I will remove it if it is considered as stable and semi-permanent part of the SDK.
It is too early to commit them as permanent part.

Use "CvGamCoreDLL.vcproj" file in ZIP to include addtional files to your project. All linkage error are reference to the added new files.

On event removal: There is only one event removed. And it is actually replaced with similar event. Because old one is considered to be a BUG. Wrong event in wrong time and with wrong argument. So it is hardly utilized productively by any current MODS.

On understanding frame work:
No I don't think so. The usage of this framework is rediculously easy and simple.
Just one example explains it all. See first few part (line 55-110, 157-161) of "SimCutieMainInterface.py".
It has examples for Event handler, screen handler, action button and Custom option screen, custom option access, abd DLL access .. nealy all in just 50 lines.

I can not imagine the same work can be expressed or implemented in simpler way than this.
Take little time to understand it.

The attched ZIP above is not intended as final submission, so don't use it as base for merge as final release. I haven't seen any of other modder's code and didn't check for any possible conflict or inconsistency. I just posted the ZIP to promote others to post current source which is being worked on.
Has anyone posted some code except me? I wanna see yours all... please post....

 

[SpoiledFruit]

Well now with my FTP server up (and actually WORKING!!!!) I think we should show and merge filse via the personal folders and implement beta changes in the civ4 folder where the main source code is. I would also like people to use the included project or solution file (i have a free software addin that does python in VS.net I will put in my folder should make combining code much easier) That way we dont have to search posts to find files.

 

[12monkeys]

Oh! Thank you very much for kind comment and criticism... This comments would be invaluable advice for my work..

Ok, first of all, sorry for the harsh words (if so). I really don't want to offend you.

Some XML files are errornously included in ZIP file.. Please ignore them...I am sorry for confusing you.

There is genuine lack of documentation indeed but this is just alpha or beta stage of the project and just 1.0 at best. It is changing and evolving so fast; moving target is hard to document.

If this is alpha or beta state, than you shold to mark them as this. I thought you posted it to start the "merging cycle".
My usual way of working is that I only have one topic in work and I do implementing, testing and documenting it completly, before I start another one. Looking at yours it seems to me that you started 8 points without finalizing one completly. Please keep in mind, that have to work in a team and that the changes needs to be understood by the others. You put yourself under pressure if you start to much at one time (at least this is my opinion).

You are too much to expect complete document for 1.0 of this kind of hobby project of just little over a month. You must be very demending boss or manager, I guess
I need some more time to build up docs. I am not English-native and not even belong to Latin-languge group. Pardon me for a while for lack of documents.
Example usages in working souce code is currently best document.
But think of how much of docs/comments the Firaxis code has?
I boast much higher density of comment and docs compared with Firaxis code or other averge Modders in Civfanatics commiunity.

Again, I don't think so. If we want the modders use our work, they have to understand it. We have a different position to firaxis, because they built the game everbody wants. There is a large community analyzing the SDK and API and creating documents and guidelines to use. We are only a few people offering something which MAY help them. Don't expect that anybody will spend much time to anlyze and dcoument what WE are doing. If the modders have the feeling, that it is to complex or that the don't understand how to use it, than they won't use and we failed.
Regarding examples : there may be example, but they can hardly be indentified as such. Examples must be marked as examples. Mybe you put those files into a seperate subdirectory.

#ifdef thing is currently under use for regression/component testing.
I will remove it if it is considered as stable and semi-permanent part of the SDK.
It is too early to commit them as permanent part.

If they are tested they will be permanant part. To have a config option to switch them on/off whould be enough.

Use "CvGamCoreDLL.vcproj" file in ZIP to include addtional files to your project. All linkage error are reference to the added new files.

I copied all your files into my solution. Anyway, I'll test it again this evening.

On event removal: There is only one event removed. And it is actually replaced with similar event. Because old one is considered to be a BUG. Wrong event in wrong time and with wrong argument. So it is hardly utilized productively by any current MODS.

Still not sure if wouldn't be better to add a new one, instead of removing an old one. But OK.

On understanding frame work:
No I don't think so. The usage of this framework is rediculously easy and simple.
Just one example explains it all. See first few part (line 55-110, 157-161) of "SimCutieMainInterface.py".
It has examples for Event handler, screen handler, action button and Custom option screen, custom option access, abd DLL access .. nealy all in just 50 lines.

I can not imagine the same work can be expressed or implemented in simpler way than this.
Take little time to understand it.

Again, examples hould be marked as examples.

The attched ZIP above is not intended as final submission, so don't use it as base for merge as final release. I haven't seen any of other modder's code and didn't check for any possible conflict or inconsistency. I just posted the ZIP to promote others to post current source which is being worked on.
Has anyone posted some code except me? I wanna see yours all... please post....

If this is the intention of your ZIP than its OK, but you posted that we should try to start merging via forum. So I took the ZIP as your release version.

But before you upload some files next time, have them more clean and ready, please.

Above you said that, I may be a demanding boss. I'm working in the computer aided quality control business and have some years of experience as developer and project manager. As a project mangaer I'm the one who have to go to the customer to specify the changes and to anylze customer demands. And I'm the one who is repsonsible to make the customer satified.
Maybe thats the reason why I have a different look on those things, because usually the customer beats me when something does not work or is not what they expected.
I'm just glad that nobody has to spend money for it

I think, we just starting with something which is a bit new in the community. To gain acceptance, we have sell ourself a bit especially in the first release. Thats why I said: quality is more important than quantity.


12m

 

[The Great Apple]

To be honest the simplest event manager is the Firaxis standard one - you just put your things where the events are. What could be easier to understand? The way you've implemented it, while neater, and even simpler, is less easy to understand in the first place.

12m makes some very valid points. If we release a version that people don't understand, then make it simpler in later versions, people won't use the first versions because they don't understand them, and then may not try later versions becasue they thing they won't understand them. We have to remember that alot of people may not have written a line of code before they bought Civ 4, and so while we can hide complicated stuff away where they don't have to worry about it, the actual bits they do have to worry about (event manager, and so forth) should be very simple to understand.

As for the lack of time - it can't be. We need to release something soon, before it becomes too late and people don't use it because it conflicts with another SDK mod. The later we leave it, the less willing individual modders will be to merge their work with ours.

I think, we just starting with something which is a bit new in the community. To gain acceptance, we have sell ourself a bit especially in the first release. Thats why I said: quality is more important than quantity.

I have to agree with this. Also:

4) Moddability - make sure that the added modding feature is easy to understand, as well as potentially useful. Too many added features will slow the game, as well as make existing features more complicated to use. These features should have no effect unless activated by a modder.

Relating to the FTP. If you can upload you're working projects along with any working release versions in the folders, then people can easily browse through and comment on your working code, and whenever we decide to do a release we can combine together all the files in the "release" folder, test, and then release it.

 

[SimCutie]

To be honest the simplest event manager is the Firaxis standard one - you just put your things where the events are. What could be easier to understand? The way you've implemented it, while neater, and even simpler, is less easy to understand in the first place.

12m makes some very valid points. If we release a version that people don't understand, then make it simpler in later versions, people won't use the first versions because they don't understand them, and then may not try later versions becasue they thing they won't understand them. We have to remember that alot of people may not have written a line of code before they bought Civ 4, and so while we can hide complicated stuff away where they don't have to worry about it, the actual bits they do have to worry about (event manager, and so forth) should be very simple to understand.

As for the lack of time - it can't be. We need to release something soon, before it becomes too late and people don't use it because it conflicts with another SDK mod. The later we leave it, the less willing individual modders will be to merge their work with ours.

I have to agree with this. Also:


Relating to the FTP. If you can upload you're working projects along with any working release versions in the folders, then people can easily browse through and comment on your working code, and whenever we decide to do a release we can combine together all the files in the "release" folder, test, and then release it.

My rationale on the event manager code is "complex in implementation, simple in usage".
Indeed, Mine is much complex than Firaxis or any other custom event managers.
Because it does an acrobatic feat any other event manager didn't and can't, to make it easy and simple for modder to use event manager and multiple mod by the general players.
I don't think that python modder in general who uses this event manager should understand the event manager code. It is not what I intended. It is enough just understand *interface* only.
The interface of this event manager is the simplest form ever invented. Just return one python dict data with event name - handler value pairs. The event manager will do it all automagically for you. Could you ever imagine any simpler way to express them? Much more simpler than even the Firaxis one.
This event manager code should be treated like a blackbox which you should communicated only through interface. The internals of the event manager code is not for faint-of-heart or children or pregnant women.

Actually it is too simple to use that no documentation is needed to use the event manager. Then, it accomplishes a feat that no event manager ever did. No need to add or edit event manager code to use it. Not a single line. not a single character. This makes it tremendusly easier to use or merge or manage multiple mod by the player without any modding skill.
So modder don't have to look into it, no need to unserstand it. Say, the manager code can be compiled into binary form ( *.pyc form) or obfuscated beyond recognition and distributed and used without problem.

 

[The Great Apple]

The interface is simplest form ever invented. Just one python dict data with event name - handler value pairs does it all. Could you ever imagine any simpler way to express them?

I could argue here that I know of quite a few people who mod in python who don't know what a dictionary is.

I understand what you are saying though.

I think most people could manage if an example file was made to trigger at some default events, and do some action. Something like printing a message when you move a unit, or at the start of every turn. This way people could see quickly how it tied into whatever they currently have.

From a brief glance this would work, right? (assuming standard imports)

def EventHandlerRegister( evt_mgr, unused = None ):

	return {
		'BeginPlayerTurn' : beginGameTurn,
		'unitMove' : unitMove
	         }

def unitMove(argsList):
	CyInterface().addImmediateMessage("You have just moved a unit","")

def beginGameTurn(argsList):
	CyInterface().addImmediateMessage("You have just begun a turn","")

Hmmm. Might it not be a good idea to have the default set up to return blanks for all the events except the ones the modder defines to be different, just so all the handlers are there for everybody to see?

Hmmm. I have to go know. I might post more random thoughts later.

 

[SimCutie]

I could argue here that I know of quite a few people who mod in python who don't know what a dictionary is.

I understand what you are saying though.

I think most people could manage if an example file was made to trigger at some default events, and do some action. Something like printing a message when you move a unit, or at the start of every turn. This way people could see quickly how it tied into whatever they currently have.
.. [snip....]

Hmmm. Might it not be a good idea to have the default set up to return blanks for all the events except the ones the modder defines to be different, just so all the handlers are there for everybody to see?

Hmmm. I have to go know. I might post more random thoughts later.[/QUOTE]
Code above is correct except that handlers need same argument just like Firaxis event handlers.
Default action of event that does not have custom handler is not doing nothing.
Event manager calls default Firaxis handler code in original Firaxis "CvEventManager". 
Even event *with* custom handler will execute default Firaxis handler unless it explicitly prohibit it by rerturning True as return value of custom handler.
Hmm.. Providing default handler for event with empty handler would be good idea. 
Currently { 'event': None } dict will print one error message log and be ignored. 
Printing on screen event notification may be better than ignoring it.
Currently, all outstanding *custom* event handlers are printed in "PythonDbg.log" file like this:
[code]
Custom event handlers
  'UnInit+' =: [<Boost.Python.function object at 0x18488C10>]
  'buttonShow' =: [<function onShowButtons at 0x189A3D30>, <function
onShowButton at 0x18719B30>, <function onShowButton at 0x18781C30>]
  'UnInit-' =: [<bound method CvSimCutieMainInterface.onUnInit of
<CvSimCutieMainInterface.CvSimCutieMainInterface instance at 0x18997030>>]
  'UnInit' =: [<function onUnInit at 0x18647BF0>]
  'Init+' =: [<Boost.Python.function object at 0x18488BE0>]
  'buttonAction' =: [<function onActionButtons at 0x187811B0>, <function
onButtonAction at 0x1864AAB0>, <function onActionButton at 0x18781830>]
  'Init' =: [<function onDLLOptionUpdate at 0x18647C70>]
  'optionEnd' =: [<function onDLLOptionUpdate at 0x18647C70>, <bound method
CvSimCutieMainInterface.onCloseOption of
<CvSimCutieMainInterface.CvSimCutieMainInterface instance at 0x18997030>>]
  'OnSave-' =: [<function onSaveUtil at 0x18916270>]
  'OnLoad+' =: [<Boost.Python.function object at 0x18488C50>, <function
onLoadUtil at 0x18916870>]
  'GameStart+' =: [<Boost.Python.function object at 0x18488C90>]
  'InitEnd+' =: [<function InitUtilCustom at 0x18916830>]
  'optionBegin' =: [<function onDrawOption at 0x18781070>, <function
onDLLOptionDraw at 0x18647C30>, <function onDrawOption at 0x1864AF70>, <function
onDrawOption at 0x187818B0>]

 

[The Great Apple]

Code above is correct except that handlers need same argument just like Firaxis event handlers.

Oh yes, forgot that bit. I was in a hurry. I have corrected it.

About the other stuff - what I meant is that we'd distribute an event handler template so that all the events are listed for easy use. For example this code would be in the file we send out as a template event manager file:

def EventHandlerRegister( evt_mgr, unused = None ):
	# Format: { 'eventname 1' : <function to run 1>, ...,  'eventname n' : <function to run n> }
	EventHandlerMap = {
		'mouseEvent'		: None,
		'kbdEvent' 		: None,
		'Init'			: None,
		'Update'		: None,
		'UnInit'		: None,
		'OnSave'		: None,
		'OnPreSave'		: None,
		'OnLoad'		: None,
		'GameStart'		: None,
		'GameEnd'		: None,
		'plotRevealed' 		: None,
		'BeginGameTurn'		: None,
		'EndGameTurn'		: None,
		'BeginPlayerTurn'	: None,
		'EndPlayerTurn'		: None,
		'endTurnReady'		: None,
		'combatResult' 		: None,
		'combatLogCalc'	 	: None,
		'combatLogHit'		: None,
		'improvementBuilt' 	: None,
		'routeBuilt' 		: None,
		'firstContact' 		: None,
		'cityBuilt' 		: None,
		'cityRazed'		: None,
		'cityAcquired' 		: None,
		'cityLost'		: None,
		'cultureExpansion' 	: None,
		'cityGrowth' 		: None,
		'cityDoTurn' 		: None,
		'cityBuildingUnit'	: None,
		'cityBuildingBuilding'	: None,
		'cityRename'		: None,
		'unitMove' 		: None,
		'unitSetXY' 		: None,
		'unitCreated' 		: None,
		'unitBuilt' 		: None,
		'unitKilled'		: None,
		'unitLost'		: None,
		'unitPromoted'		: None,
		'unitSelected'		: None, 
		'UnitRename'		: None,
		'goodyReceived'        	: None,
		'greatPersonBorn'      	: None,
		'buildingBuilt' 	: None,
		'projectBuilt' 		: None,
		'techAcquired'		: None,
		'techSelected'		: None,
		'religionFounded'	: None,
		'religionSpread'	: None,
		'goldenAge'		: None,
		'endGoldenAge'		: None,
		'chat' 			: None,
		'victory'		: None,
		'changeWar'		: None,
		'setPlayerAlive'	: None,
		'windowActivation'	: None,
		'gameUpdate'		: None,
		<Insert custom stuff here>
			}
	return EventHandlerMap

Then the user just puts the function they want to run into the map. If the map returns None then nothing at all happens. This will document all the events possible, as well as any custom events we happen to have. Maybe an example of how to trigger an event from the map would be good.

I suggest this method because it puts all the possible event names in front of the modder's face - they don't have to go around searching for whatever the name of the event they want is - it's right there for them.

Each mod could have a unique version of this template, and all would be good.

 

[12monkeys]

OK, my files are uploaded on the FTP server. They are in my user directory, for further checks and comments. They are final and ready for final testing through the team.

12m

 

[The Great Apple]

I like what you've done to CvGameUtils. Some great additions there. I know for certain I'll use the canConvert function myself. I can see lots of people having fun with the other functions as well.

 

[SimCutie]

OK, my files are uploaded on the FTP server. They are in my user directory, for further checks and comments. They are final and ready for final testing through the team.

12m

On style of canXXXX() hooking..
When you hook some existing canXXX predicates (like CvUnit::canMoveInto())
You use two separate Python entrypoint..( eg. "canMoveInto", "canMoveInto2")
It will confuse modder and has two times of overhead of calling python.
Python call is very expensive call (big overhead) so it should be avoided when Python "canMoveInto" is not used.
It can be improved for better way.

See this code.

.................
bool CvUnit::canMoveInto(const CvPlot* pPlot, bool bAttack, bool bDeclareWar, bool bIgnoreLoad) const
{
// ------ BEGIN BY SIMCUTIE (2006-05-16) ---------------------------------
#ifdef SIMCUTIE_UNITEXT
	bool bcanMoveIntoResult = canMoveInto_Orig(pPlot, bAttack, bDeclareWar, bIgnoreLoad);

	return canMoveInto_Python(pPlot, bAttack, bDeclareWar, bIgnoreLoad, bcanMoveIntoResult);
}

bool CvUnit::canMoveInto_Orig(const CvPlot* pPlot, bool bAttack, bool bDeclareWar, bool bIgnoreLoad) const
#endif // SIMCUTIE_UNITEXT
{
// ------ END BY SIMCUTIE ------------------------------------------------
	TeamTypes ePlotTeam;

	FAssertMsg(pPlot != NULL, "Plot is not assigned a valid value");

.......................... (original canMoveInto() codes)

extern bool callPythonEntryPoint( LPCSTR szPyFunc, CyArgsList &pyArgs, long &lResult );

// called by CvUnit::canMoveInto() to check if the Unit can move into the plot.
// This calls "CvGameInterface.py/canUnitMoveInto()"  Python entry point
// extra invocation argument : bCanMoveInto - boolean result from original canMoveInto()
//
bool CvUnit::canMoveInto_Python( const CvPlot* pPlot, bool bAttack, 
		bool bDeclareWar, bool bIgnoreLoad, bool bcanMoveIntoResult )	const
{
	if ( !cm_hasCanUnitMoveInto )
		return bcanMoveIntoResult;
	long lResult = bcanMoveIntoResult;	// default on call failure.
	const CyUnit* pyUnit = new CyUnit(const_cast<CvUnit*>(this));
	const CyPlot* pyPlot = new CyPlot(const_cast<CvPlot*>(pPlot));

	CyArgsList pyArgs;
	pyArgs.add(gDLL->getPythonIFace()->makePythonObject(pyUnit));
	pyArgs.add(gDLL->getPythonIFace()->makePythonObject(pyPlot));
	pyArgs.add(bAttack);
	pyArgs.add(bDeclareWar);
	pyArgs.add(bIgnoreLoad);
	pyArgs.add(bcanMoveIntoResult);

	(void) callPythonEntryPoint( PYFUNC_CANUNITMOVEINTO, pyArgs, lResult );
	delete pyUnit; delete pyPlot;
	return ( lResult );
}

cm_hasCanUnitMoveInto is class static member(== global) boolean variable.

and in global initalization code

//! \brief		Check existence of Python attribute value..
bool hasPythonAttr(LPCSTR module_name, LPCSTR attr_name )
{
	FCheckString(module_name); FCheckString(attr_name);
	if ( isStrOK(module_name) && isStrOK(attr_name))
	{
		PyObject *py_mod = PyImport_ImportModule (const_cast<char*>(module_name));
		return  ( py_mod &&  PyObject_HasAttrString( py_mod, (char*) attr_name);
	}
	return false;
}

//	Common init for GameStart or OnLoad case.
static void CvExt_GameBegin()
{
	FAssertMsgExt( getInitStage() == ESTAGE_READY , "Init stage error" );
	setInitStage( ESTAGE_PLAY );
	report_stage(true);
	// init code here...
	CvUnit::cm_hasCanUnitMoveInto = hasPythonAttr(PYMODULE_ENTRYPOINT, PYFUNC_CANUNITMOVEINTO);
	report_stage(false);
}

This will remove overhead of calling python entrypoint when no CvGameInterface.py/canUnitMoveInto() is defiend.
And it will reduce two python invocation call into just one call.
Yet, the Python "canUnitMoveInto" entry point can check original canMoveInto result at hand, so modder can decide to honour the result or to ignore the result at modder's will, so you need just one call to Python.

PS. You don't have to edit and pre-define "canUnitMoveInto()" in "CvGameInterface.py"
It can be dynamically added in Run-time to "CvGameInterface.py" by python mod when the mod has need to hook "canMoveInto".

def setPythonEntryPoint( funcName, funcDef):
	""" Add Python Entry poin function to CvGameInterface module.
		Added function can be called from SDK/"CvExtension.cpp/setPythonEntryPoint() """
	import CvGameInterface
	assert funcName and isString(funcName) and callable(funcDef)
	setattr(CvGameInterface, funcName, funcDef ) 

...............
def My_canUnitMoveInto(argsList):
           pyUnit, pyPlot, bAttack, bDecalreWar, bInoreLoad, bcanMoveIntoResult = argsList[:6]
           .........
           return my_result;

On OnInit() event:
 
            setPythonEntryPoint( "canUnitMoveInto", My_canUnitMoveInto)

PS2: I used "canUnitMoveInto" instead of "canMoveInfto" because CvSelectionGroup has same canMoveInto().
I recommend change other Entry point names more descriptively. (ex: "canWork" -> "canWorkOnPlot" )
You should not expect general Python modder will read SDK code. So no need to match both name sacrificing readability/undertandability of Python code.

PS3: Some Python entrypoint predicate canXXX like canStartMission()/canTradeWith()/canFound()/canConvert() returns TRUE, FALSE, or -1. -1 for obeying original code result. It is confusing.
Python canXXX() should return always boolean value. not -1.
No other Firaxis canXXX() Python entry point uses such questionable practice.
You can use same scheme described above to make them return only boolean value.

 

[SimCutie]

Oh yes, forgot that bit. I was in a hurry. I have corrected it.

About the other stuff - what I meant is that we'd distribute an event handler template so that all the events are listed for easy use. For example this code would be in the file we send out as a template event manager file:

<.............>

Then the user just puts the function they want to run into the map. If the map returns None then nothing at all happens. This will document all the events possible, as well as any custom events we happen to have. Maybe an example of how to trigger an event from the map would be good.

I suggest this method because it puts all the possible event names in front of the modder's face - they don't have to go around searching for whatever the name of the event they want is - it's right there for them.

Each mod could have a unique version of this template, and all would be good.

I guess it is not good way when integrating multiple mod which uses "EventhandlerRegister()" for its own mod.
This is scheme is designed to make mutiple mods working in harmony without stepping on other mod's toe working togather. It should install event handler for only events that the mod has need to handle. Leave alone for event that the mod doesn't care. The list itself is readily available in any modder's and player's installation folder.

 

[SimCutie]

OK. I sensed some feeling of reluctance among members here all to accept radical approach of my eventmanager ( using dict data to install handler)

So I added somewhat more conventional way to do same work.
You all may be accustomed to old addhandler() method thing.
So I added similar interface to the my event manager.

Here is example usage:

More conventional way:
def EventHandlerRegister(evt_mgr, unused):
       evt_mgr.addEventHandler('Init', onInit) 
       evt_mgr.addEventHandler('UnInit', onUnInit, evt_mgr.PRIORITY_HIGH)

Radical way:
def EventHandlerRegister(evt_mgr, unused):
      return { 'Init' : onInit ,  'UnInit+': onUnInit }

Both way works in exactly same way.
Are you satisfied?

 

[SimCutie]

On date format:
Some members here uses date format like 23-05-2006 ( day-month-year).
It is questionable convention and discouraged in source code commenting for clarity . Because someone uses 05-23-2006 for same date (month-day-year) even in same western civilization.
date like 05-10-2006 can be interpreted as May 10th or October 5th.
If the year is abbreviated in two digits (frequent practice) it is total chaos.
Can you tell what date it is 07-05-06?
So I recommend to use ISO international standard date format like 2006-05-23. (year-month-day)
Or at least, Use month name like 23-May-2006 or May-23-2006

 

[SimCutie]

Ok, first of all, sorry for the harsh words (if so). I really don't want to offend you.

No problem, constructive criticism is the way we are getting better than before. And I always appreciates frank word than sweet lie. Your advice is really good medecine for my code.

Above you said that, I may be a demanding boss. I'm working in the computer aided quality control business and have some years of experience as developer and project manager. As a project mangaer I'm the one who have to go to the customer to specify the changes and to anylze customer demands. And I'm the one who is repsonsible to make the customer satified.
Maybe thats the reason why I have a different look on those things, because usually the customer beats me when something does not work or is not what they expected.
I'm just glad that nobody has to spend money for it
I think, we just starting with something which is a bit new in the community. To gain acceptance, we have sell ourself a bit especially in the first release. Thats why I said: quality is more important than quantity

Oh I understand... Sticking to quality is good point that I should learn from professionals like you. I am just a hobbist in modding. I should have much thing to learn from you.
But our project is not commercial product. So I think that applying or demending strictly same practice and standard of quality like commercail product to our project is too much or just overkill and counter-productive. More over Civ4 is just a game, not mission-critical or life-supporting software of spaceship.
To accomplish such degree of quality of code and documentation, we would hardly make out any notable thing before next expansion come out! and the next expanison is following us, not far from our back.