LiQuiD911 Posted January 29, 2015 Share Posted January 29, 2015 (edited) Thanks :smile: Yeah, at the moment I am creating an overlay map in the UDK that uses the art assets of the one(s) already loaded. No moding required to create a map ( only in the stage where we should create a tileset ). It's a bit awkward if you don't have visual references to the base map so one should first check the coordinates ingame an then move the objects in the udk. This shouldn't be a problem for brand new overlay maps where everything should be visible in the editor. At the moment I'm not releasing the stubs because I'm still testing (mostly by trial and error) various setups. Also my lighting setup is a bit off (it looks as if it isn't per pixel) Edited January 29, 2015 by LiQuiD911 Link to comment Share on other sites More sharing options...
wghost81 Posted January 29, 2015 Share Posted January 29, 2015 (edited) 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: Edited January 29, 2015 by wghost81 Link to comment Share on other sites More sharing options...
LiQuiD911 Posted January 29, 2015 Share Posted January 29, 2015 Hey there :) I hope the requests are not too lenghty to implement.A note on the cooked shadows (and lighting I guess) in levels: they are not per mesh but per square sector. The lighting can be seen with umodel. So removing them alters the base level significantly. Link to comment Share on other sites More sharing options...
Zyxpsilon Posted January 29, 2015 Share Posted January 29, 2015 You're making good progress ..... saves us from having to write a custom map editor :wink: Ideally, such a custom "SDK" asset would become highly popular with most LW-Players, btw.Still, far out in the future though. :D Link to comment Share on other sites More sharing options...
LiQuiD911 Posted January 30, 2015 Share Posted January 30, 2015 (edited) I uploaded the new stubs on git https://github.com/iiiLiQuiDiii/UDKload the provided overlay map only on CB2_MP_Blank or other maps that have VEH_PickupB -At the moment the collision box is a bit off (the non reimported mesh is more precise and I can't set it up correctly)-The meshes are extracted with umodel,converted with a Blender plugin and reimported to UDK because stub meshes don't accept stub materials :blink:-The Materials,sounds and particles are stubs-The lighting is not ideal but I guess it's because of my UDK settings-The car windows are not working :\ I can't fracture the mesh right. (and I can't use stub mesh because of materials) uh.. bad news : streaming a bomb or an exalt map over CB2_MP_Blank shows that the bomb and radars do NOT get vision blocking. (previously I did some minor test on trainyard bomb and it seemed that the bomb had cover but I must have gotten something wrong)The radars replace the fogpods stealing their sightliness. Meld and the Transmitter get away with this because they are "friendly" objects that have player sight. Edited January 30, 2015 by LiQuiD911 Link to comment Share on other sites More sharing options...
wghost81 Posted January 31, 2015 Share Posted January 31, 2015 (edited) 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: FindObjectEntry Name to find: TheWorld.PersistentLevel Found Export Object: 0x00000A4B (2635) ( 4B 0A 00 00 ): Level'TheWorld.PersistentLevel' TypeRef: 0xFFFFFFD4 -> Level ParentClassRef: 0x00000000 -> OwnerRef: 0x00002C37 -> TheWorld NameIdx: 0x00000993 (Index) 0x00000000 (Numeric) -> PersistentLevel ArchetypeRef: 0x00000000 -> ObjectFlagsH: 0x00000000 ObjectFlagsL: 0x00070001 0x00000001: Transactional 0x00010000: LoadForClient 0x00020000: LoadForServer 0x00040000: LoadForEdit SerialSize: 0x000630B3 (405683) SerialOffset: 0x004214B3 ExportFlags: 0x00000000 NetObjectCount: 0 GUID: 00000000000000000000000000000000 Unknown1: 0x00000000 Attempting deserialization: UObject: PrevObjRef = 0x00000862 -> ParticleSystemComponent0 UDefaultPropertiesList: UDefaultProperty: NameIdx: 0x00000B11 (Index) 0x00000000 (Numeric) -> ShadowmapTotalSize TypeIdx: 0x000005AE (Index) 0x00000000 (Numeric) -> FloatProperty PropertySize: 0x00000004 ArrayIdx: 0x00000000 Float: 0x466EE028 = 15288 UDefaultProperty: NameIdx: 0x0000070C (Index) 0x00000000 (Numeric) -> LightmapTotalSize TypeIdx: 0x000005AE (Index) 0x00000000 (Numeric) -> FloatProperty PropertySize: 0x00000004 ArrayIdx: 0x00000000 Float: 0x468894D0 = 17482.4 UDefaultProperty: NameIdx: 0x000008C2 (Index) 0x00000000 (Numeric) -> None Stream relative position (debug info): 0x00000044 (68) ULevel: Actors: 4B 0A 00 00 // 0x00000A4B // PersistentLevel 01 06 00 00 // 0x00000601 // EffectCue_30 38 2C 00 00 // 0x00002C38 // WorldInfo_6 00 00 00 00 // 0x00000000 // 3E 2C 00 00 // 0x00002C3E // XComBuildingVolume_0 89 24 00 00 // 0x00002489 // StaticMeshActor_35 02 24 00 00 // 0x00002402 // StaticMeshActor_11 15 24 00 00 // 0x00002415 // StaticMeshActor_13 00 0B 00 00 // 0x00000B00 // LightmassImportanceVolume_0 4F 35 00 00 // 0x0000354F // XComFloorVolume_7 41 35 00 00 // 0x00003541 // XComFloorVolume_11 42 35 00 00 // 0x00003542 // XComFloorVolume_12 43 35 00 00 // 0x00003543 // XComFloorVolume_13 44 35 00 00 // 0x00003544 // XComFloorVolume_14 45 35 00 00 // 0x00003545 // XComFloorVolume_15 46 35 00 00 // 0x00003546 // XComFloorVolume_16 47 35 00 00 // 0x00003547 // XComFloorVolume_17 56 24 00 00 // 0x00002456 // StaticMeshActor_2 AF 36 00 00 // 0x000036AF // XComLevelVolume_4 8A 00 00 00 // 0x0000008A // DecalActor_5 [cut, file is too big] 68 2F 00 00 // 0x00002F68 // XComDestructibleActor_481 69 2F 00 00 // 0x00002F69 // XComDestructibleActor_482 Stream relative position (debug info): 0x00001854 (6228) Object unknown, can't deserialize! 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: 07 00 00 00 75 6E 72 65 61 6C 00 // unreal 00 00 00 00 // null string 0A 00 00 00 58 43 6F 6D 53 68 65 6C 6C 00 // XComShell 00 00 00 00 // null string 00 00 00 00 // null string 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 Edited January 31, 2015 by wghost81 Link to comment Share on other sites More sharing options...
LiQuiD911 Posted February 2, 2015 Share Posted February 2, 2015 (edited) Thank you for the update :smile: I've uploaded a small fix to my github because it was using EU enums instead of EW ones, now expansion units are placeable (and covert operative spawn points too). Also meld spawn points are working. Oddly I cannot switch exalt to my team. I've noticed that only variables that have "(TAG)" or just "()" in the decompiled sources show up in the UDK. Do you think it's safe to remove the variables that are not configurable? I've done this in some cases to reduce the volume of stub dependencies. Edited February 2, 2015 by LiQuiD911 Link to comment Share on other sites More sharing options...
wghost81 Posted February 2, 2015 Share Posted February 2, 2015 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. Link to comment Share on other sites More sharing options...
LiQuiD911 Posted February 7, 2015 Share Posted February 7, 2015 We can write new kismet objects that call xcom functions, I made a small test with custom ambience music.Now we have to figureout which functions may rebuild sightliness Link to comment Share on other sites More sharing options...
johnnylump Posted February 7, 2015 Share Posted February 7, 2015 (edited) We used this to debug an issue with suppressors losing sightlines to enemies after finishing suppression: * class'XComWorldData'.static.GetWorldData().DebugUpdateVisibilityMapForViewer(m_kUnit.GetPawn(), m_kUnit.Location); This calls a native function, but it does a lot better job of refreshing sightlines after an action than the regular sightline stuff. I'm not sure, though, that this would work -- it may only fix things for established vision-blockers, rather than establishing what blocks vision. There is also a console command "AddSightBlock," which creates a smoke volume (via CreateVolumeByType) that blocks sight. It might be kinda hacky, but a workaround could be to find a way to create permanent smokelike sight-blocking volumes but with no visible effect. There's even a deprecated volume type (eVolumeType) you could repurpose for this. EDIT: See also XGTacticalGameCoreData.EVolumeEffect_BlocksSight Edited February 7, 2015 by johnnylump Link to comment Share on other sites More sharing options...
Recommended Posts