wghost81

Those packages are indeed decompressed, so DecompressLZO report is correct. You don't need to unpack Engine package for the mod to work properly. You need only the files included in the mod distro (MAC/Linux distro). If memory serves, Engine.upk is not listed in sha file, so this might still be the hash problem. Try installing a fresh game copy with no mods, decompressing XComGame.upk and removing corresponding uncompressed_size file.

You can't create new topics there using forum interface, but you can do it via site interface or you can just find an appropriate existing topic. Do you have Steam and XCOM installed to default locations? Are you sure you're running EW, not EU?

http://forums.nexusmods.com/index.php?/forum/665-xcom-file-discussions/

Yes, I tend to forget about CheckpointRecord and scratch my head when some weird bugs appear because of it. :smile: Good advice for everyone: always check if the variable you modifying is the part of CheckpointRecord structure. :smile: Just for the reference: CheckpointRecord structure is used to save/load saved games. BTW, I saw your topic on StrategyAI mod and I recommend to try and use Mutators for this purpose, as hex-coding such a complex mod is a pain. XCOM Mutators project on GitHub: https://github.com/wghost/XCOM-Mutators

Yes, all these static and private modifiers can be removed to our advantage with no negative effect for existing maps/scripts.

For Patcher: UPK_FILE=XComStrategyGame.upk EXPORT_ENTRY=XGStrategyAI.m_arrUFOsShotDown.m_arrUFOsShotDown OBJIDX=Core.FloatProperty // Type To change the type of the array you need to change the type of its inner object (first 4 bytes of corresponding export table entry). Thankfully, IntProperty and FloatProperty have the same serial data, so no further changes are needed in this case. And, of course, don't forget to use proper tokens (for floating point operations) while modifying all the scripts needed.

If we are to make a combined stubs for both scripting and map editing, we need to keep all the variables and functions in place. But, I believe, for map editing purposes only you can safely remove internal class variables.

I took some time to look at the FogGene's findings and to make my own observations on XCOM savegame format. As I predicted, save format is quite similar to upk format. The main difference is that all the objects and names in savefile are stored directly as strings while in upk they are stored as name/object table indexes. Objects are saved as a sequence of lzo packed chunks. Each chunk starts with usual "magic" - C1 83 2A 9E. After unpacking it reveals a structure, described by FogGene on me3explorer forum. I want to make several corrections to his description, though. Uncompressed save data starts with the list of names. First 4 bytes hold the number of string objects in the list (N), but the actual number of objects is N/2. I'll explain why. Each object saved in that list has the following structure: (string) Name (int) Numeric (string) PackageName (int) Numeric This structure follows the same convention as name reference, used in upk: Name + Numeric define a unique instance name. The only difference is that Name is referenced with 4-byte index in upk and is saved as a string in savefile. So, for each name in savefile name list, data format follows this pattern: 4 bytes integer - length of object name null-terminated string - object name 4 bytes integer - numeric 4 bytes integer - length of package name null-terminated string - package name 4 bytes integer - numeric Numeric is decoded the same way as for upk: if numeric == 0, nothing is added to the name; if numeric > 0, numeric-1 is added to the name. Examples (URB_Bar): WorldInfo_6:URB_Bar StaticMeshActor_35:URB_Bar StaticMeshActor_11:URB_Bar StaticMeshActor_13:URB_Bar LightmassImportanceVolume_0:URB_Bar XComFloorVolume_7:URB_Bar XComFloorVolume_11:URB_Bar XComFloorVolume_12:URB_Bar WordInfo_X is an instance of an object in the World, so I don't know why FogGene decided to nest all the other objects under WordInfo in his tool. For whatever reason this list of names is repeated three times in the savefile: two times from the start and another one time later. List of names is immediately followed by the saved properties for each of the object. Again, data format is essentially the same as DefaultPropertiesList format in upk with the difference that all the names are saved directly as strings.

I did a research for LiQuiD911 on TheWorld.PersistentLevel data format and that's what I found. PersistentLevel object is of 'Level' type. 'Level' type is referenced as Class'Engine.Level', but it is not defined anywhere inside the Engine.upk package. As well as 'World' and some other classes, so I suspect those are defined directly in C++ code, i.e. they are completely native and inaccessible to us. Level class seems to inherit directly from Object class, i.e. its serialized data begins with internal linker info (PrevObjRef) followed by Default Properties List. Immediately after those there is an array of object references. Those references are Actors present on this Level. I have modified FindObjectEntry tool to deserialize and output those. Here is an example for URB_Bar map: Right after Actors array there is another array of strings. I have no idea what it is used for, but for URB_Bar it has 5 elements: The next four bytes seem to be the object reference of ShadowMap2D object. And down below there are also references to several LightMapTexture2D objects. But this part is unclear to me. So, in theory, to remove an object from the Level we need to overwrite its reference in Actors array and set it to Null (0x00000000). Here is an example patcher file to remove all the XComDestructibleActor objects from URB_Bar map: https://drive.google.com/file/d/0B5MAcyqYBx4dd2NwMmdJb2ZHeUk/view?usp=sharing It works and there are indeed no destructible actors shown: http://steamcommunity.com/sharedfiles/filedetails/?id=384562139 Interestingly enough, using 'set XComLevelActor bHidden 0' console command brings all the 'removed' actors back, so it looks like removing an Actor from the Level 'database' results in hiding it and not deleting it. All the experiments were conducted with just URB_Bar map, no streaming maps, no UDK maps. New UPKUtils version on github: https://github.com/wghost/UPKUtils/releases/tag/v6.2

Sorry for disappearing, but I'm busy with my RL job right now and I can't provide much help. :sad: LiQuiD911, PM me if you need a patcher script or a new functionality added to help you with your work. I'm still reading the forum and I will certainly return as soon as I have more free time. :smile:

Do not use Training Roulette, it's bugged under Mac and Linux.

Sorry, I completely forgot that UEE decompiles certain (numbered) names incorrectly. Working enum definition is: enum ETeam { eTeam_None, eTeam_Neutral, eTeam_One, eTeam_DONT_USE_1, eTeam_Two, eTeam_DONT_USE_2, eTeam_DONT_USE_3, eTeam_DONT_USE_4, eTeam_XCom, eTeam_DONT_USE_5, eTeam_DONT_USE_6, eTeam_DONT_USE_7, eTeam_DONT_USE_8, eTeam_DONT_USE_9, eTeam_DONT_USE_10, eTeam_DONT_USE_11, eTeam_Alien, eTeam_DONT_USE_12, eTeam_DONT_USE_13, eTeam_DONT_USE_14, eTeam_DONT_USE_15, eTeam_DONT_USE_16, eTeam_DONT_USE_17, eTeam_DONT_USE_18, eTeam_DONT_USE_19, eTeam_DONT_USE_20, eTeam_DONT_USE_21, eTeam_DONT_USE_22, eTeam_DONT_USE_23, eTeam_DONT_USE_24, eTeam_DONT_USE_25, eTeam_All, eTeam_MAX };

You can't re-define an object in different class, as it will result in a different object. I have enum ETeam defined inside Object.uc class and it compiles and works perfectly. Furthermore, Actor.Spawn functions is different in XCOM: native final function Actor Spawn(class<Actor> SpawnClass, optional Actor SpawnOwner, optional name SpawnTag, optional Vector SpawnLocation, optional Rotator SpawnRotation, optional Actor ActorTemplate, optional bool bNoCollisionFail, optional Core.Object.ETeam SpawnTeam); UDK: native noexport final function coerce actor Spawn ( class<actor> SpawnClass, optional actor SpawnOwner, optional name SpawnTag, optional vector SpawnLocation, optional rotator SpawnRotation, optional Actor ActorTemplate, optional bool bNoCollisionFail ); I.e. UDK version doesn't have SpawnTeam. I haven't modified it for mutators and, surprisingly, it worked perfectly. But I have no idea what effect it might have on kismet spawns. Umodel can extract everything, including meshes, afaik. If you look inside the map package, you will see TheWorld object and tons of other objects. TheWorld is what contains actual map actors. Everything else are assets, cooked directly into the map: textures, meshes, anims, FX, prefabs, etc. If we somehow clear TheWorld and make it into an empty map, it will still contain all the assets we could use. In theory. :smile: Question is, how to clear it. TheWorld.PersistentLevel object contains some binary data which looks like a list of object references. I suspect, those are actors of this level. We could try to set all those to null for a start and see what breaks. :smile:

Well, all the assets are cooked into map files and we have to either prevent cooking our stubs into new maps and try to load actual assets from inside some existing package (same way as you do now) or try to extract those assets from maps and recreate them with all the textures and meshes. If you use camera zoom mod to set insane zoom values, you'll be able to see how XCOM maps are made: http://steamcommunity.com/sharedfiles/filedetails/?id=347976244 Basically, each map is a small area inside a 'ghost' city. I don't know if this is a good idea, but if we can clear that area, we can stream in our own map instead, which will have access to embedded assets. Edit: just tried 'stub asset' thing with menu sound cue, cooked into XComGame: SoundCue'SoundUI.MenuSelectCue'. This one is cooked directly into XComGame.upk, but originally it was a separate package. So, to obtain a correct in-game reference I used UDK to create a stub SoundUI package with one empty SoundCue object named MenuSelectCue and saved it to UDKGame\Content folder.

BTW, Actor class is slightly modified in XCOM, I suggest you take a look at those differences.

You can have your very own location :smile: An entire LiQuiD911 map! :smile: BTW, regular non-kismet spawns use XComAlienPod_Abduction/XComAlienPod_Terror objects for placement. They do not require any pawn content, afaik.

LiQuiD911, interesting. I will certainly take a look at those.

All the map objects should have 'placeable' attribute for you to be able to actually place those on the map. You mean your script packages are cooked into the map? Have you added those to Engine.ScriptPackages section of UDKGame\Config\DefaultEngine.ini? Like this: [Engine.ScriptPackages] +NonNativePackages=UTGame +NonNativePackages=UTGameContent +NativePackages=XComGame +NativePackages=XComStrategyGame

It does. I strongly recommend to keep vanilla compatibility for a start. This will make it easier to debug. On the other hand, I don't think LW modifies any of the map related object properties. I have four vanilla XCOM versions on my hard drive, plus test version with plenty of mods, plus Long War version. :smile: I also have two different UDK installs for EU and EW. :smile: Bruteforcing all stubs can take ages. I usually re-create only the parts I need for my current work.

Some install advices from MAC user: http://forums.nexusmods.com/index.php?/topic/2407274-beta14-on-mac/?p=21457719

LiQuiD911, amazing progress here! Congrats! You don't need any of the functions for map objects to work. Map objects are archetypes and operate on properties (i.e. member variables) only. So all you need to do is create a bunch of classes with member variables definition. And, again, you don't need all of these variables, as not all of them are used to define map object. And yes, UEE code is incorrect in some cases. Furthermore, compiled packages do not need DependsOn specifier, but uc sources do. You can create github projects with current data so the others could see the progress and contribute to dummy sources. UPD: In fact, I decided to set an example :smile: and uploaded my current sources I used to compile XCOM Randomized mutator project. Hope this helps a little at least with general idea on how to make those.

LiQuiD911, I was. And I'm still is. But I'm quite an unorganized person and I tend to have a hundreds of projects under development at the same time, so I just jump from one idea to another and sometimes forget to finish what I started. :smile: It doesn't play new music or it plays no music at all? I think in the same voice packages topic there were some examples of how to play custom music cues.

I don't have Mac, so I can't help you with exact steps. Google for Mac console usage tips. Under Linux it's enough to open the shell and run the script. Same things have to be done under Mac, you just need to find out how to open that shell.

You need to create and compile corresponding XCOM sound classes. After that you will be able to use them in UDK editor. There was a topic about voice packages with examples somewhere in this forum.

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.