Rewriting Scripts

[twinj]

I gather we can't make bigger functions because each function's location in the upk is referenced in a bunch of other places, so all functions have to stay at the same starting point?

 

But smaller ones are OK because we can pad out the function with null statements. Is my understanding correct?

That's my understanding of things currently too. Being able to "move" the starting location of a function+header would be very helpful!

 

twinj, do you know if this is/isn't possible yet? Are we able to update the places that reference the function+header position? :)

 

Follow-up:

 

Can we add parameters to existing functions? One workaround to make longer scripts is to find some unused function or debugging function, rewrite it, and call it from the main function we're trying to edit. If that's workable, next step would be catalog these functions.

 

Yeah I thought of that as an alternative. Some functions could be completely cleaned out. Arrays can be lengthened to store data and saved as params. In fact i was using this technique when rewriting for squad sizes. Cannot add new params though as that will screw with how upk files are parsed through the exports. Would have to rewrite the whole upk. Currently an index to an object 'say a class' will point to all of the functions and its children which are other exports. Changing the params adds new children which screws with numbers of all other exports and children after that export. Mostly the children are in order. Same issue as size.

 

Imports are an even bigger issue as these work across upks...

[johnnylump]

What's the shortest null statement you've implemented (with the function still otherwise working)? Hopefully a one-byte statement?

 

I'd like to clear space in a couple of functions before inserting new code.

Edited January 26, 2013 by johnnylump

[Tayot84]

256 characters equal 1 byte

 

well, actually it depends on what language you use

 

but I think that will work for us

[Drakous79]

Thank you twinj :thumbsup: Great info!

 

Following this and Script Headers topic for some time, but I'm too lost in reality atm.

[johnnylump]

@ Tayot84

 

I'm not sure I follow you. What I'm asking is in the context of rewriting the hex in functions in the upk files.

 

What I'd like to do is find script sections I can get rid of, and replace them with meaningless coding that X-Com will always ignore. Then I can overwrite the meaningless code with new codes to add functionality, and I'll always know how much space I have to work with. The fewer bytes the meaningless code is, the easier it will be.

 

@ Drak

 

Missed you lately! I've been hoping you can crack some stuff I'm stuck on.

Edited January 26, 2013 by johnnylump

[Drakous79]

Johnny :) I'll be cracking some wood against my head in an attempt to prevent my little daughter from falling downstairs. Wooden fence and my poor carpentry skills gonna take 3 days or more. And looking for new job simultaneously takes too much time, I can hardly play or research.

[twinj]

I have added one byte 0B's in code to null out stuff. Generally it is more than one to keep the size correct. You can add them anywhere but keep in mind this can stuff your jump values. I like to remove code and replace it with 0B's so the jumps stay ok. If you removed index reads you have to adjust the jump by -4 each read and whatever was removed as bytes if you did not add 0B's. You can still fixed stuffed up jumps so you should be able to null out anywhere, even 1 byte. I like to append all 0B's at the end of the function once i know its working and then rewrite the jumps.

 

Essentially you can null out full functions using 0B's but you must change the virtual size to match the actual size so it loads correctly.

 

I was looking for functions to do this with so they can be used as proxy's for whatever.

[johnnylump]

I have added one byte 0B's in code to null out stuff. Generally it is more than one to keep the size correct. You can add them anywhere but keep in mind this can stuff your jump values. I like to remove code and replace it with 0B's so the jumps stay ok. If you removed index reads you have to adjust the jump by -4 each read and whatever was removed as bytes if you did not add 0B's. You can still fixed stuffed up jumps so you should be able to null out anywhere, even 1 byte. I like to append all 0B's at the end of the function once i know its working and then rewrite the jumps.

 

Essentially you can null out full functions using 0B's but you must change the virtual size to match the actual size so it loads correctly.

 

I was looking for functions to do this with so they can be used as proxy's for whatever.

 

Great, just what I was after. (I think I follow on virtual size; if not, I suspect I'll post here again). Thanks. I'm going to try a few things -- randomize grenade damage, give to-hit bonuses to interceptors based on kills, buff early aliens after several months, buff small UFOs after several months). Seems like the biggest challenge is finding space to work inside small, efficient functions ... and spare functions to overwrite.

 

@ Drak -- I've been there. Our boy is about to start crawling, which mean the safety gates have to go back up. Good luck.

Edited January 27, 2013 by johnnylump

[johnnylump]

Hrm, all right, still learning.

 

Edit: I've changed a function and removed one function parameter-less call within it, and removed one if-else statement (which inlcuded a jump). This required subtracting four from all jumps with a destination after the function call to work. I've used 0b to fill in byte gaps. Must I also reduce the VS by 4 as well? (Or will the function just take a little extra memory if I don't?)

 

Was it the jump or the function call that added the four bytes? If it was the function call, if I had removed a function call with three parameters, would the size go down by four or sixteen?

Edited January 30, 2013 by johnnylump

[twinj]

Hrm, all right, still learning.

 

Edit: I've changed a function and removed one function parameter-less call within it, and removed one if-else statement (which inlcuded a jump). This required subtracting four from all jumps with a destination after the function call to work. I've used 0b to fill in byte gaps. Must I also reduce the VS by 4 as well? (Or will the function just take a little extra memory if I don't?)

 

Was it the jump or the function call that added the four bytes? If it was the function call, if I had removed a function call with three parameters, would the size go down by four or sixteen?

 

If it is a final function i.e 1B do not count index reads unless it is obvious they are only four bytes long as some index references here are already 8 bytes long.

 

If it is a 1C call these need to be counted. Jumps are not counted as reads.

 

The best way to understand the counting is to also look at the statements list provided by UE Explorer. Each statements is shown and its reads are shown with their respective decimal positions. All jumps will always go to the beginning of a new statement. You will have to convert them to hex positions.

 

If you removed a four byte index reference the virtual size will have to be reduced by 4.

 

reduce VS