R&D XCOM Map Alterations

[LiQuiD911]

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

[wghost81]

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

[LiQuiD911]

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.

[Zyxpsilon]

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

 

[LiQuiD911]

I uploaded the new stubs on git https://github.com/iiiLiQuiDiii/UDK

load 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

[wghost81]

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

[LiQuiD911]

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

[wghost81]

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.

[LiQuiD911]

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

[johnnylump]

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