1) DA supports a tag for picking the special environment types in CustomPlanets.xml: </PlanetType>. Just add that tag to the planet definition, and give it a value from the following list:

HabitableByAll
HeavyGravity
Aquatic
Toxic
Barren
Radioactive

That will make the planet the type you specified. But I believe that homeworlds themselves will ignore any planettype tags (you can set it on other planets in the home system, though).


2) I'd expect that'd require one to change the UV mapping in the ring model, but I can seem to find any model in the game that would be used for rings. Making that a dev question which'll have to wait until another day (they all seem to have taken the day off).

3) What exactly do you mean here?

4) AFAIK the game forcibly makes any home system have five planets, so any situation varying from that is likely a bug anyway.

5) Photoshop and PaintShop Pro work with 384x192, greyscale, interleaved/RGB, 0 header length. What are you using now?

6) Putting the added entries into a file in modname/data/customplanets *should* append them to whatever is in the core file when the mod is loaded, unless there's some issue preventing this behavior with that file.

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

Follow-up to the reply...

1) Ahhhh... exactly what i needed to hear, mind you the Aquatoid race WILL now officially receive it's fair share of Aquatic planets nearby and/or restricted. Which reminds me of Toxic access to other(s) !

2) I'll wait. At first though i thought my GCard was the culprit since ship Textures aren't available with it. By extension, i figured the 32x32 mapping failed to stick as drawn or wouldn't develop as expected. Still, it could be visually stunning to make good use of the potential.

3) The customracexml file has a line with Homestar... which isn't really updated when the player defines it's homeplanet in the custom screen setup. Going out to the customplanets.xml file, one can actually re-write the Homestar name - but this doesn't get taken into account until a whole new session is started. Thus, the confusion of having to tie both source of "names" together with manual xml editing rather than an indirect link via code (intuitive detection, if you like).

4) Yup, maybe a bug. Strange though. Cuz, i swear, the Thunderbirds DIDN't get their fifth planet (John/Earth/Five circling above as a "pseudo-moon") as defined in the customplanetsxml while i was playing with a Tiny test map.

5) Interleaved/RGB? That's it then - Thanks. I mostly use a VERY old version of PSpro at times, Gimp & some "home-made" patchy stuff i'm more comfortable with. I'm from the good'ol Dos-generation(!).

6) That's what i thought also - makes the issue clearer.

7) 24b vs 8b textures for planets? Any comment?

Thanks again, Kryo.

- Zyxpsilon.

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.

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.

Sorry for the double-post!

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.

The kind of automatic segmentation you're looking for isn't really possible. Probably the easiest thing to do would be to just make the three separate mods in one zip.

As to the file layout itself, you'd be better off doing all the races in each group in a raceconfig.xml file rather than as individual customrace files (which aren't really the intended distribution method for entire mods anyway). All the related graphics for them can go in the appropriate parts of the mod folder that way as well.

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.

Hey Zyxpsilon you from Michigan ??? There only one Kalamazoo!!!

Nasty

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

Nope, From Quebec - in the "great" white North... which doesn't make me any less interested in Chattanooga trains, Kalamazoo dungeons or even Abracadabra caverns!

- Zyxpsilon.

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

Another thingy please, Kryo?

I'm somehow stuck in mud about the rings "proportional data & values".

The cariElf (old Guide) hints on a couple of data standards, but i have yet to entirely understand the process itself, somehow.
Quoting her straight from the related section...



What i really don't get is the underlined part above. Is it 1.5 TO 5? Or compounded FROM/BETWEEN distance based on relative fractions made up of min/max modulo formulas?

Knowing the planet size(s) remain as constant values (at galaxy creation time), it seems like these initialized parameters get "altered" under different conditions. Rare planets or Stars numbers/grids, even going from a small to medium map size resets the Rings appearance in some lengths so that these might actually squeeze right into the planets themselves or disappear altogether, not counting overlay partly or entirely on the cue-cyan-circle-select-cursors (but that would have to do with the choices made)!

Inner & Outer radius can always be fiddled with. Distance of "mid-start" position from planet are variable enough that a fixed rendering shows the intended calibration.

I was just about ready to make a kind of illustration to show what i meant, clearly. But i guess, you could deduct the main argument from the small statements above.

Trying some ASCII tag line for a fictional space slice;

Ring starts~ /c/------A------/b/......../Planet/......../B/----a-----/C/ ~Ring ends.

(Aa) is the center location value which is proportional to the planet size percentage based on star volume (which are all constantly the same, it seems)
(Bb) is the Inner-radius value assumed from a variable number (taken from the xmls)
(Cc) Outer.

Now, presuming the default 32x32 textures(alpha) UV mappout function (after the usual Flipping Left/to/Right) spreads evenly on any typical ring sizes... shouldn't the final graphics proportions STAY similar or exactly proportional from say, a game played on a tiny map to a new Large one in another session?

Hope i made myself clear enough, but if you need precisions do not hesitate to ask or comment.

Thing is, maybe the above code behavior is absolutely normal occurance. Still it boggles the heck outa my mind, so far.

Lemme know, asap - as i'm currently making the finalized set of planets (some 39+ Major races' Homeworlds along with two or three local system dependant unique planets, is no small task!) for X-Worlds and i'd like them to be as much fair and real to both code-processes and visually exact to my intentions. Besides, Research or Production bonuses for any planets DO have an impact, AFAIC.

- Zyxpsilon.