Do you have to save a file as .xml for the game to use it as a mod?

3) That's because the in-game customization setting is just to set the homeworld itself, the intention being to simply override the homeworld's name as defined in the system definition--*not* to switch it to a completely different definition. Since you'd have to manually add a new system in customplanets anyway, it doesn't make a lot of sense to not just do the same for the matching entry in raceconfig.

5) How old? I use PSP7 myself, and that works fine (don't much care for what Corel did to it after they bought out JASC).

7) That'd be a dev thing as well. Though if the game bugs out on 8 bit textures then it's probably a safe bet that any difference would require manual coding work.

Following through...

3) Then, it's time for an easy one-step manual editing of the lines in question. Fair enough, i can do that.

5) PSP6 - Works very smooth too. I'd sure enjoy more recent versions (of anything), but can't afford it. But, it's okay.

7) The 8B's showed up as an entire sparkling whites blank... so i figured 24b was an essential format & had to switch right back to the bigger files. Again, i don't mind. But, since there are 42 races (so far!) & 8~12 Minors in X-Worlds and i'd be willing & ready to provide each with a full-range of 5 uniquely designed planets per starting system. (!!)
Just imagine such a folder... 210+ (plus the Minors) files of about 250kbs/ea. = 52,500. Tadaamm - i guess i'm gonna have to find a way to re-use a few here & there, or even possibly resize as needed. Bof, it's alright.


Thanks once more, Kryo.

- Zyxpsilon.

Oh, and one more thing please?

Bare with me on this as i try to explain a complex situation for the X-Worlds triplet of themes.

Creation of all the races must start somewhere and their individual files (*.customracexml) have to be placed and called from a specific folder. So it seem.

I know for a fact that the main caller picks its values while using the properly located assets (Logos, etc) with a few path-relative calls. That's alright, it makes sense. But, what doesn't is this...

It is a MOD and i would rather have everything right INTO the appropriate directories.
APOC, TFTD, UFOD, Three sidekicks/neutrals, Ten (and growing) Minors - Everything.

So, what do you suggest?

Put the GFXs in and alter the many *.customraces.xml lines to read (gfx\race\*.* directly from the mod location) OR instead use the longer version (C:\Documents and Settings\My documents\My games\GC2DarkAvatar\GFX\*.*) while transfering all necessary files accordingly??

Here's where it gets a bit more complicated...

Thematic approach requires 3 different areas which cannot or shouldn't be "simultaneous". I wouldn't want to enforce three whole different mod folders and quick resets at once if that is needed by the users. I'd rather have everything available rapidly and configurable without the much tedious activity of creating multiple opponents from an extensive list (saved into the prefs.ini, that i know) BUT self re-organizing every time a new game starts.

Examples;

Game #1; Human(X-Com) vs 8 Alien races from UFOD and the ninth being SideKick/Interceptors. Played, final score tallied. Quit.

Game #2; Human(Apocalypsion) vs 6 Alien races from APOC and the seventh SideKick/Thunderbirds. Played, lost. Quit.

Game #3; Human(Magnetic) vs 10 Alen races from TFTD and the 12th Sidekick/S-H-A-D-O. Half-played, saved. Quit.

BUT... later on.

Game #4; The mix-match fun begins -- Human(Aquatoid) against ThunderBirds/Magnetic/Apocalypsion/S-H-A-D-O/Sectoid/Anthropod/Snakeman/...

See, the original mod folder (or folders with individual APOC/UFOD/TFTD structure) cannot hold all and any variations possible.

So, the question is - How do i go about providing all races at once while keeping a sort of structured MOD-Folder which can be (somehow) variable as often as needed?

I hope i was clear enough with the above but if you have any supplemental observations or advice, by all means, share the explanations!

Right now, i am zipping the MOD with a process of "workaround" solution(s) which ask for extensive editing of the races' files and a number of copy/paste operations by the users. I'd rather make it a lot easier to install or setup.

- Zyxpsilon.

Kay, that explains a lot of things to me.

Automatic segmentation (proper terminology, in my case indeed) wouldn't be possible in the actual interface. That i understand completely. If ever, the coders could figure a sort of function for the "setup" phase which would allow variable listing(s) of active races, i'd then be the very first person to exploit such a feature.
In the meantime i will certainly follow your excellent advice above and proceed with the three-way MOD folders while sticking the grouped races into a "raceconfig.xml" as an optional version of the MOD.

There's also the possibility to load the whole kalamazoo in one shot with a bunch of *12-IDs* for anyone to pick and choose from right into the MyDocuments\*** location and providing the proper call-lines for the multiple GFXs straight in the *.customracexml(s) files. Not quite an elegant process, but it sure works as is while i am developping the MOD. As i drag the tests gameplay, i find it easier to place races data in one place and the other modified stuff (planets, parties, etc) in the X-Worlds MOD folder.

Finally, if i write the thematic data for each races into a specific raceconfig.xml (for each UFOD/TFTD and APOC) this would mean the default GCs (0-TA through 11-KR) are being replaced by mines, right?
Much easier that way, i agree.

Thanks, once more for your kind help as i truly begin to realize some important design steps and procedures.

- Zyxpsilon.

it's not always a bug. it depends on the map. with a regular one, you're probably right. but with a custom map you can decide on how many planets each system has, so it's possible to have as many (or few) planets in one star system as you want.

-Dsep

OK you win I had to Ask because of Kalamazoo !!!

The ring values are a bit of a mystery even to me, and last I was aware the game largely seemed to ignored them anyway, so I wouldn't lose too much sleep over that.

Yea those darn ring values don't work. Haven't ever worked AFAIK. They're just random, sometimes you'll get rings inside a planet, or half so.

You can do that any time, you just can't define the rings' outer and inner radii, as the variables are ignored.

Maybe it was because you (if) didn't add the new tags to the others, saying 'HabitableByAll'? Random guess.

Gee, gotta try this too, since i also couldn't place a second "extreme" in my custom system(s) while guessing it might have been caused by a code-built normal function. Thanks for the info!

Tactical wise, it is certainly a tricky situation where some indirect (mostly for Toxics or HeavyGrav, since Super-Adapters get two of the other types by default) racing towards researching the proper colonization ability can prove to be quite "fun"... specially when the only remaining 17+PQ on a map IS actually right beside your Homeworlds and becomes a wealthy target for neighbors! I found out that most AI do have the habit of trying to pick available planets inside my systems asap, anyway. Might as well make it harder to many/all/few or simply hand-over the ability (at level 2 or 1, btw) right through some xml editing to the custom race in question.
Lots of possibilities, in fact.

- Zyxpsilon.