SnapShot of my current work, Please comment...

[SimCutie]

This is not official release, but now we had worked on SDK over two weeks..
So I think that it is time to share some preliminary initial batch of my work.
Nothing much to show off now. Just a snapshot to show what I am doing now..
But as a start up stuff, not so bad..
Modder here, Please give your opinion or advice...
What kind of utility function do you need urgently?

Most of new codes are in CvExtension.cpp and CvUnit.cpp

Edit: ZIP Upload Done.
Most of Changes are about building "base infrastructure and utility" for futhure modding work.

 

[The Great Apple]

Unfortunetly I can't access .rar files here at uni, so I can't check it out. Could you upload it in .zip format maybe?

Also - what exactly have you changed, out of interest?

 

[12monkeys]

I had a glimps. Some questions :
you made three major changes :

a.) UniText
b.) two new widgets WIDGET_ACTION_BUTTON and WIDGET_PYTHON_ACTION.
c.) a new for In-Combat-Event

Some Questions and remarks :
to a.) I have no clue about what it is for. Can you give us some more details, please?

to b.) Those widget code in CvExtensions.cpp is ... well ... too complex for me. As I understand it you defined two new widgets which can be used to define and create some Action buttons. In general this is nice, even better if it works. Where is the advantage against the already existing solution? Can you also give us some python examples how they can be used?

to c.) What is the intention of that event? Can you give us some more infos for it as well?

Seems to me that it was a quite large peice of work, especially if you did in your free time. Sorry that I can't praise your work, but I simply have the problem, that I don't understand the needs for it by shortly reading the code. So, please, give us some more explanations about it.

One thing to note is comment syntax, which doesn't match our agreement. Because its a beta preview version, I suggest you will change that before final release.

You did used some IFDEF compiler directives. Why? All you did is just an enhancement of the Python API and its ablitlites. This is neutral to gameplay and dont requires a swictc at all.
The only reason I found to have a switch in there, is the load and save game function which you altered as well. I don't know, what happens if you load an old game with the new dll.

BTW. this is a point we have to discuss : do we want/need to be backwards compatible with save games.

 

[The Great Apple]

One thing to note is comment syntax, which doesn't match our agreement. Because its a beta preview version, I suggest you will change that before final release.

Yes, please can we keep the commenting sytax sane. I've left most of the stuff in there optional, but we do need the mod creater and mod name so that if the code get's altered at a later date we can sort out interdepenancies and suchforth. The reason for the commen syntax is so that people will be able to recognise it at a glance.

BTW. this is a point we have to discuss : do we want/need to be backwards compatible with save games.

Hmmm.

Do we need it? No. Do we want it? Yes!

From what I can tell the save-game stuff is handled by the read/write functions in many of the files. If we're good, we should be able to just initialise new values for pieces of data not already stored in the save game, right?

I can see some cases complete save-game compatablilty won't be possible - if we're changing the way some saved value works, for example. I suggest we save these sorts of changes to be released together, making sure that everybody knows their games won't be compatable.

 

[SimCutie]

a) UnitExt : Not much big thing.

1. Added truely unique and invariant Uinit ID. It is unique across all units of *ALL* players and will not chnage before/after unit upgrade/unit gift. You can use the UID as true key or handle to individual units.
2. Script data is preserved across upgrade/gift.
3. getNamekey() will return true TXT_KEY_ key for Great People.
4. More genaral unit data save/load framework. (under study) including versioning.
planned : fast UID -> CvUnit look up. Dynamic Unit XML varible. ( Remove need to change SDK code to add new XML vaiable)

b) Much more flexible and dynamic than existing Action Button 2.0 facility. In fact, it is more general "Custom Widget Action" facility. Any new widget ( Not just fixed action button but any graphical widget on the screen) can have its own class of python handler and help text. (No need to change SDK code) It can dynamically change handler/button/help text. Any thing can be set and chanaged in Python code. No XML file needed. It is not possible with talchas's Action button 2.0 (because it is based on static XML file). As added benefit, now python code can do anything that mouse click can do. (like turning grid on/off in Python)
Actually, Action button feature is just an application/specilization of more general dynamic widget action facility.
Planned feature is that you don't have to edit or change "CVGameInterface.py" file to add a new handler for widget. ( Dynamic addition of handler code itself!)

c) No unitCreated/unitLost event on upgrade/gift. Instead it will trigger new unitReborn event. No more useless CombatOddCalc event. Instead it will trigger beginComat event with more useful infomation arguemnt. New combatHit event for every round of combat with more sane and useful argument and on more useful timing than combatLogHit event.

On Save/load data: My intention is not backward compatibility. On the contrary, it is to prevent old version of save file from loading amake make a havoc. But within some degree of compatible change like adding few new varaibles, it will remain comatible to old save file.

Any opinion or request on this code?

P.S. It is sad that I had to slash time to play Civ4 to spare more free time to write this SDK mod. I worked harder in free time of evening than work time of a day. I am not even a professional programmer myself!

.

 

[Impaler[WrG]]

These look like some usefull changes, admitedly much of that Widget code went over my head but I understand your improving Python Modability which is great.

I noticed what might be a typo in your code, their were some references to "Depender" which I think might have been ment to be "Defender".

The CvGameCoreDllxt.h is a good idea for keeping all our globals and control type stuff, but I would rather we call it ComunityEnhancments.h to make it more explicit.

I agree with DozenMonkeys that none of your changes are things that need an ifdef, infact I dont realy think we should be useing any ifdefs. The vast majority of users will just download the Dll file we provide, none will compile. Instead they will use the options menu being worked on to turn features on and off at run-time (probably durring game setup). That should be our strategy.

 

[12monkeys]

I agree that these are usefull improvements. Especially the widgets will make several things much easier.

No unitCreated/unitLost event on upgrade/gift. Instead it will trigger new unitReborn event. No more useless CombatOddCalc event. Instead it will trigger beginComat event with more useful infomation arguemnt. New combatHit event for every round of combat with more sane and useful argument and on more useful timing than combatLogHit event.

I just have some concerns about this. I have no problems to add some new events but changing the existing events, will blow several mods. Is there a special reason to remove the old ones? Why not just add the new ones and let the old ones untouched?

 

[12monkeys]

P.S. It is sad that I had to slash time to play Civ4 to spare more free time to write this SDK mod. I worked harder in free time of evening than work time of a day. I am not even a professional programmer myself!

Hehe . I know that. I havn't played one single Civ4 game this year, except some test rounds with WB created scenarios for mod testings. But thats OK. Actually I have more fun to mod it than to play it.

 

[SimCutie]

I agree that these are usefull improvements. Especially the widgets will make several things much easier.


I just have some concerns about this. I have no problems to add some new events but changing the existing events, will blow several mods. Is there a special reason to remove the old ones? Why not just add the new ones and let the old ones untouched?

Don't worry.. It has runtime flag to enable/disable this. If you set a flag, then it will behave in old way.
Why do I change old unitCreat/unitLost? Because it will make these events more useful. In old way, you have to check whether it is real unit creation/lost event or upgrade/gift before doing something when a unit is really created brand-new or genuine unit destruction.
And checking this in Python turns out to be quite complex and somewhat uncertain. And wores, you can not determine it right away. So real action should be delayed until it is determined. With this change of event behavior, you can skip checking for upgrade/gift and assure that it is real unit creation/destruction on that very moment, pure and simple.
The current timing of CombatLogCalc event is kind of *BUG*, I think.
It should have triggered when player pressed Alt button before combat. The Original behavior and code in CvUtils is extactley for that timing. (Another evidence: Displaying combat odd didn't worked in original release. But fixed in later update. I think that the wrong timing of the event is cause of original bug) Currently, it is triggered when a combat begins and its argument is not useful for using as begin combat event. I removed it as a bug-fix.
CombatLogHit event is not removed or changed . I added new event CombatHit on better timing (before actually killing/damaging unit) and with more sane arguments..

 

[12monkeys]

Don't worry.. It has runtime flag to enable/disable this. If you set a flag, then it will behave in old way.

Why do I change old unitCreat/unitLost? Because it will make these events more useful. In old way, you have to check whether it is real unit creation/lost event or upgrade/gift before doing something when a unit is really created brand-new or genuine unit destruction.

OK, I understand.

And checking this in Python turns out to be quite complex and somewhat uncertain. And wores, you can not determine it right away. So real action should be delayed until it is determined. With this change of event behavior, you can skip checking for upgrade/gift and assure that it is real unit creation/destruction on that very moment, pure and simple.
The current timing of CombatLogCalc event is kind of *BUG*, I think.
It should have triggered when player pressed Alt button before combat. The Original behavior and code in CvUtils is extactley for that timing. (Another evidence: Displaying combat odd didn't worked in original release. But fixed in later update. I think that the wrong timing of the event is cause of original bug) Currently, it is triggered when a combat begins and its argument is not useful for using as begin combat event. I removed it as a bug-fix.
CombatLogHit event is not removed or changed . I added new event CombatHit on better timing (before actually killing/damaging unit) and with more sane arguments..

Mmmh. I may wrong, but as I know, all those events in CvEventManager.py can't be used to change something in the gameflow. Its just a message that it will or already has happened.
As you surly knows there is a nother kind of "events" (I called it "pre events") in CvGameUtils.py? Those functions can be executed "before" something happens and they are sequential embedded in the program flow. According to your return parameter (usually a bool) you can decide if you like to make it happen or not. I already added some of those functions in my current SDK work. Maybe such "pre events" are useful for you as well and would round up your changes in the combat messaging.

 

[SimCutie]

Mmmh. I may wrong, but as I know, all those events in CvEventManager.py can't be used to change something in the gameflow. Its just a message that it will or already has happened.
As you surly knows there is a nother kind of "events" (I called it "pre events") in CvGameUtils.py? Those functions can be executed "before" something happens and they are sequential embedded in the program flow. According to your return parameter (usually a bool) you can decide if you like to make it happen or not. I already added some of those functions in my current SDK work. Maybe such "pre events" are useful for you as well and would round up your changes in the combat messaging.

You are right. The purpse of 'combatHit' event is not change execution flow or outcome of the combat. The unit kill() process changes many internal state of the unit class unrecoverablely (like X,Y position), So it better to know that the unit is going to die in combat right now than getting postmortem information that it died already.
Of course, you can change the program flow by refilling hit point of unit defeated-and-about-to-die. You can make a unit which rise from the death or with 9 lives in this way.. In postmortem 'unitKilled' event, you have to restore old states of the killed corpse.