WoC Suggestion Thread - NOT Specific Modules

[TAfirehawk]

Speaking for the graphics, that is correct, but to me this doesn't matter much (at all actually).

To me the modular concept refers to xml and xml only. You could still keep the xml separate and plug / unplug it, the graphics simply remain in the FPK and won't get used if the corresponding xml is unplugged.

Instead of having Modules/<some-dir>/<yet-a-dir>/Art, why not go with Art/<somedir>/<yet-a-dir> ? That way you could put all art in an FPK with the module still remaining pluggable.

Yes, the space used up by graphics of deleted modules would still be used, but I do not consider this much of an issue and a worthwhile tradeoff for the gained loading speed.

That is impossible because individual modules or small groups of modules will be separate downloads from the WoC Core and from themselves. To do what you want would require many, many extra MB's/GB's worth of downloads for every single person.....

BTW, the modular concept does NOT apply to just XML but the entire Civ game and every piece and part....just Firaxis doesn't allow everything yet, but they will eventually.

 

[NikNaks]

If you didn't know, mamba, Zebra 9 is working on a Python modular system, so it's all coming together

 

[FlashAron]

Hi there,

are you planning to include some World Maps with starting Positions and all resources ? Would be nice !

THX

 

[TAfirehawk]

Hi there,

are you planning to include some World Maps with starting Positions and all resources ? Would be nice !

THX

We have one already in.....Giant Earth Map.

We are doing our best to provide examples of everything that can be modded....our goal is NOT to do every mod but help all other modders adapt to the WoC Standard.

 

[mamba]

If you didn't know, mamba, Zebra 9 is working on a Python modular system, so it's all coming together

I read that a while ago, but I still have trouble even understanding how he wants to achieve that (but then I do not know Python)

 

[mamba]

That is impossible because individual modules or small groups of modules will be separate downloads from the WoC Core and from themselves. To do what you want would require many, many extra MB's/GB's worth of downloads for every single person.....

Yes, that would be the logical conclusion of it, but then I also think that providing a large collection of units in a unified location as FPKs (for all modders to use) is preferable to the alternatives.
You could still have different FPKs based on some criteria (e.g. one for WW1 units another for WW2 units), but having a unified location and one common FPK is an advantage in my book, not a disadvantage.

To me there are basically only two alternatives to this.

Alternative 1 : all mods do still come with their own FPKs, which include 95% of the same units as the other mods. So everyone still has 5 versions of the same unit on the HD (but at least the loading time is still ok).

Alternative 2 : all mods come with their own units not stored in FPKs but following your convention, increasing the loading time by 5-10 times and with a little luck (*) actually storing them in the same path as the other mods do (thereby reducing / preventing the duplication of identical units).

(*) while you provide a path, there is no naming convention for the unit directories themselves, so one could call them Archer_England, the next EnglishArcher, the third England/Archer and so on

About the only case where this is preferable is for a user who only wants a handful of new units and 2 new civs, for anyone wanting to plug in a large mod like Varietas Delectat, Wolfshanze Mod, Diversica etc., having FPKs is far preferable imo.

And given todays internet connection and HD sizes, downloading somewhere between 200 and 500 MB of FPKs does not even require a second thought.

To me the only questions here would be, what is a sensible structure within the FPK, what criteria to use to separate the different FPKs (and what units to put in each) and who creates them

 

[TAfirehawk]

mamba,

My current thoughts are to divide up the FPK's in Unit Categories as we have defined from Firaxis and is the folder structure we are using.

FPK's will be a refinement we will look at after v1.00

Trust me, nobody knows the usefulness of FPK's better than I do....just look at the super-sized ViSa expansion pack we did for Warlords, 958MB.

 

[mamba]

Fine by me, I'd probably go with Art/Custom/ and then the Firaxis dir structure, i.e.

Interface/Buttons/Buildings
Interface/Buttons/TechTree
(and maybe add some like Resources or Leaderheads)

Leaderheads/<leader>

Terrain/Resources/<resource>

Units/<unit-package?>/<unit-subpackage?>/<unit>

with the structure within units probably needing the most though, so they can be broken into separate FPKs. Probably by era or type (Naval, Air, Armored, like you did with "Custom Units").


imo there also should be some naming conventions established to make mixing of mods easier.

E.g. all civ-specific unit art styles should be named like the civ, e.g. UNIT_ARTSTYLE_ENGLAND (to allow mixing units from several mods easily, if one mod would call the english artstyle UNIT_ARTSTYLE_ENGLISH instead, this would not work without changing xml yet again)

and probably some others to allow for an easier mixing and matching of stuff from several mods.


For my mod I also separated "Custom Units" from "Custom UnitArtstyles" (in your example you placed both xml files in "Custom Units").

I did so as there are several units used by multiple civs and some units which only have a *CIV4UnitArtStyleTypeInfos.xml file but no corresponding *CIV4ArtDefines_Unit.xml file as they are defined by CIV (for a scenario) already.

I also found this cleaner than to place all the *CIV4UnitArtStyleTypeInfos.xml files for the different civs in the "Custom Units" dir, as now I have one place to look up what units get used by a civ instead of having that info spread all over the place (it is still one file per unit though).

I am not sure whether this is actually preferable or whether to be correct here, one should create separate units for the seperate civs, even though they use the same art. The later would allow for easier adding / removing of units as it still can be done per dir whereas the split into unit and unitartstyle would require changes in two places. But from what I understand you want to provide some way of specifying such dependencies and then this might no longer be an issue (looking forward to that).


I also noted that you did not break down some mods further, e.g. in Inquisition, you have many units (one per religion) instead of splitting them into separate Custom Units. Is this because you cannot yet define dependencies, or will this always remain like that ?

I am wondering whether I should split some stuff up even further, e.g. my modular version of the NextWar mod is currently one directory, but it could be 10 techs, 5 buildings and 7 unitclasses (or something like that) instead.

I would look forward to truly breaking the mod boundaries and having it in the latter form (instead of having either all or none of NextWar in the game), but then we would need some way of telling the system what dependencies there are, so you do not accidently remove all units for a tech (or the tech for units you still keep around) etc.

So I guess for the time being it should remain one dir. What is your take on this ?

 

[TAfirehawk]

mamba,

The "Arts" are to use the exact same folder structure as Firaxis, just within the Modules folder....we have modified the code to allow relative art paths so bringing a mod into the WoC won't require changing all the paths in the XML. Of course this hurts the FPK concept but in the end that will probably need to be addressed with Firaxis once they "get on board" with a truly modular system.

We have a separate Art Style folder....if some units are not in there it is just that we haven't gotten to them yet.

Inquisition is a mod by itself and thus has the units within it....you don't play with just one Inquisitor and not the others and you don't get all the Inquisitors without the rest of the module. There really is a reason for everything we have put in place....but I will be the first to admit that we haven't covered all the bases yet and that is why dialog with all modders like yourself will turn the WoC Standard into something Firaxis can adopt relatively quickly.

Breaking up mods is a core concept and one of the most difficult to implement. The basic idea is that if a unit/building/etc can be used stand-alone then it needs broke out into the Custom Unit/Building/etc folder. The Inquisition is a perfect example of units that must remain with the mod....the Navy mod was broken up because those units are not dependent on other Navy mod code.

At the same time, dependencies are a real nightmare right now because we are turning all modules on/off manually. But once we have the WoC Module Chooser (aka front end program) that will have an XML checker and at least warn the player of dependencies if not automatically select the needed dependencies. For now we have been modifying the SDK so the game doesn't CTD with missing dependencies....so the game won't play quite right but it won't crash either, which is the best we can do until v2.00

 

[mamba]

The "Arts" are to use the exact same folder structure as Firaxis, just within the Modules folder....we have modified the code to allow relative art paths so bringing a mod into the WoC won't require changing all the paths in the XML. Of course this hurts the FPK concept but in the end that will probably need to be addressed with Firaxis once they "get on board" with a truly modular system.

I don't see why we shouldn't be able to have a solution now which supports FPKs. What is wrong with putting art in Art/Custom and then the Firaxis structure ? Sure, the art will stay around even when the mod is unplugged, but hey, I much prefer that over not being able to have an FPK

So I will definitely go that route with my mod.

How are your talks with Firaxis about them "getting on board" progressing ? Will they incorporate WoC in the next (or a latter) patch ? are they at least sufficiently interested to see how this turns out ?

Inquisition is a mod by itself and thus has the units within it....you don't play with just one Inquisitor and not the others and you don't get all the Inquisitors without the rest of the module.

True, however if I were to add another religion, I would need an inquisitor for that religion as well. So while it is true that I do not want less inquisitors than provided by the Inquisition mod, I might actually be in need of more inquisitors.

Where would I then put that inquisitor, in the Inquisition mod or as a Custom Unit ? Apparently the former as he requires the mod to function properly.

Breaking up mods is a core concept and one of the most difficult to implement.

Very true

The basic idea is that if a unit/building/etc can be used stand-alone then it needs broke out into the Custom Unit/Building/etc folder. The Inquisition is a perfect example of units that must remain with the mod....the Navy mod was broken up because those units are not dependent on other Navy mod code.

What if a unit is dependent on a new tech I introduced ? Do I place it with the tech then ?

At the same time, dependencies are a real nightmare right now because we are turning all modules on/off manually. But once we have the WoC Module Chooser (aka front end program) that will have an XML checker and at least warn the player of dependencies if not automatically select the needed dependencies.

How will it check for dependencies ? does it traverse the xml to check if everything required is actually found (and probably also the unplugged modules to find the missing ones if something is missing) or do we provide some dependency info for the checker to verify against ?

What about some 'soft' dependencies, e.g. we probably will need to shuffle some techs around (x and y grid) when introducing new techs, so they are not placed on top of each other, esp. with several modders all introducing new techs and putting them in the same blank spots. Could something like this actually be checked (well of course it could, but would it) ?

Actually I believe the only way to arrive at a truly pluggable tech tree is to simply ignore the x and y grid outright and create a graph based on the requirements of each tech. Are you trying to do something along those lines ?

For now we have been modifying the SDK so the game doesn't CTD with missing dependencies....so the game won't play quite right but it won't crash either, which is the best we can do until v2.00

That is already pretty good, provided it tells me about what it missed so we can fix those errors.

 

[rockinroger]

We have a Zoroarastrian Inquisitor and Missionary that is in the library/custom units/special and the buildings for the religion are in library/custom buildings. Right now working on getting the Religion found nif and the Shrine_Zoro_dwg_512.dds, to work correctly. That part has been frustrating for sure.

 

[FlashAron]

Hi there,

sorry to ask, but I couldn't find the "Giant Earth Map" for WoC ... and also "Ghenghis the maker of the map" didn't know anything. Even I got Version 4.1 of the original Giant Earth Map working, of course there are not the extra resources included ... is it still not released ?
Or where could I download it ?

(Of course I could start World Builder after I have started the game and put them in, but how many and where ? )

How is the status at the moment ?

Thank you

 

[TAfirehawk]

Hi there,

sorry to ask, but I couldn't find the "Giant Earth Map" for WoC ... and also "Ghenghis the maker of the map" didn't know anything. Even I got Version 4.1 of the original Giant Earth Map working, of course there are not the extra resources included ... is it still not released ?
Or where could I download it ?

(Of course I could start World Builder after I have started the game and put them in, but how many and where ? )

How is the status at the moment ?

Thank you

It is on the SVN.....not v.90

V.95 will be out next week hopefully

 

[FlashAron]

It is on the SVN.....not v.90

V.95 will be out next week hopefully

Thank you for your answer, I am using SVN and found it now in the Modules directory ... how could I activate it, as I couldnt find it in the maps, scenarios and so on (of course after loading the Woc Mod

Where do I activate all the modules ?
Do I have to change that file ?
MLF_CIV4ModularLoadingControls.xml

Anyway, thank you for all your work !

Hmmm ... it is even there

<Module>
<Directory>Custom Maps</Directory>
<bLoad>1</bLoad>
</Module>

Where should it normal show up ?
THX

 

[TAfirehawk]

It is the last scenario on the list....I don't know why the proper name doesn't show yet....

Everything in the Modules folder loads....everything not in there does not

 

[TAfirehawk]

mamba,

Load time for BtS is 15 seconds and the current WoC Modules is 32 seconds. Of course I have a pretty fast system so others will take longer....but I will also go test it on my slower P4 laptop to be sure.

The FPK issue will be addressed when needed....hopefully people will start using the WoC Modules SVN so I will have plenty of things to 'stress test' the loading with

 

[modusoperandi]

Is it possible to modify spies so that they can steal resources? Say, for example, a neighboring civ has oil and you don't; position a spy on their oil, spend a pile of espionage points, and you then have access to that resource for a certain number of turns.

Emperor Justinian had monks smuggle silk worms from central Asia to Constantinople. Consequently, the Byzantines were able to produce silk on their own and no longer relied on foreign trade to acquire it. Is there a way to incorporate this concept into WoC? Say you steal a resource (that requires a plantation) so many times, or have a spy physically "steal" a sample and return it to your capital (with increased risk of being caught), and as a reward you earn permanent access to the resource?

Just some ideas.

 

[lord_graywolfe]

i was looking at Dales new combat mod and it looks really cool and sounds like it would be a great addition to any mod but if i read it right he did most of his changes in the DLL. now doesnt that make it pretty hard to add into other mods as it will overwrite the exsisting Dll which may contain other nessery files for the mod such as Bluemarble. i mean his will work great in the exsisting modular system but can it work with WoC modular loading? im just curious as i dont know much beyond the XML coding.

another question would it be possible to put some of the new ideas into the game full time and then just have the option on a menu to turn them off or on so people arent picking through mods trying to find what they are looking for? i know that will result in a much larger file size but its just a thought

 

[mamba]

i was looking at Dales new combat mod and it looks really cool and sounds like it would be a great addition to any mod but if i read it right he did most of his changes in the DLL. now doesnt that make it pretty hard to add into other mods as it will overwrite the exsisting Dll which may contain other nessery files for the mod such as Bluemarble. i mean his will work great in the exsisting modular system but can it work with WoC modular loading? im just curious as i dont know much beyond the XML coding.

Blue Marble doesn't require any dll changes, so it will work with Blue Marble without problems. WoC otoh does require a different dll, so if you use WoC formatted xml you cannot replace the WoC dll with Dale's dll.

Dale's code could be combined with the WoC code (and I sure hope it will be) to have a dll which supports both the WoC format and Dale's changes.

 

[lord_graywolfe]

ok thats cool, thats why i asked cause i didnt know how that would work.

i do have another question though, may not be the right place for it but anyway

im reworking my mod to make it work with WoC, now i changed all the leaders to 3 traits and in some cases it wasnt just adding a third trait i changed thier old ones as well, but when i make them do i need to make a new file for each of the leaders? or do i just make a file with the trait changes? if its the later im not sure how i would do that.