FxsRMcFall

In case you are curious... http://i.imgur.com/gFQzK0Y.jpg?1

I'm happy to participate in a discussion about best practices and mod interoperability. A framework mod is something we expected would evolve once the mod community had exposure to the systems and some mod ideas to spur it forward. Someone mentioned that static data members don't exist in UE3 ... actually they sort of do but getting at them can be pain. There is a method on engine called "FindClassDefaultObject" that will return the default object for any class by name. We added this to our version of UE3... anyways, data members of this object can be used like statics. Be aware that these members also form the "default" values of the class, so any values you set in there will be propagated to new instances of that class. Anyways, seeding the event manager with lots of events for modders to take advantage of - in combination with a set of methods that let you inject listeners for the events - could go a long way.

This is pretty cool! This was something that was tossed around as an idea for the game but never made it in. I can answer questions on face morphs, but that is a world of pain. As you might be able to tell from the data configuration, modding was not a factor when the face system was devised. That said, it sounds like one of your obstacles is getting the reference head from which to build a new morph? Perhaps we could include a base head source asset in SDK. You might have noticed this already as well, but face props that hug the face ( beards, nose rings, etc. ) also have morphs. One for each face... so that could be another complication.

Cinematic maps with the _VIEWER naming convention are used exclusively in the editor. If you have a map that is just a matinee that can "work anywhere", it gets a bit abstract to work with. So the cinematic team uses the viewer maps to pull in other maps and see how the matinee would look with actual stuff to serve as the background, environment lighting, etc.

It's cool to see this Unrealscript language service integrated into Modbuddy! As far as needing the base game files present to work properly, that is pretty standard and I expect Alex's hands are somewhat tied there by the language service interfaces. Modbuddy already avoids including base game *.u files if you haven't made changes, it should also be made to avoid including the base game source files in the same circumstance. That way, you can have the base game source files there to make the parser happy without worrying about an inefficient mod upload.

One other thing: to get the most correct image of what the scene would look like in-game you will want to use game view (https://udn.epicgames.com/Three/ViewportToolbar.html#Game View). This will use the post process sequence the game uses, which contributes a lot towards the final look.

The animations in the drop ship are controlled by matinee, and the RemoteEventString referenced above connects to the kismet that contains the matinee. The map representing the drop ship interior is called: CIN_Loading_Interior and this map contains the kismet script and matinees that control the characters. Since the animations are controlled by matinee that is why they do not work for non-human characters - matinee works by having direct references to the resources it is using. If you look at the Cinematics folder inside Maps, that is why there is a separate cinematic map for each character type. So your options are: 1. Implement alternate matinees for other character types in the CIN_Loading_Interior map and distribute that map with your mod ( it will override the base game one ). 2. Write code to handle other character types inside the drop ship parts of XComPlayerController. If we had needed to support other character types riding the sky ranger int the base game, this is what we would have done. Similar to how the characters are handled in the squad select and post mission screens. We didn't have any aliens in the lineup to test with, but the code had branches for that possibility.

Looked into this and indeed it seems like the sanctity of the utility item stat has been sacrificed in the name of some bug fix. As far as working around the stat being stomped I am curious whether you could work around the problem by using the MP character template name. In every case where bAddsUtilitySlot stomps the stat, it avoids doing so if there is an MP template name specified with SetMPCharacterTemplate. If you just make it 'Soldier' or whatever the normal character template is ... I believe that would suffice. The side effects of the MP template name being set would probably be acceptable relative to the stat being stomped. As was noted above unclamping the stat will have knock-on effects for other areas of the game. At the very minimum you would have to review UIArmory_Loadout and make anything there use the stat that wasn't already using it.

Our best practices for base game script changes are: not to change function signatures (adding optional parameters is OK) and not to delete or rename data members. I believe some of that did take place with the latest code update and should have been caught in code review, but moving forward it should be avoided. Also if you have other thoughts with respect to best practices feel free to share them.

The answer to the problems you are having with certain kismet nodes are pretty straight forward. Basically, you don't want to mix & match converted with unconverted nodes. However, in some cases using an unconverted node is essential ( such as with logic gates ) so in those situations the level designers manually flagged the node as converted. You can do this by viewing hidden properties on the node and then flagging the appropriate variable. Because this has already been done on base game kismet script nodes, that is why they operate correctly. What does "converted" mean? That just means that the kismet node is safe to use as part of a game play logic sequence, which is not allowed to be latent, manipulate actors, or store state internally ( kismet variables must be used instead for storage ). Why individual logic sequence actions weren't flagged as converted, I couldn't say - but in general it is likely because they store some kind of state internally that isn't part of the game state system and thus not "safe". An example of this would be a conditional that internally tracks how many times it has run. Technically not safe if you are going to use that internally tracked value, but if you don't plan on using that you can just flag the conditional as converted and use it anyways.

That is really cool, I was going to suggest using the .net steamworks library but it looks like you figured that out already. The original design for the launcher called for many of the features you have there but was pared back during production. Class overrides are a good start for conflict detection, another thing to check for would be package name conflicts.

Hey Abeclancy, when you compile scripts in "final release" configuration the log macro is compiled away. Logging is incredibly time consuming as it involves concatenating strings in many cases. And even worse from script when you factor in marshaling the data around. It can add dozens of ms to the frame time in the worst cases. If you want logging from final release script code you can use `warn. However, this will have the same negative performance impact that `log has if you throw it around too much. So it is recommended that you debug using the uncooked data / script packages and only cook in order to produce an optimized "shipping" package. Since "regular" mods are actually uncooked script packages, they can use `log in an unrestricted way but should be careful with it for the same reasons.

XCOM 2 Modbuddy / SDK will be getting updates / fixes alongside the game. At the very minimum the SDK must receive an update to keep the script code in sync with any patches that come out, but we will roll as many bug fixes and QoL improvements as we can into the updates as well. Issues such as the mod shader cache stuff mentioned here are an example of the type of issue that would be addressed asap.

Yes, the misunderstanding is clear now. Your replacement class is a subclass of the base game class, which must be done because this will *safely* operate with base game compiled script code that uses your replacement class. By safely, I mean that through the definition of your mod class you cannot cause data misalignment errors or memory corruption. I don't understand the resistance to just avoiding hiding base class data members, as this is a best practice when using inheritance anyways. The issue with the functionality you're asking for is that any discrepancies in the data layout between your mod class and the base game class could have disastrous effects on the execution of compiled script code distributed with the game. However, as with many things Unreal actually has a facility to do what you're asking already. There is a config array mActiveClassRedirects inside [Engine.Engine]. We have used this in the past to move classes from one script packages to another. This feature isn't currently usable for a mod because mod INIs are merged into the config cache *after* this array is processed. It could be made to work with mods easily enough though if you really want to play with fire.

Nice! A few things to note about cooking: Mods that replace XComGame are the highlander of mods, there can only be one. But it lets you do pretty much whatever you want with the script source - don't need to use class replacements, screen listeners, et. al. Also, regular mods that just add new script packages can still work with an XComGame replacement mod - but they would be effectively modding a mod so it could get weird unless they use your mod's source code as a base. "Weird" could include crashes if you start renaming or deleting variables or functions in the base classes that another mod's complied script code is using. Lastly, be very careful about making changes to base game classes that are part of the cooked data. One of the reasons that cooked data loading is so much faster is that it doesn't do any data type checking / version checking / tagged serialization / etc. So if you modify the data layout of a cooked object with script changes and don't update the cooked data then the object will serialize in using the old data layout. This causes random memory overwrites, crashes. So best to leave actors in the cooked data ( ie. stuff like XComLevelActor ) alone, but if you do make changes stick to just function changes and transient variables if you add variables to the class.

I think the confusion must stem from a misunderstanding of what the extends keyword, and by extension what the class replacement functionality provides. When you make an override class you are using the extends keyword to create a new class that derives from the shipping base game class. If you have two classes: +======================================= | Class BaseGameClass extends Object | | var int BaseClassVar; +======================================= +======================================= | Class ModClass extends BaseGameClass | | var int BaseClassVar; +======================================= If we look at a simplified memory layout of ModClass we see: +===============================================+ | BaseGameClass::BaseClassVar | ModClass::BaseClassVar | +===============================================+ The two BaseClassVar fields can hold different values and it depends on the running code and the script VM which one is used. This is why the following setup would be much better: +======================================= | Class BaseGameClass extends Object | | var int BaseClassVar; +======================================= +======================================= | Class ModClass extends BaseGameClass | | var int SomeNewVar; | | ( Uses BaseClassVar and SomeNewVar in virtual / local functions ) +======================================= In this set up there is only one BaseClassVar and when you use inheritance you only define functions to modify the behavior of the class. Does that make more sense?

OK, based on your error... I'm guessing your cook produced some small-ish texture file caches in the published cooked data folder. These are bad, because it means that your script packages will point to offsets in these small files instead of the ones that the base game has. Anyways, to fix this... Copy the following files into your "XComGame\Published\CookedPCConsole" out of the symlinked cooked directory: GuidCache.upk GlobalPersistentCookerData.upk PersistentCookerShaderData.bin All TFC files And then run the cook script again. If everything is operating correctly, you should see the TFC files remain unmodified by the cook ( indicating your script package is pointing to all the right offsets into the TFCs ).

Unreal script does not have an inline concept and does not have an optimizing compiler even if it did have one. Would be nice to have, but if we were going to go that far I'd rather just integrate another scripting language. The type specifiers matter because I don't believe overriding class variables is well defined. I'm not actually sure on that because we never do it in our own code and I haven't dug into the VM to see what the expected behavior is. Our intended purpose for the override classes was for modders to use inheritance to modify behaviors / functions only and only define new variables in the new classes, which data hiding makes more difficult. Regarding the config variables, they are set using INI sections with a this syntax: [<PackageName>.<ClassName>]. A new class (which you are creating) would require a new section to define its config variables. So, the reasons it was necessary are pretty specific to Unreal and how config files work / are cached internally.

Abeclancy, you are on the right track. We left cooking out in the initial drop because it comes with some caveats and is only worth it if your mod absolutely needs it. However, tools and documentation for cooking are in our future plans because as mods become more sophisticated the need for it will grow. Reasons to cook: * You are making a new XComGame script package - ie. you are rewriting / changing our base game classes to be whatever you want. Total conversion, inaccessible function, etc. * You have a LOT of new maps. To tell whether this is necessary you will just have to benchmark and see how your map pack affects load times. If it makes them really long it might be worth it to cook. The main caveat to cooking is that you are tying your mod to a specific revision of the game content. If the base game cooked data changes, it may invalidate the cooked data that your mod contains. Now, to help you with your XComGame cook... The symlink to the cookedpcconsole directory is to facilitate performing cooks for mods. This is so that your references to base game cooked packages and texture file cache locations are correct. The cooking process below is just if you are cooking a new script package. Before cooking, you'll want to run: "xcomgame.com make -final_release -full" - This will output final release versions of the base game script packages that the cooker can use. They go into a ScriptFinalRelease directory in your SDK\XComGame directory. Then:"xcomgame.com cookpackages -platform=PCConsole -final_release -quickanddirty -modcook -sha -multilanguagecook=INT+FRA+ITA+DEU+RUS+POL+KOR+ESN" - The output from this process will be a bunch of packages inside of a "XComGame\Published\CookedPCConsole" folder. You'll notice that the cooked XComGame script package is much larger than the uncooked because the cooker has embedded resources that the script packages references directly into it ( and the game needs this when running in seekfree mode ). Take the XComGame.upk and size files from that folder and copy it to a "CookedPCConsole" folder in your mod just like you would with a content package. XComGame and all the core script packages are not something that UE3 normally permits to be overridden by downloaded content, but we made changes to make it possible - so if you have the above setup the game will use your cooked base game script packages. Our future plans include an option under the "tools" menu in Modbuddy that performs these steps for you, but for now a batch script or cmd can do the same.

Catching up with this thread, the majority of these issues could be resolved by changing all our privatewrite vars to be protectedwrite. Since function call overhead is a huge issue, in unreal script the recommended best practice is to use type specifiers instead of getters / setters. Unreal script is a really old, really weird scripting language and inheritance can get tricky when you start hiding delegates fields, config vars, events, and other base class elements with your override class. Luckily, the path forward is clear. It would be relatively simple to relax those type specifiers a lot to help everyone out.

A comment on the Mod IDE: We in turn were disappointed at some of the issues that are apparent in VS isolated shell custom project library that Modbuddy is using. Some of the basic project operations that have problems were expected to work "out of the box" but sadly it wasn't so ... and fixing them couldn't be worked into the schedule alongside the game. Either way, when we have bandwidth to fix the custom project code we'll take care of it. And long term - ultimately, our goal is to replace our internal code workflow ( uses a lot of tools that cannot be distributed ) with what Modbuddy uses and then this issue will be resolved.

Unfortunately, I'm also a little unclear on when each of the macros applies, and when it doesn't. I copy/paste a lot of Firaxis code, and there are a variety of methods for accessing History for submitting gamestates. `TACTICALRULES.SubmitGameState really only seems to work when in a tactical mission, which makes sense give the name. `GAMERULES.SubmitGameState seems to work in almost every situation, except.... when adding things during a OnLoadedSave in X2DownloadableContentInfo, neither of these macros work, and the only way I found to submit (copied from the ExampleWeapon) is using : `XCOMHISTORY.AddGameStateToHistory First off - thanks for this write-up Amineri! This is a good overview of the component system for game state objects. Regarding when to use the rule sets and when not to when submitting game state changes... The rule sets provide special handling that are specific to XCOM 2's game rules - but are only active when the game world has come up. Specifically the rule sets include triggers for the event managers, rule set observers, and logic for processing the in-game concept of interrupts. So: If you are submitting game states that care about the rules of the game, use `GAMERULES. You shouldn't need to use the tactical variant of this macro unless you need something specifically from the tactical rules class. If the change you are making is technically outside the rules of the game, then that is where you might just directly submit changes to the history ( `XCOMHISTORY.AddGameStateToHistory ). In the use case above when responding to the load save event you are doctoring the history with whatever you want prior to entering the saved game world. Even if you wanted to use the game rules here, it wouldn't be advisable since the rule set that is active would depend on what game mode you were in when the saved game was loaded. In the shell menu, there is no rule set so that is probably the most common use case. The order of events for loading a save is: 1. The saved game data loaded into the history ( existing history is cleared ). 2. OnLoadedSave is called for any mods new to the save ( we're adding an additional event that triggers for *every* load not just the first ... ) 3. UE3 level load process is initiated ( open map command ). This loads up the "plot" map for tactical games, and the avenger skeleton for strategy. 4. The level load creates all the supporting actors required by that game mode, including the rule set actor. These actors then organize streaming in all the maps that form the bulk of the procedural levels ( backgrounds for both game modes, parcels for tactical, rooms for strategy ). 5. Load movie is lifted when all the maps and processes are situated. Hopefully that clears up when / where / how to submit new game states.

Looking at your override class, my off the cuff guess is that you did not remove config vars from your override class. The one that looks like it might have an effect is "UIColorBrightnessAdjust". Config vars that don't have an assignment in the INIs default to 0. In general leaving variables that conflict with base class vars is bad, but in some cases due to data hiding we might not have left you a choice. If your change is limited to just the methods that specify the body part filter delegate, I would recommend only overriding the methods that use that field. Let inheritance handle the rest.

Since we didn't update that class, I think you are probably running into a limitation in the script compiler and the timing is just coincidental. if you copied the class exactly then there may be additional challenges due to the fact that the class you are copying is native. For sure something we could look at, but I am confident it is not related to the hotfix / SDK update.

There have been a lot of good suggestions so far, some items on the road map for improvements: Allow overriding gameplay templates by name. Poking at the templates after they are built is more friendly if you just want to tweak one specific aspects of them and let other mods do the same, but a name based wholesale replacement is much cleaner and works more easily with the difficulty system.Improvements to the class replacement system, allowing static methods to be overridden and adding specific support for overriding selected natively constructed classes such as game state classes.Additional optional arguments for finding templates, including difficulty.New methods on the X2DownloadableContentInfo class for mods to use."Seeding" game play code with additional event manager events that mods can hook.Distributing our Visual Studio plugins in vsix form so that they can be used with Visual Studio professional or community/express editions ( which would support the use of nFringe )Cooker documentation, plugin.A better unreal script language service ( that provides intellisense ) is also planned. This was on the wish list for the initial offering of the mod tools, but didn't make it. There are some good ones already out there that could be bent with just a little bit of effort to work with our tool set, one of which I saw someone had gotten working ( sort of? ) on here.