Well. it sounds to me, that the major race slots are capped to 13 by code.

Were you able to mod the 13th slot aka custom race? That definately works!

AFAIC, the code itself *must* reserve memory stacks for each active races once runtime routines kick in... then, the actual pool of available ID (at the settings phase) is a built-in range of available slots to deploy 12 Majors, 1 Custom, 8 Minors, etc, up until the maximum (code driven, again) of 36 in total... including the mega-events random races.

Even if you were to add any majors above the default 12 (typed 4 and filling other's reserved IDs), the code still needs to allocate memory for these extra slots which i'm 98% sure has to be done through function calls & declarations; that stuff being absent, the whole UI won't recognize any supplemental items. Considering also the extra AIs algorithms necessary to drive gameplay processing too, presuming the 9 opponents max rule still stands AFTER your list is properly detected, it would most probably take up as much memory as any single default Major slot *per* any new ones.

There might be an indirect way to "modify" the code... if you'd have access to the source;

-- Providing for a selectable screen of more choices (as indicated by your snapshot) that ties each slots with switchable incode definitions. Say, Terran 1a & Terran 1b... toggling upon one or the other.

-- Then a re-parsing routine that resets every code calls to the new race parameters **at runtime**.

-- Increasing the number of active slots for the opponents too since all races can fill such duty also.

-- Rewriting the variable arrays that keep track of *supplemental* stack space, dynamically.

If they HAD to reduce memory trace of the ships' graphics to make room for the new Gigantic map -- it tells me that the 'compatible' stack of available heaps is already somehow tight in the code.

Raising that figure, may just be too complex for the kind of feature you want in.

Besides, you could always use my X-Worlds' trick; simply switch RC.xml files that has as many different races as you wish within the default pool of twelve.

What puzzles me even further about this "need" to have more than the RC races on screen to select from is this; what stops you from using the Custom slot? It switches to another screen where you can always load up many saved "indirect" races!

try "up, up, down, down, left, right, left, right, A, B, A, select, start"

What I was talking about was a system in which you could bypass the raceconfig.xml entirely, and load pre-created opponents from the race customizer into each box one at a time. Of course, if you cannot get to the 2nd screen from the empties, I guess that would not work.

Ya know, i've been thinking a little deeper about this whole "more races to select from the setting screen" since i first read your initial post and replied and here's (Not that far from what Scoutdog is suggesting above in fact!) what i came up with;

- Linking any number of extra races from a 'virtual row of slots' directly to the Custom Race slot itself... the principles would remain the same except that the main dxpack caller stays active while the secondary row pulls its races parameters from the normal process of using the Custom slot functions.

- A bit like "creating" the illusion that a new (custom selection) dxpack is currently being used straight from that specific screen.

- Then, it becomes a simple matter of recalibrating the layouts so that a new sort-of transit screen pops into the UI until you hit the usual *NEXT* to proceed with opponents while skipping or even confirming, the bynow valid & active & selected Custom values.

Short of having an indirect way to alter the default code calls for Custom processing functions, of course.

(PS; a few months ago , i gave this stuff a ride for its money while i was trying to make each Race slots "selectable" and editable by popping in two simple things; Portrait & Logo via a similar process such as what we can do in the customization by clicking LR arrows. Soon i realized, the dxpack wouldn't let me switch over to the cycling code itself but it doesn't mean it can't be done - indirectly by scripting a special routine.)

No, the 'other' scripting code(s), dsep.

I won't go as far as calling it an external patch - but rather, a slight alteration to some tricky areas of any given *source* reference. As everyone knows it's illegal to decompile a packed executable.

@Scoutdog: Yep I think that is what he means.

@Zyx: Sorry to say but if you want to mod a game to be what your needs even if it includes breaking the law, than you have serious problems.

Right, i *was* joking; modding while maintaining compatibility with official stock code is more about finding the tricky hidden stuff and provide indirect gameplay elements which players wouldn't otherwise get unless SD alters its program accordingly.

Neilo's quest for an alternate races selection screen is one more perfect example of the challenges we (modders) all face when we aim for something specific. We must determine principles WITHOUT looking at a source code and try some workaround 'design steps' to succeed or conclude, *IT* can't be done.

How often have i found myself seeking for answers about many code functions, asking SD coders for some help, parsing through hundreds of forum threads, testing gameplays for bazillions of quick verifications, etc.

Yep, that's the beauty in solving these issues -- shoulda seen my big grin a few days ago when i realized the AIs were actually reacting as expected with the numerous 'concepts' introduced in X-Worlds 06-A; enhanced espionage stuff, terraforming complex surfaces, packing up their scouts with extra components on size 20 hulls!

But, it is illegal to decompile copyrights. One can always BE curious if they have the proper skills, though... AFAIC - nobody is going to come here preventing me from using my own PC how i please and for whatever good reasons.

OMG... someone is watching over my shoulder. I mean, com'on, Neilo if there IS one member here who'd want me banned for whatever obscure reason - it's you, right?

You've blocked me from one of your sooooo precious thread about fixing the medals, claiming i was going toooooo off-topic. So be it, i had forgotten. But if you really do want to return the favor by publicly stating i decompile stuff around for my own pleasure and curiosity and, in fact, to determine stuff **WHICH i do not get any answers from official SD source & staff & real coders** -- be my guest.

As to what Brad can do or not with people on this forum, i'd risk a theory;

The open-minded listens carefully and doesn't try to interpret words out of context, the programmer studies the stuff with the tools & skills it has access to, and some people prefer to select their friends from what they know exactly about them and not from third party's opinions.

You'd want 24 Majors to choose from, right?

I had a very swift & obvious solution since early this afternoon.

Sadly, again.

EOF.

(PS; Lemme be absolutely clear about this; i haven't decompiled GC2 but if i really wanted to, i have the means & the perfectly legal & bought professional software to take any C++, packager, compressor codes apart *** FOR PERSONAL USE ONLY ***)

Good enough... problem solved.

Let's get on with our lives and our modding stuff --

The key with supplemental races is not within the RC.xml file but rather HOW the code keeps tab of the Majors at that particular moment of the settings phase. (Hint; the Minors amount in TA is an optional array that gets parsed at the Galaxy setup screen, btw)

A routine reads the RC and only then, deploys each slot sequentially (that's the essential word right there) in a temporary placeholder - in dynamic memory.

Augment that heap to allocate for extra slots and the routine would follow through with Races 0-12, the usual Minors and, while restricting DreadLords & Pirates as it should -- but, looping out TO any declared extras between 30 to 35.

Sadly, it's a recompile of the source after alterations. Unless, somebody else has a different magical way.