[MODCOMP] - XML Cleanup & Expansion

[MagisterCultuum]

So I don't have to wait for 0.33 after all? I guess it is a good thing then that I haven't really started my modmod yet (apart from playing around with changes in my version of FF 041c)

Edit: it would be a lot more useful if you included schema files

 

[xienwolf]

Well, you'd have to write your own schema and python, but those parts are easy to do.

 

[MagisterCultuum]

Sure, the python should be easy, but my attempts at schema changes have never worked before (granted, the problem was probably in the SDK reading the schema). It seems like if you tested it to know that it is functional that you must already have the schema files on your computer that it would be easier for you to just upload them. (A single example of a unit/promotion/etc with full fields could be useful too.)

 

[xienwolf]

Well, between these attached files and 41D you should be set, ought to be able to piece together what was changed, and I doubt that I did much outside of these files which would be required.

 

[MagisterCultuum]

I've compiled the DLL and used FF041D + Junk.zip, and now have it so that it loads without errors. However, some things aren't quite right.

The first mistake I've noticed after getting it to load properly is that the game options you added are all missing. I know they are in the xml and are set to be visible, but they do not show up in the custom game screen. Did you accidentally leave these out of the FF source files? I compiled them exactly as you had them (adding you files over the normal FfH SDK files and compiling according to Kael's guide) without modifying any of them (although I was considering making some changes once I had it working).

Also, using your CvMainInterface.py (either the version from Junk.zip or one where I tried to make the mana bar be a single column) the interface appears entirely hot pink. If I leave it out then the interface shows up, but without the mana bar. (Hmm...I haven't looked into copying any art files yet. Could this be related to the religious HUDs missing their graphics? Of course, the option doesn't seem to be present and this on the first turn, before adopting a religion.)


Also, when I try adding the .ini files FF uses for FFHBUG, the interface doesn't show up at all.


Edit: Ok, I went back and found all the HUD graphics files from Fall Further and added them in, and added FF's CIV4ArtDefines_Interface.xml too. As you can see, this seems to have made The Order's city screen interface become the main interface at the beginning of this Luchuirp game. That's not really right either. I'm thinking some of the changes I omitted because I thought they were tied to the civ specific city/improvement graphics (most of which I dislike) may have actually dealt with the interface.

I think I'll wait and try to fix this after I get some sleep.

 

[Grey Fox]

Looks like the graphics files are in the wrong place.

 

[xienwolf]

That is opague, so you are seeing ALL of the interfaces; Order and Empyrean just happen to be on top, which is proper from the load order anyhow. Loads from evil to good. And you are showing full city overlay when not in city zoom. Thus the problem is pretty obvious.


Your issue is that you are not hiding any of the interface pieces after they are generated. Probably not ever I'd imagine. So all of those ___.hide(___) lines need to be put back into CvMainInterface If you want to remove screens you need to remove lines which state addDDSGFC(___).


As for how to get options to not show up, but be marked as Visible in the XML, you got me there. Never tried adding any to the XML without adding them to the DLL, so it could be that they are missing from the DLL files, seems to be the most reasonable explanation. That would mean you must have missed a couple of files when overwriting Kael's base source though, as only missing 1 would have caused errors while compiling. I believe changes to the Gameoptions require 3 files minimum.... Other changes are made in each of those files as well though, so nothing ought to have worked if those didn't.

 

[MagisterCultuum]

Well, I'm using exactly the CvMainInterface.py that you provided.


I've searched through the source files I compiled and the game options were definitely there. I compiled it over again, and then I noticed that the created date of the DLL had not changed. I just checked, and it is the same size as the normal FfH dll, smaller than the FF041 although it should contain more stuff. I'm guessing that it never did compile correctly, and I've just been using the normal FfH DLL. (I'm kinda surprised it even loaded. I guess it only checks to see if it matches the schema, not the DLL. I haven't played many turns (for obvious reasons), or else I probably would have noticed the lack of functionality.) I've cleaned and rebuilt the project a few more times, and it is clearly making new object files but has not made an actual DLL yet, despite having no errors. I'm not sure why it isn't compiling correctly, since I'm following Kael's guide closely and have successfully compiled DLLs before.


I'm thinking the Interface problem may be because all your ___.hide(_______) lines are within if statements referencing game options that don't exist in the DLL.

 

[xienwolf]

Yeah, using the wrong DLL means that some things aren't exposed to Python which ought to be, to include new WidgetTypes, so there is no telling HOW it would break Python to be honest.


Check where your Build Target is set for in Codeblocks. Most likely you are creating the file, but in a completely different location than you think you are.

 

[MagisterCultuum]

The Build Target is definitely Final Release. All of the object files are being created in the Desktop\CvGameCoreDLL.032MagisterII\Final Release folder, it just doesn't get around to making the actual .dll. I'm pretty sure those were always placed in the same folder in my previous, successful compilation attempts.

 

[xienwolf]

Well, delete your Final Release folder, re-compile, and see what pops out.

 

[MagisterCultuum]

I just tried, and it ended up recreating the folder with the object files, but no .dll

Project : CvGameCoreDLL
Compiler : Microsoft Visual C++ Toolkit 2003 (called directly)
Directory : C:\Documents and Settings\Jon-Michael Ivey\Desktop\CvGameCoreDLL.032MagisterII\
--------------------------------------------------------------------------------
Switching to target: Final Release
CvArea.cpp
CvArtFileMgr.cpp
CvCity.cpp
CvCityAI.cpp
CvDLLButtonPopup.cpp
CvDLLEntity.cpp
CvDLLPython.cpp
CvDLLWidgetData.cpp
CvDeal.cpp
CvDiploParameters.cpp
CvFractal.cpp
CvGame.cpp
CvGameAI.cpp
CvGameCoreDLL.cpp
CvGameCoreUtils.cpp
CvGameInterface.cpp
CvGameTextMgr.cpp
CvGlobals.cpp
CvHallOfFameInfo.cpp
CvInfoWater.cpp
CvInfos.cpp
CvInitCore.cpp
CvMap.cpp
CvMapGenerator.cpp
CvPlayer.cpp
CvPlayerAI.cpp
CvPlot.cpp
CvPlotGroup.cpp
CvPopupInfo.cpp
CvPopupReturn.cpp
CvRandom.cpp
CvReplayInfo.cpp
CvReplayMessage.cpp
CvSelectionGroup.cpp
CvSelectionGroupAI.cpp
CvStructs.cpp
CvTalkingHeadMessage.cpp
CvTeam.cpp
CvTeamAI.cpp
CvUnit.cpp
CvUnitAI.cpp
CvXMLLoadUtility.cpp
CvXMLLoadUtilityGet.cpp
CvXMLLoadUtilityInit.cpp
CvXMLLoadUtilitySet.cpp
CyArea.cpp
CyAreaInterface.cpp
CyArgsList.cpp
CyArtFileMgr.cpp
CyArtFileMgrInterface.cpp
CyCity.cpp
CyCityInterface1.cpp
CyDeal.cpp
CyEnumsInterface.cpp
CyGame.cpp
CyGameCoreUtils.cpp
CyGameCoreUtilsInterface.cpp
CyGameInterface.cpp
CyGameTextMgr.cpp
CyGameTextMgrInterface.cpp
CyGlobalContext.cpp
CyGlobalContextInterface1.cpp
CyGlobalContextInterface2.cpp
CyGlobalContextInterface3.cpp
CyGlobalContextInterface4.cpp
CyHallOfFameInfo.cpp
CyHallOfFameInterface.cpp
CyInfoInterface1.cpp
CyInfoInterface2.cpp
CyInfoInterface3.cpp
CyMap.cpp
CyMapGenerator.cpp
CyMapGeneratorInterface.cpp
CyMapInterface.cpp
CyPlayer.cpp
CyPlayerInterface1.cpp
CyPlayerInterface2.cpp
CyPlot.cpp
CyPlotInterface1.cpp
CyRandomInterface.cpp
CyReplayInfo.cpp
CySelectionGroup.cpp
CySelectionGroupInterface.cpp
CyStructsInterface1.cpp
CyTeam.cpp
CyTeamInterface.cpp
CyUnit.cpp
CyUnitInterface1.cpp
FAssert.cpp
FDialogTemplate.cpp
_precompile.cpp
Linking dynamic library: ..\Beyond the Sword\Assets\CvGameCoreDLL.dll
Creating library ..\Beyond the Sword\Assets\CvGameCoreDLL.lib and object ..\Beyond the Sword\Assets\CvGameCoreDLL.exp
Process terminated with status 0 (19 minutes, 37 seconds)
0 errors, 0 warnings

 

[xienwolf]

Look at the 4th line from the bottom. Your final target is \Beyond the Sword\Assets\CvGameCoreDLL.dll, and that is where the new DLL finds itself placed.

I would advise you don't try to play non FfH BtS anytime soon

 

[MagisterCultuum]

I don't think that is the case. Looking at the Beyond the Sword's asset's file I find what appears to be the normal BtS 3.17 patch version of the DLL, which was created a little over 2 months ago and is smaller than the normal FfH DLL.

I decided to do the exact opposite as you advised, and found BtS runs fine (at least for the first dozen turns or so. It's too boring to play longer than that.)

I don't think those lines have to do with where the files are actually created. In fact, I'm pretty sure I remember it being just like that every time I've ever gotten a DLL to compile correctly. (Maybe you'd want to check that by compiling it yourself? ....and then maybe uploading it?)

 

[xienwolf]

I did check by compiling my own copy, and it states the Final Release directory for the output source on that line. Check your CustomAssets folders maybe? Since we do not see anything before the Beyond the Sword folder it is possible it is anywhere on your computer in reality. Though how it would be targeted into a random place is slightly beyond me. You could also do a search on your entire harddrive for CvGameCoreDLL.dll filename which has been changed within the last 48 hours.

 

[MagisterCultuum]

The hard drive search was a good idea, which frankly I should have thought of before. I just found that it had created a \Beyond the Sword\Assets folder on my desktop, containing CvGameCoreDLL.dll, .exp, .lib, and .pbd, all dated to 4:04 pm yesterday. I'd looked on my desktop before, but I guess I didn't look closely enough at the first column, where I guess it went because I'd recently deleted some stuff. It also found 2 DLLs in modcomps I'd recently downloaded and was thinking of merging with my modmod, but having the mod name in their folder name made it clear that they are not what I wanted. A file size of 6.64 MB looks about right too.


I started a game, and it is working just fine so far. Well, mostly fine, but I do need to go back and add the graphics for the UnitStats button and the Armageddon counter, as well as a lot of textkeys. The .ini files probably need to go back too.

 

[Vehem]

A file size of 6.64 MB looks about right too.

It's a little large, but from the looks of it you just aren't doing the full optimization. The linker normally discards the extra references, which normally throws out a warning such as;

Linking dynamic library: Final Release\CvGameCoreDLL.dll
   Creating library Final Release\CvGameCoreDLL.lib and object Final Release\CvGameCoreDLL.exp
LINK : warning LNK4089: all references to 'KERNEL32.dll' discarded by /OPT:REF
Process terminated with status 0 (1 minutes, 3 seconds)
0 errors, 1 warnings

In this case - the DLL is accessed by the game .exe and doesn't need the references to Kernel32.dll anyway, so dropping them just reduces the filesize to slightly over 5MB.

Shouldn't have any effect though so nothing to worry about. The steps Kael posted for setting up Codeblocks should turn that optimization on though.

 

[Tarquelne]

Sorry if this has been requested already (or is present and I didn't see it, come to think of it...):

A req. for Promotion based on the presence of another unit.

With "Autoaquire" and "Mustmaintain" a Paladin, for example, might have a "Death resistance aura" that's automatically given to friendly units it's staked with.

 

[MagisterCultuum]

Sorry if this has been requested already (or is present and I didn't see it, come to think of it...):

A req. for Promotion based on the presence of another unit.

With "Autoaquire" and "Mustmaintain" a Paladin, for example, might have a "Death resistance aura" that's automatically given to friendly units it's staked with.

That sounds like a good idea. There was another modmod that used python t handle that kind of think, but I don't think anyone has suggested it here.

Similarly, it could be good to have a tag for promotions that makes them require that some unit in the stack has a certain promotion.

 

[xienwolf]

Nope, don't have anything like that at the moment. Sounds decent enough for the wishlist

Had crossposted with Magi, but already thought of the promotion one myself. Before anyone shares my other thought, I do NOT plan to extend the range of such prereqs (unit within X tiles, promotion within X tiles...). I'll leave it as on same tile only, and it won't care if the other unit is yours, a teammates, or an invisible unit you are at war with.