tracktwo

Check X2PathSolver (might have the name slightly wrong, on mobile). This is the class that contains utilities for computing a reachable path between points.

Since the new call is buried inside spawn for actors I'm afraid you may be out of luck, unless there is some alternative to spawn that lets you pass in an instance name that it'll respect, but I'm not aware of any such thing. So I think your workaround might be the only viable option here.

Yep, that's an alternative too, you'll just need to sync it up to the shot. I'm not an animator either so I don't know how to do it, but I do know the default animations for sniper and cannon shots are extremely short so they frequently have this problem with custom SFX. Another hint: be careful to not put the SFX cue at exactly the same time as another notify or it may not play. Stagger them all slightly so they trigger close to each other but not exactly the same time.

The animation you attached the SFX to is probably too short. The sound effects can get cut off if the animation is so short that a frame rate dip can skip the sound notify. If you make the animation longer that should help.

Yep, I've had this problem in the past too, even before the patch. Don't subscribe to you own mods or things can behave very oddly.

Found a mistake in my original post: XcomEditorUserSettings.ini is the file you want, not Default. It may already have the SourceControl section in it.

If you look for a launch.log in the SDK log folder (not the one in your personal my games folder) it might be able to give you more insight about what's going wrong. I think it's in SDK/xcomgame/logs but I might have the path not quite right.

Yes, new bug since the June patch makes the new feature not work. Source: Firaxis.

@Abeclancy there is a bug in the xcomgame loading that requires a hotfix from Firaxis to work. It prevents loading a custom cooked xcomgame package from a mod folder. As a workaround for testing locally you can copy the xcomgame.upk and size file into the game's cookedpcconsole folder (not the SDK folder, the game). Basically overwriting the base game version with yours. Back up the old one first! And doing so will obviously mean you can't run vanilla until you restore the original files, even if you untick your mod in the launcher.

There is apparently a problem with source control integration in the editor since the patch. Try editing XComEditorUserSettings.ini to include: [SourceControl] Disabled=True That helped for me. EDIT: Original post said DefaultEditorUserSettings.ini, correct file is XComEditorUserSettings.ini. Both files exist but XCom is the one to change.

Did you see my post a few responses back up? The loc should all happen long before it gets to flash. If that string isn't showing up localized when you `Log it the problem isn't on the flash side, it's in the regular unreal loc. Double check for typos in your loc file and make sure the entry is in a correctly named file.

That sounds like something is misconfigured in your localization setup. All the loading of localization should happen long before you get to the call site where you pass a string to flash. To verify, you have it declared as "var localized string strFoo" and then in MyMod.int you have a section [MyMod.WhateverClass] with 'strFoo="some text"'? EDIT: To clarify, if the localized string is in one of your classes, not a base game template or anything, then your loc needs to be defined in a file with your mod name, not XComGame.int.

Can't you just use your own localized string variables in your own .int file?

Scaleform is not likely to help you too much, I don't think. That would be useful if you want to create your own custom flash, but that'd completely bifurcate the UI. In order to make a custom screen or panel from the flash level you need to tie into the ActionScript framework exposed by the game's ui - you need to inherit from the right classes and call the right functions in the actionscript to make that work, and none of that source code is part of the SDK. I did hack together a custom screen with some custom flash, importing the .swf to unreal and that did load (at least I could draw some basic sprites). But since it's not really a proper Screen at the flash level I can't attach any vanilla panels to it, so I can't really build anything useful from this unless I want to reimplement all the widgets and everything. I don't think I understand your original problem, though. Are you trying to create a new screen and display some existing panels in it? As. I understand it, that should work, but there might be something specific about the intel panel that I'm not familiar with.

The default mod template just populates from some .zip files that are provided by Firaxis. You can find them all in your SDK\Binaries\Win32\ModBuddy\Extensions\Application\ProjectTemplates\XCOM2Mod\1033\ folder (e.g. DefaultMod.zip). Looks like the templates weren't updated with the patch. But there isn't anything magic about the templates, you can just copy over all the files from SrcOrig into your mod folder and it'll show the updated ones. The only gotcha is that any new files won't be automatically added to the project, so you'll need to manually "Add Existing Item" and choose the files to add all the new ones to the project. Probably easiest to use a diff tool like windiff/kdiff3/etc to do a folder compare of the classes in SrcOrig to the ones in the mod and that should tell you all the files that exist in SrcOrig but not in the mod that you need to add to the project.

There are extra arguments to `log() that you can use to categorize your own log messages into a different log category. This can make them easier to read. E.g. `Log("My log message",/*A condition goes here to log only if a condition is met*/,'SomeName'); Then in the logs it'll say something like: [0021.32] SomeName: My log message This can make it easier to grep for your own messages by searching for "SomeName:". As a bonus, you can use the "+Suppress=SomeName" directive in XComEngine.ini to suppress all of the logs in this category, so you can set up detailed tracing that is suppressed by default but you can turn on (with a -Suppress) for debugging. There's also the "FilteredLog" section in DefaultEngine.ini that looks like it'll log particular categories into different log files, but I couldn't get that to work.

There is a UDK localization guide on epics site that explains how to do localized audio. Basically you split the cues and wavs into separate packages with a particular folder structure and naming convention and it'll create multiple sound packages, one for each language. The game will load the correct one at runtime.

The ability icons are all just alpha channel masks, yeah. If you open it in photoshop and see all black, switch to the channels tab and click the box next to the alpha channel to make it visible (and uncheck the RGB ones). You should see the icon at that point and you can edit it with greyscale values to adjust the opacity. The icon will get whatever color tint you assign it in the ability template.

You can't directly add new actionscript to the existing flash, but there are alternatives. You can also extract the flash files from the gfx packages and view them to get the list of functions, and use either the MC utilities or raw scaleform calls (eg Invoke()) to call functions in the flash or get/set variables. You can find the gfx package from the ui class, but I haven't found a simple way to extract it yet. You can open the package in the unreal editor and see the SWF object in the content browser but exporting it won't give you a .SWF, unfortunately. What I did was open the gfx package in a hex editor, search for "GFX" and copy pasted the rest of the file from that point into a new file with a .SWF extension. That was enough to get JPEXS to read the file and decompile the actionscript. There may be a better way to do this. You can also build your own interfaces if you can author .SWF files, and manipulate objects from the existing flash through your own actionscript. See my thread on the XCOM EU mod talk forum for my adventures in getting this working for EW. The same techniques should apply. i believe the thread was titled "R&D flash modding" or something like that. Edit: here's the link. Not sure how useful it'll be for xcom2. http://forums.nexusmods.com/index.php?/topic/3020124-r-d-xcom-uiflash-modding/page-4&do=findComment&comment=27687815

Mods will always run the risk of conflicting with each other regardless of what technique you're using: if your mod replaces all swords with lightsabers and mine replaces them all with rubber chickens we're obviously not going to be compatible (until the glorious light chicken mod arrives, obsoleting both). But I don't see how the technical solution of the ui listeners as an entry point would ever introduce any such conflicts as there is no limit on the number of mods that can attach to the same listener, and the listener events themselves don't change any game state. Whereas overriding definitely does cause specific problems just by virtue of using an override, even if two mods would otherwise be completely independent but happen to override the same class. Do you have a specific example of what kind of conflict you get from the listeners? one that wouldn't be a problem with some other technique?

With the expanded dlc info class hinted at in the official mod support thread, we might be getting some new, more appropriate "entry points" into the game in an update. Yeah, I agree that using the ui listener is often a hack, but like someone else said on another thread: better to have impure code that does the right thing than code that doesn't play nicely with others. Religious adherence to something like MVC concepts isn't going to help anyone when all the mods are incompatible with each other. And there is a surprising amount you can do without overrides. But not everything, I know :) I have issues in some of my own mods that I can't solve perfectly using just listeners, but I do feel that compatibility is worth those minor bugs.

IIRC you can extend native classes, but your subclass can't itself be native. Attempting to do so will crash the game because the engine will try to look up the corresponding native data structures for the class and of course not find any. A lot of the existing game classes do this: there is a non native XComFoo class that extends the native class XComFooNativeBase. But in general I agree with eXecator: never override anything except as a last resort.

It's true the wiki takes a lot of work to maintain, but it's so much nicer to have a single fairly focused source of information. We had the incredible good fortune of having a resident librarian (DubiousIntent) in EW who curated a lot of the wiki and even pulled info out of threads into new wiki pages. The threads would often get out of hand (30+ pages of rambling posts on experimentation, failures, partial successes, new ideas and off topic side conversations) where trying to find the important bits again later gets really hard.

Glad to hear of the support! Two things off the top of my head right now: Allow UIListeners with screen set to UIFoo fire for UIFoo and any subclasses of UIFoo. Currently any mod that overrides a UI class breaks all mods that use a listener for that class. Defined mod load ordering so we can be sure a mod will load after some other mod. A potentially bigger item would be to allow us to register pre/post delegate functions instead of needing to extend a class. I haven't thought this through entirely yet, but the basic idea is to provide an alternative to class overriding that several mods can do at the same time on the same class. If I can say "call function X before/after SomeClass.SomeFunction" that would be amazing. Edit: Walking to the bus stop thoughts: don't use delegates, pass ThisObj and a name of the pre/post hook sort of like the event system except always synchronous calls. So the hooks can receive all the arguments and an out return value of the hooked function without running afoul of the uscript type checker.

For sure. I wasn't worried so much about cheat mods but rather mods that were using this technique to adjust difficulty templates without saving and restoring the lowest difficulty setting. People would be understandably upset to discover their achievement didn't unlock because of a mod that doesn't really drastically impact gameplay.