428 replies to this topic

[dubiousintent]

There was a re-compiler that people were using up until around November, when a cease-and-desist order was issued to halt distribution of the re-compiler. I guess it stepped on someone's toes?

 

I haven't seen a upk re-compiler that allows putting the pieces of upk code back together again since.

Hmm.  Now that we have figured out how to disable hash checking, has anyone confirmed that the decompressed UPK still has to retain the same size?  Isn't the game engine reading from the decompressed (but still packed) loose UPK file?  Isn't that being handled in the same manner as the DGC.INI, which now can be larger?

 

-Dubious-

[Amineri]

That's the tightest starting area that I can recall.

 

The main trick will be trying to figure out which direction is the safe one.

 

I'm wondering what the layout order is for the soldiers, and if it's consistent.

 

Is it something like :

3  2  1
6  5  4

If there is a consistent layout then soldiers 7-10 could be placed in between the existing soldiers, with position found just by averaging, e.g. position 7 = (1 + 2 ) / 2. That would give safe positions for up to 10 soldiers per map.

 

Even for those maps where the soldiers are staggered there is a function that returns the closest tile position, so each soldier should end up correctly placed into a tile.

[Amineri]

 

There was a re-compiler that people were using up until around November, when a cease-and-desist order was issued to halt distribution of the re-compiler. I guess it stepped on someone's toes?

 

I haven't seen a upk re-compiler that allows putting the pieces of upk code back together again since.

Hmm.  Now that we have figured out how to disable hash checking, has anyone confirmed that the decompressed UPK still has to retain the same size?  Isn't the game engine reading from the decompressed (but still packed) loose UPK file?  Isn't that being handled in the same manner as the DGC.INI, which now can be larger?

 

-Dubious-

 

 

My understanding is that it's not the size per se that is the issue, but there are tables and tables where things reference each other in the code. Tables of functions, tables of variables, tables of names. All of these table references have to be preserved or else rebuilt / fixed. I'm pretty sure that when the game runs it decompresses the upks on-the-fly into memory.

 

However, I'm not really an expert at Unreal Engine code (despite my successes with mucking about with the XCOM code, I've had no actual training or other experience with programming it).

 

There definitely could be some way to re-work the code, but I'm just not aware of it.

[Bertilsson]

If there is a consistent layout then soldiers 7-10 could be placed in between the existing soldiers, with position found just by averaging, e.g. position 7 = (1 + 2 ) / 2. That would give safe positions for up to 10 soldiers per map.

 

Even for those maps where the soldiers are staggered there is a function that returns the closest tile position, so each soldier should end up correctly placed into a tile.

In the research outpost council mission there is a telescope with soldiers spawned like this:

        S <--  a spawnpoint

   XX <-- telescope

   XX <-- telescope

S <--spawnpoint 0

 

See this link for further details: https://www.youtube....haGce0#t=00m58s

[johnnylump]

Urg, if I had been smart I would have highlighted the grid when I took the rooftop image.

 

Here's the layout:

 

X1_S_S_X

XS_S_S_X

 

X = blocked

1 = first soldier

S = other soldier

_ = accessible space

 

So I propose soldiers 7-12 be placed to the right of the first 6:

 

X17SNSNX

XSNSNSNX

 

7/N = New soldier

 

Based on that video, should work with the telescope, too, although the video only shows a 5-person squad, and spawn point 6 is uncertain.

[Amineri]

When I was in the same mission JL's screenshot was taken, but with 4 soldiers, the initial Soldier layout was:

X1_S_S_X
XO_S_O_X

X = blocked

1 = first soldier

S = other soldier

O = open spawnpoint not occupied

 

I definitely know that a vector offset of length 96.0 from the existing spawnpoints is the location for the new  spawnpoints. The question is : Which direction?

 

Some maps like the small UFO swamp map have three different skyranger locations, and the orientation of the spawnpoints is not the same for each of them:

 

Here's a screenshot I took of the map after using the "\set actor bhidden 0" command, which sets every actor in the level visible. This sometimes crashes my game on UFO maps, just as a word of warning.

 

 Small Scout showing three dropzones 2.jpg   207.65KB   2 downloads

 

You can see that 2 of the dropzones are oriented in the same direction, but the 3rd is along another map edge and so is rotated 90 degrees with respect to the others. This means that the direction "right" for the soldiers is also rotated 90 degrees.

 

I'm trying to understand where soldiers 1 and 2 are in as many cases as possible. If soldier 1 is always in the "upper left" of the squad (soldier 1 should be in the 3rd position in the squad select I think?), and if soldier 2 is always in the front row as well, the we can use a direction vector from soldier 1's spawn to soldier 2's spawn, but renormalized to distance 96.0 as the offset from each spawnpoint.

[Bertilsson]

Maybe the key to direction is to be found in kSpawn.Rotation?

kSoldier = SpawnUnit(class'XGUnit', m_kPlayerController, kSpawn.Location, kSpawn.Rotation, kChar, m_kSquad, kSpawn);

I guess that if you can query that value it should make the question about which direction a lot easier as it probably is what dictates what is forward from the soldiers perspective at spawn.

[TheOldOne822]

So far everything I've done has given me an inventory list that will not show in game. Even decompiling and recompiling with no code change to the same flash version used doesn't work. My Flash training is useless if I can't compile the code at all and have it run.

[Amineri]

So far everything I've done has given me an inventory list that will not show in game. Even decompiling and recompiling with no code change to the same flash version used doesn't work. My Flash training is useless if I can't compile the code at all and have it run.

 

What I've had to do is make the changes to the Flash code, then identify those portions of the resultant compiled hex that have changed. Sometimes the compiler will change some stuff not related to the code I just re-compiled, so I've had to really figure out the core of what is actually changing, and prepare just that section for hex replacement within the command1.upk.

 

Within command1.upk, the actionscript is actually run using the Unreal Engine's GFX engine, so the embedded file's header starts with 'GFX' instead of 'SWF'. That's part of the process of finding / extracting the actionscript from the upk in the first place. Otherwise there aren't any tables that reference any portions within a single embedded actionscript file.

 

I've been able to take bytes from one block in order to add them to another. In order to create the Perk UI mod, I reduced the size of some of the strings in the 'Environment' package (and then adjusted the declared size of that block) in order to increase the size of the block containing the abilitytree sprite. I picked the Environment package just because it was closest to the Sprite definition which required the smallest hex block replace.

 

I'm guessing that the size of the hex must be staying the same or the game wouldn't run at all.

 

My issue was that none of the changes I made had any effect at all. The inventory list still showed but no scrollbar would be added.

[johnnylump]

Here's the original thread discussing editing ActionScripts ...

http://forums.nexusm...272-ui-editing/