New tool available that recalulates the jump offsets automatically

[Bertilsson]

Actually that makes perfect sense!

After I deleted the multiplayer code UE Explorer refused to give me a new token view data to use in my tool since I had failed to remove a 07 token and before I realized that was the problem I changed the header to see if that was the problem and forgot all about it.

Edited July 27, 2013 by Bertilsson

[Amineri]

I just gave Bertilsson's new tool a spin, and the initial test was a success.

 

I was modding just a small part of the debrief code so that upon returning from an alien base mission the mission's country entry was displayed instead of the continent (as in vanilla).

 

The function in question was XGDebriefUI.UpdateCouncilDebrief

 

The original decompiled code was :

            if(kHQ.m_kLastResult.eType == 6)
            {
                kContinent = Continent(kHQ.m_kLastResult.iContinentTarget);
                kTag.StrValue0 = kContinent.GetName();
                // End:0x68C
                if(kHQ.m_kLastResult.bSuccess)
                {
                    strFeedback = class'XComLocalizer'.static.ExpandStringByTag(m_strAlienBaseFeedback, kTag);
                }
                // End:0x6C7
                else
                {
                    strFeedback = class'XComLocalizer'.static.ExpandStringByTag(m_strAlienBaseLoss, kTag);
                }
            else

Ideally I would have just changed the first two lines to :

                kCountry = Country(kHQ.m_kLastResult.iCountryTarget);
                kTag.StrValue0 = kCountry.GetName();

However, the XGCountry.GetName function call is 1 byte longer because it has an optional parameter for the "possessive" version (e.g. China vs. Chinese).

 

So, I had to combine the two lines together into :

	kTag.StrValue0 = Country(kHQ.m_kLastResult.iCountryTarget).GetName();

Since the function itself was quite large, I wanted to replace only this small portion relating to the alien base mission case.

 

I don't think that the tool knows how to substitute using dummy variable calls instead of 0B null-ops, so I had to add those manually.

 

It was however able to automatically find and correct the one jump offset that was incorrect, yielding final decompiled code of :

            if(kHQ.m_kLastResult.eType == 6)
            {
                kTag.StrValue0 = Country(kHQ.m_kLastResult.iCountryTarget).GetName();
                // End:0x67A
                if(kHQ.m_kLastResult.bSuccess)
                {
                    strFeedback = class'XComLocalizer'.static.ExpandStringByTag(m_strAlienBaseFeedback, kTag);
                }
                // End:0x6C7
                else
                {
                    strFeedback = class'XComLocalizer'.static.ExpandStringByTag(m_strAlienBaseLoss, kTag);
                    kTag
                    kTag
                }
            }
            // End:0x91C
            else

[Bertilsson]

 

I don't think that the tool knows how to substitute using dummy variable calls instead of 0B null-ops, so I had to add those manually.

Yes that is correct.

But I'm not sure I follow why the tool should insert anything else than 0B.

It only use them to expand storage size and since memory offsets are recalculated there should be no need for fillers of any other nature?

[Amineri]

 

Yes that is correct.

But I'm not sure I follow why the tool should insert anything else than 0B.

It only use them to expand storage size and since memory offsets are recalculated there should be no need for fillers of any other nature?

 

 

Technically you are correct, it's not needed.

 

However, the example function I gave, XGDebrief.UpdateCouncilDebrief is 3588 storage bytes long. Of that, I was only replacing 244.

 

The reason I try and replace only small snippets of code when I can is to maintain maximum compatibility between different mods. If two different mods (even two of mine) both end up modifying the same UpdateCouncilDebrief function, if I've overwritten the entire function then the two mods can't be compatible without manually creating a combined version.

 

By changing the smallest piece I can, as long as the two mods are changing different parts of the same function (for example if one was modifying base missions and one modifying council missions), then the two mods have a much better chance of working together.

 

As I said, not technically needed, but I do it to try and cut down on possible work in the future.

[Amineri]

Also, would it be possible to add into the section currently labeled : "Not sure what to do with this area" what the broken down hex code would look like? It's not a huge deal, but would save a step when producing the broken down hex code I keep in my notes, with the corrected jump offsets.

 

If not, I can always pull it from UE Explorer after putting in the new hex code.

[Bertilsson]

I'm currently thinking a toolboks mod would fit nicely in that box...

However it would be very simple to add the "target hexline" as part of the text-output below the boxes.

 

But I suspect that you are probably more interested in the originating hexline where the jump token itself is located and is the one actually being modified?

[Amineri]

Well, here's my reasonining behind my request.

 

I try and keep up-to-date broken down hex for all of my mods, including corrected jump-offsets. That way if I have to change a straightforward value, I can just change it.

 

I had to do this with the example above, as I needed to change the function call : GetName(); with .GetNameWithArticle(true); (just to pretty it up, because it was missing the article 'the'). Everything was the same size so I just put in the new function call, re-condensed my hex code, and was done.

 

It's not really a huge deal if it's a lot of trouble to output the expected UE Explorer token view output (with corrected jump offsets).

 

--------

 

On a side note, if EliotVU were to happen by, I hope he's aware of how incredibly useful the new token view is :)

[Bertilsson]

It would offer some consistency...

Old Old

Mod Mod

New New

 

I will definitively keep it in mind and if it does not seem to painful to implement I will probably do it.

 

On top of the list of things to fix right now is the 0A 00 00 bug, adding buttons for undoing individual changes, rewrite the header calculation... But even more on top is fixing larger squad size so that I can play Long War mod on classic or impossible and almost not feel like cheating :P

[Bertilsson]

I've been using the tool myself the last few days and have discovered and addressed a few logical weaknesses which it suffered from, preventing it to resolve multiple foreach loops.

 

Even though the tool now actually outperformes the original intended specifications, I have also come to the conclusion that it would be much nicer if it also handled jump offsets directly affected or even created by your mod.

 

Right now I'm considering the following design:

 

Use modified view tokens to find all existing jump tokens in modded code. (Based on the assumption that exactly all jump tokens (06, 07, 0A, 2F and 58) can be found at position 0 of the byte-strings in view tokens).

 

For all jump tokens give a drop down that allows you to select any valid target in modified code.

 

Lookup the target value in original view tokens and attempt to rediscover and auto-select in modified view tokens.

 

If multiple matches found in modified view tokens: Give an extra selector with only identified matches.

 

Present output as object code snippets with some extra information and selectors when jump tokens are present.

 

The dropdowns which are used to select targets include the targets object code line, memory offset, and line number in modified code.

 

Any obvious design flaws or suggestions anyone wants to add or point out regarding this approach?

[Bertilsson]

New Tool planned:

• One box for Byte Code with broken jump offsets
• One box for View Tokens with broken jump offsets
• One box New Byte Code with repaired jump offsets
• Object Code Presented with line numbers
  • Next to any line which holds a jump token is a drop down where the user can select any valid target Line number depending of jump token type.
  • The resulting offset is then cascaded to all following drop downs until halted by an invalid target where user must again a make selection to continue the cascading.

I expect the new tool to be very quick and intuitive to use.

Edited September 22, 2013 by Bertilsson