anyone know?

-Dave

1) Yes. But, it involves thorough understanding of in-code calls... given a proper link, any 'custom' screens would certainly act as a genuine game asset.
** While i was trying to figure out a way to alter the welcome backdrop image and its menu location... i ended up with an extra selection box ready to push_in its secondary screen. This was made to create an alternate way for users to play (or not) teaser movies about the X-Worlds major races BEFORE entering the game settings itself. I still have a few things to fiddle for correct calls but i believe the principles remain similar everywhere else. Although - strict knowledge about ObjectX features is necessary; as long as functions structure and data-value requirements are met.

2) Again, this has more to do with how desktopX 'links' its inter-dependant set(s). If you take a look at the different VBscripts (like Macmatt said above) found in these files you will notice a programmatic way to invoque any sub-components of a running main screen. Click any box, callup sub-routine, extra-screen popping afterwards. Simple, direct and yet... complex enough to maintain. Integrity of the first main code_layer can't suffer from feasible and valid calls which is why (once more) solid understanding of prodedural coding is an absolute must. I doubt the core routines can be 'altered' though. But, if all you want is a few screens here and there with a limited set of data or images - it sure can be done. Accessing memory slots or even, the heap subset to acquire gameplay_values_data would possibly need much more complex scripting tasks. With proper encoding skills, anything could be done i guess.

But, need i insist, solid programming knowledge is definitely required.