TUTORIAL: Creating new tile overlays

[tracktwo]

I've put together a tutorial on how to create new tile overlays. I've created this for a new version of Evac All to work around a vanilla issue where certain tiles are not valid to evac from, but you can't always tell ahead of time which ones. It looks like this:

 

 

 

 

http://i.imgur.com/vl5RFsb.jpg

 

 

 

 

Since threads get buried fast, I added the tutorial to the Nexus Wiki. You can find the article here: http://wiki.tesnexus.com/index.php/XCOM_2_Tile_Overlay_Tutorial.

 

There are still quite a few unknowns here for me, but it works. Hope you find it useful.

 

EDIT: The version of the mod with this change isn't up yet either here or on the workshop, cause I'm trying to figure out how to not have an 88MB ModShaderCache file before I publish.

Edited February 23, 2016 by tracktwo

[Lucubration]

Thanks. Until and unless I get around to dealing with actual particle effects, this could be quite useful.

[Zyxpsilon]

Oh yes -- that infamous "Obstruction Trap" that makes the full 3x3 zone invalid in some cases where vertical "Tubes" aren't linked to the roping cycle towards the Skyranger take-off position. I got scooped once by this flaw and promised myself never to be fooled again. Ya know what -- three more times already, i swear my visual acuity was right on the spot... so i thought. Isometric rendering is such a gimmick for most people.

 

The shaderCache 85MBs silly problem?

Well, this really seems to be an attempt by Firaxis Devs to solve performance issues on some Video-Cards settings or PC Drivers... honestly, they're shooting straight for diagnostic hints (publicly, no less) with that stuff. Conspiracy aside, it's almost useless and there's an easy way to deal with the temporary situation.

 

Go to the XComGame\MODS folder in the XCom 2 SDK root and simply delete that file ---before--- uploading to Steam.

Be warned that each subsequent BUILDS will put it right back in, every-time-we-must-do-our-magic-finishing-steps!!

 

Let's hope they'll fix that messy "principle" soon -- cuz at that rate, the Steam-Workshop (and most people's directories) has been flooded by pseudo -- (or relatively important) -- junk long enough, AFAIC.

 

I'd rather concentrate on CREATING/CODING some mods than worrying about validated file size(s).

:D

 

PS; Superb Tutorial, btw. (And... since i'm contemplating a new symbol for the Puck cursors, that precious and detailed info will certainly come in handy -- mucho thanks, Jo.) :wink:

 

PS2; I'm crossing 11 fingers & all toes overhere that this might well be related to (or exploited for...) the theory "Send/All/To" feature we discussed last week! Logic is fun when performed by skilled minds.

Edited February 23, 2016 by Zyxpsilon

[davidlallen]

 

 

Go to the XComGame\MODS folder in the XCom 2 SDK root and simply delete that file ---before--- uploading to Steam.

I tried that for my ArmorVariety mod that makes the advent armor wearable (original work by Dor). But, when I ran the game with this file deleted, all the armors were black. So I rebuilt, and left the file there when I published. Are you sure there are no side effects from deleting this file?

[tracktwo]

The shader cache file is definitely required - I accidentally published the wrong folder on nexus for one of my mods so this file was missing and it definitely caused bugs. But I think Xyzpsilon is suggesting cleaning the folder out and rebuilding may shrink the size back to a reasonable level. I'll try that tomorrow.

 

I'm not sure when exactly I started seeing this, or how the shader cache is constructed, but this didn't happen before. One thing I changed was making my content package an external package in the editor. In the first releases I had it directly in the UDK folder tree. It's possible that this caused the change.

[Zyxpsilon]

This might explain how i got my own big file too, btw. I had assumed this was a new Patch/HotFix consequence simply because the timing matched with the exact moment Steam Installed this tricky update.

 

Two flaws could have caused it to appear, then;

 

1) Double-Clicking directly on the Content\***.UPK file from ModBuddy solution (as an absolutely normal OS reflex, i guess -- we're all conditioned to just use that process)

 

2) Firing up the editor & wanting to edit that specific file straight into its own external package section (tricky proposition, AFAIC)... cuz, there's no immediate FeedBack proofs that the changes performed are validated ***WITHIN*** the correct string of editing principles that UE3-IDE is conceived to handle. Again, this is a matter of intuitive coding reactions. Meaning -- there are unclear design rules that risk borking up our setups and ruin files structure. Sadly, we don't really have a direct way to intervene or verify... what-where-how something destroys stable work.

It's okay for people familiar with UE3... but apprentices like me are bound to fail --not because they aren't skilled-- but on some weird IDE requirements and technical details undocumented by XC2-SDK.

 

I feel Caching is necessary -- sure. Yet this major problem needs to be solved at the source extremely soon by Firaxis. I suspect the Tsunami of unpredictable flaws has yet to reach its inevitable momentum. Workshop flood included.

 

It's very dissapointing nonetheless. :sad:

 

As if i didn't have enough troubles already figuring out how to use custom Rank Icons by means of studying many different source code files; UIUtililies_Image.UC + X2SoldierClassTemplate.UC & XComClassData.INI ... and even more!

I promised myself never again to hack my way to textures via TexMod. If nobody can truly help at this point -- well, see ya all around in a few months or years without any rational guarantees of results or even, success. Yeah-right... Listeners. We need Talkers.

 

I'll just go play some more -- maybe that's all i can do.

Edited February 23, 2016 by Zyxpsilon

[tracktwo]

I don't think this is even a Firaxis issue, I think it's an unreal issue. But I don't know for sure yet what exactly is causing the bloat, but I'll investigate more tomorrow.

 

My current working theory is that unreal is pulling in extra dependencies from the base game when using my external package. I'll try to take a look at the contents to verify that and try to figure out how to avoid it. I don't think I'm actually referring to any base game assets in my particular package, but I do remember unreal doing weird stuff when I was using custom packages in EW. I'll also see if my workaround of not using external packages helps. What I did in EW was create directory junctions mapping script and contents folders in my mod to the UDK directory structure. That way I kept my mods self-contained but also kept unreal happy cause everything was under the same directory tree.

 

I'll report back any findings when I have them.

[tracktwo]

OK: had some time at a computer earlier than I thought and issue solved. I was getting errors in the Editor about the local shader cache being > 300MB and that this isn't recommended. I didn't remember getting those errors before. So I just deleted XCOM 2 SDK\XcomGame\Content\LocalShaderCache-PC-D3D-SM4.upk and then rebuilt. It regenerated that file as 12KB, and my mod's ModShaderCache is now tiny again. I don't know if something got out of sync locally or whatever I was doing was causing it to grow constantly, but it'll be something to keep an eye on.

[Zyxpsilon]

Good news.

 

Then, this whole mystery looks more & more to me like the RefShaderCache-PC-D3D-SM4.upk (same size) somehow gets a clone copy (( starting with the Local prefix in place of Ref )) in the root folder.

I'd risk a guess on when & how this accidental UE/ModBuddy transit process occurs == Debug! When the pre-build phase happens, the interactive flow clearly indicates such a file is being accessed while the VCard driver dispatches its settings (NVidia here -- and that one does have a tricky Shader swing). So at run-time, the engine presumes that temporary clone should be dumped as a core asset to the actual ModBuddy structure. Which in turn --of course-- grabs it like a go-happy-clown forever as valid. -duh.

 

At least, you found us a workaround solution. Spread the word? ;)

[Lucubration]

Thanks, tracktwo. I remembered seeing this thread just the other day, and I used it to reduce an 83 MB ShaderCache for my mod... down to 371 bytes. I thought that publish was oddly large.