Happy New Year 2015!

[wghost81]

Five minutes to New Year here and I'm here to bring everyone a good news:

http://steamcommunity.com/sharedfiles/filedetails/?id=366571093

 

Happy New Year and Happy New Modding!

 

PS I will return to you with explanations after celebration is over. :smile:

 

PPS I forgot to mention: of course, it wasn't created by simply editing localization text. :smile: It was created with UDK, new scripts and some ini editing.

Edited December 31, 2014 by wghost81

[wghost81]

A slightly better example of new shell class in action:

http://steamcommunity.com/sharedfiles/filedetails/?id=366835296

[wghost81]

Now to the explanations of what is it and how it is working. :smile:

 

Here's the overview of UE gameplay elements: http://udn.epicgames.com/Three/GettingStartedGameplay.html Basically, by creating a new GameInfo subclass we can create a completely new game based on XCOM engine. But this is kinda big, so the best way would be to "subclass" an existing game and then modify it.

 

First problem here is that the base GameInfo class of XCOM seems to be hard-coded inside exe file. I tried changing DefaultGame parameter inside DefaultGame.ini before with zero results. But after looking at the Launch.log closely I found that the base XCOM GameInfo class is actually the XComShell class. And it can be changed using LocalOptions parameter in DefaultEngine.ini:

[URL]
LocalOptions=?game=XComEUModPack.XComStartupGameInfo_Mod
...

This will force XComEUModPack.XComStartupGameInfo_Mod class to be set as current game info class when the game is launched. After it is done, everything else is just a matter of subclassing the corresponding classes and redirecting them to newly cleated ones. In XComStartupGameInfo_Mod:

 

 

class XComStartupGameInfo_Mod extends XComStartupGameInfo
    hidecategories(Navigation,Movement,Collision)
    config(Game);

static event class<GameInfo> SetGameType(string MapName, string Options, string Portal)
{
    local class<GameInfo> GameInfoClass;
    local string GameInfoClassName, GameInfoClassToUse;

    `Log("Modded startup game is active!");
    GameInfoClassName = class'GameInfo'.static.ParseOption(Options, "Game");
    if(InStr(GameInfoClassName, "XComMPTacticalGame", true, true) != -1)
    {
        GameInfoClassToUse = "XComGame.XComMPTacticalGame";
    }
    else
    {
        if(InStr(GameInfoClassName, "XComMPLobbyGame", true, true) != -1)
        {
            GameInfoClassToUse = "XComUIShell.XComMPLobbyGame";
        }
        else
        {
            if(InStr(MapName, "Shell",, true) != -1)
            {
                GameInfoClassToUse = "XComEUModPack.XComShell_Mod";
            }
            else
            {
                if((InStr(MapName, "Command1",, true) != -1) || InStr(GameInfoClassName, "XComHeadquartersGame", true, true) != -1)
                {
                    GameInfoClassToUse = "XComEUModPack.XComHeadquartersGame_Mod";
                }
                else
                {
                    GameInfoClassToUse = "XComEUModPack.XComTacticalGame_Mod";
                }
            }
        }
    }
    if(GameInfoClass == none)
    {
        GameInfoClass = class<GameInfo>(DynamicLoadObject(GameInfoClassToUse, class'Class'));
    }
    if(GameInfoClass != none)
    {
        return GameInfoClass;
    }
    else
    {
        return default.Class;
    }
}

 

It works well with shell class, but replacing strategy and tactical GameInfo classes is a little problematic, as calls are scattered throughout several different classes. For example, XComHeadquartersGame call is embedded in UIShellDifficulty class (and also in several other classes). This can complicate things a little, as it will require to subclass a LOT of classes to change all these calls. But it works anyway and that's great! From the Launch.log:

...
[0004.60] DevNet: Browse: XComShell?Name=Player?Team=255?game=XComEUModPack.XComStartupGameInfo_Mod
...
[0004.92] ScriptLog: Modded startup game is active!
[0004.93] Log: Game class is 'XComShell_Mod'
...
[0005.29] ScriptLog: Modded final shell menu is active!
...
[0010.20] ScriptLog: Modded difficulty shell is active!
...
[0011.56] ScriptLog: Modded startup game is active!
[0011.76] Log: Game class is 'XComHeadquartersGame_Mod'
...

Again, if only we had uc source files it would be a matter of minutes to create a base for a mod! But the necessity to create dummy classes slows down the process considerably.

 

The result of the New Year experiment: we can re-script XCOM without a hex coding! Whoa! This can potentially open a new era in XCOM modding (you saw a new button in main menu, haven't you? :smile: ), but it sure needs further R&D to be actually usable.

Edited January 1, 2015 by wghost81

[XMarksTheSpot]

Ooooh shiny!

 

At first I thought you simply hacked in the unused message-of-the-day ticker functionality, but it looks like your discovery runs quite a bit deeper than that :)

 

Great job! :thumbsup:

[wghost81]

Speaking of discoveries. :smile: I haven't yet tried to make new menu windows, but I think it's entirely possible using UDK Scaleform. XMarksTheSpot, have you tried experimenting with it? I don't even know where to start. :smile:

[XMarksTheSpot]

Speaking of discoveries. :smile: I haven't yet tried to make new menu windows, but I think it's entirely possible using UDK Scaleform. XMarksTheSpot, have you tried experimenting with it? I don't even know where to start. :smile:

I haven't attempted to create an all-new screen yet, but there's lots of information to be found about UE's Scaleform middleware implementation.

 

Not too sure about how everything needs to be set up w.r.t. UnrealScript logic. All of XCOM's UI classes seem to extend one of several linker classes like UI_FxsScreen or UI_FxsPanel which are actors at their core. Those linker classes define (among other things) a GetMCPath() function which, I guess, returns the package path of the embedded SwfMovie object to which the class is supposed to be linked. GetMCPath()is a native function though, so since the actual logic behind it is not immediately visible it's hard to tell how and where the attached objects need to be put in order to be recognized properly. This is a bit of a headscratcher especially when considering that almost all of the SWF movie clips are dumped in collection packages (e.g. UICollection_Strategy_SF.upk) separate from the linked UnrealScript game logic classes.

[wghost81]

Yes, I saw those classes while I was working on the modded shell. But since I'm no expert on GUI, any GUI element drives me crazy. :smile:

 

Adding a button to main menu shell doesn't require any swf modding. Even without a new menu it can be used to launch a modded game, i.e. to separate mods from vanilla game. But I was dreaming of replacing calls to existing swf menus like skill tree, for example, with calls to newly created ones. :smile:

 

BTW, I'm working on EU not EW now. It actually started with improved mutators compatibility idea. :smile: Then I realized that I don't actually use mutators by design: I simply use them to spawn modded class instead of vanilla one. SO the next question was do we even need mutators to use UDK created scripts? And the answer turned out to be no, we don't. :smile:

[XMarksTheSpot]

Adding a button to main menu shell doesn't require any swf modding. Even without a new menu it can be used to launch a modded game, i.e. to separate mods from vanilla game. But I was dreaming of replacing calls to existing swf menus like skill tree, for example, with calls to newly created ones. :smile:

I think this could be achieved by overriding GetMCPath() to point to a different SwfMovie, but there might be more to it than that, no idea. I guess you could try this by extracting one of the game's Flash files, put it in a different package, point to that via altered GetMCPath() and see if everything still works :) Note however that frequently SwfMovie objects are placed alongside other related objects (mainly Texture2D objects used in the movie file) in the same group. Not sure if this is a necessary precondition or just a by-product of the cooking process (or both).

[wghost81]

Thanks, I'll try this.

 

Yes, it's a by-product of cooking. Many upk files actually consist of several packages cooked together for better performance. I've noticed that UDK tries to put all the referenced objects in one package while cooking. We can reference those in our own packages by creating dummy sound and texture objects and compiling a package without cooking. This way dummy objects won't be included in a newly created package but will be referenced correctly.

Edited January 2, 2015 by wghost81

[LiQuiD911]

Wow, congratulations! I am truly looking forward for further developments :D