As for the sidebar... well, at the moment a game is loaded, I call a
sidebarclass_reset function. This function is a copy of the
SidebarClass::One_Time(void) function.
Somewhere at the start of this function, it calls
PowerClass::One_Time(void). Since this also contains sidebar positioning, I also made a copy of that, called
powerclass_reset.
At the start of that, the
RadarClass::One_Time(void) function is called. Since this contains the correct positioning of the radar graphics, I also copied that, to
radarclass_reset.
Now, this one also calls
DisplayClass::One_Time(void). At this point, though, the cloning stops. The Displayclass init no longer contains sidebar position formatting, so I simply removed it from my copy of the radarclass init.
Looking further in
RadarClass::One_Time(void), you also see it loading the sidebar graphics (in C&C95 anyway). All of that code is removed as well, since it's already loaded. Only the positioning code is kept; the rest is all stripped away.
Similarly, the end of
SidebarClass::One_Time(void) (again, just talking about C&C95) contains the
SidebarClass::StripClass::One_Time(int) function calls, and the loading of the actual sidebar graphics. Unless you got code for expanding the sidebars to full height, this init function should also not be cloned. The graphics loading should be skipped anyway, since the original game init undoubtedly already loaded that.
That's about it, really. Hyper identified these functions for me, making it easy to see what to clone and what to leave. Anything related to graphics loading should be kicked out of your copy, though. No need to reload already-loaded graphics.
------------
As for remap... well, as you may know, SHP files contain no colours. The game contains entire remap tables of 255 bytes, that simply, well, re-order the palette. For example, if C&C would be 16-colour, and the remap table would be
5,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F
and then a SHP file is loaded, the game goes over all indexes in that SHP information, and corresponds them with the value in the remap table. Any 0 that's found is replaced by the value in index 0 in the remap table, namely, 5, any 1 is replaced by the value on index 1 (which is still 1), and so on. This specific remap table only remaps colour #0 to colour #5.
Since C&C is 256-colour, these tables are 256 bytes long, but the principle remains the same. In reality, though, you'll see these remap tables normally just go from 0 to 255, with only a small range inside that whole block actually changed.
Here are these tables in C&C95:
http://nyerguds.arsa...cnc95_remap.pngAs you see, the B0 to BF range is the only thing actually touched. The rest is kept as it is.
That's the basic system. Now, in RA, all of that information is saved in
the upper left corner of the palette.cps file. The first line is not only some side's actual remap colour, but also the remap source; which range in that 256-byte block to replace. The next lines are the other sides' colours, telling the game what indexes to replace that range with for each new colour. Once you debug, you may see them appear as these blocks of 256 bytes too, but I can't really be sure, since the whole 'read from cps' thing is kinda weird imo.
As for the dual colour for Nod, honestly, I have no idea. I just found the code that checked if the side was Nod, and if so, switched the palette with the red one. I changed the check so it isn't just hardcoded for 'nod', but checks a custom "secondary palette" property of the house instead of just its house ID, and if said property isn't "-1", it uses it as index on a list of palettes (well, colour schemes actually) to find which remap table to use.
This function only did the side check and palette switch, though. I never bothered to check where it was called from. Most likely, the place it is called from is the actual system for loading graphics for buildings and units, and, in the units' case, with an extra check to only call the secondary scheme function for the MCV (since it needs to transform to a secondary-colour CY without sudden colour switch) and the Harvester (since, in C&C, it docks into the refinery building graphics). I'm afraid you'll have to debug C&C95 to figure that stuff out, though.
