Decompiling scr_84_debug leads to problems...

[BreakinBenny]

When I opened the respective script up in Decompiled mode to fix the option intended for loading the English language file, then saved afterwards and tried to open the Debug menu in-game… it crashed on me.

This can be replicated by getting a game.win (PS4 or Switch version of Deltarune Chapter 1), opening it via a UMT application with support for editing Decompiled code, going to the script file, decompiling it, and then recompiling it and saving. The A located somewhere should now have become a À. I use a Swedish keyboard with an appropriate keyboard layout.

[Kneesnap]

What's the issue? Can you give screenshots of what's wrong and what is supposed to happen instead?

[Kneesnap]

I tried decompiling this, I don't see an "A", or a "À" anywhere.

[Grossley]

My guess it has to do with the Swedish keyboard/language configuration. Though that’s speculation.

[BreakinBenny]

Looks like I have to get another game.win so I can do a before-and-after comparison.

[BreakinBenny]

Here are some comparisons, first the original (from the Switch version) and then the edited one where I fixed it using Japanese again when pressing "use english". Chances are that the code edited for the fanmade Chapter 2 me and my pals have is strangely set up, thus leading it to not decompiling properly. (The "A" is definitely to make the debug menu accessible without needing a gamepad!) ALTERNATIVELY, the decompiler kinda goes bonkers and doesn't check for the while flag returning true.

https://pastebin.com/U2m0QDt1

https://pastebin.com/EFr9z2vL

[Kneesnap]

Can you try using this with an English keyboard setting, and see if it works then?

[BreakinBenny]

I don't have the original unedited .WIN file seeing that I never backed up the test build me and my pals had, but I can assure you this is what it was supposed to read, simplifications from the application aside...:

if process
    return (global.chemg_menu_depth > 0);
if (gamepad_button_check_pressed(obj_gamecontroller.gamepad_id, gp_stickr) || keyboard_check_pressed(ord("A")))
{
    global.chemg_menu_depth = 1
    global.chemg_interact = global.interact
    global.chemg_yoffset = 0
    global.interact = 0
}
if (global.chemg_menu_depth > 0)
{
    parent = global.chemg_menus
    var change = 0
    var depth_ndx = (global.chemg_menu_depth - 1)
    var i = 0
    while (true)
    {
        var choice_ndx = global.chemg_menu_indices[i]
        var choice = ds_list_find_value(parent, (choice_ndx * 3))
        var choice_data = ds_list_find_value(parent, ((choice_ndx * 3) + 1))
        var choice_name = ds_list_find_value(parent, ((choice_ndx * 3) + 2))
        i += 1
        if (i == global.chemg_menu_depth)
        {
        }
        else
        {
            parent = choice_data
            if 0
            {
            }
            else
                continue
        }
    }

I'd say the letter A turning into an À is the least concern at the moment.

[colinator27]

Can you please give more simplified reproduction steps... I literally have no idea what the problem is here...

[colinator27]

The only issue I can see is with the loop, which is already a known decompiler issue. We're hoping to rewrite the logic (along with the rest of the decompiler) soon/eventually.

[BreakinBenny]

@colinator27 Thank you. And as I said, that previous issue that may relate to me using a Swedish keyboard language setting is the least concern at the moment, since it could easily be fixed. Maybe if UMT had the option to not automatically simplify the decompile code (or anything of the sort, as I view it), I could revert to before that while loop went bonkers.

[colinator27]

Not automatically... simplify the decompiled code? What do you mean by that?

Right now it's just that it doesn't detect the loop type properly. while (true) only happens when it gives up, if I recall correctly.

[BreakinBenny]

I'm referring to the code being saved the way it is, without stuff like automatically making one-line IF or WHILE conditions having the opening and closing brackets { and } being omitted (and that includes this while loop going from while (true) to while 1). It could be made optional, much like editing in Source mode on Wikis instead of using a visual version meant to make things simpler.

[colinator27]

That is simply a side effect of recompiling it. As I said, while (true) occurs when the decompiler basically gives up on determining the loop type (that text is hardcoded into it). Once you recompile that, it actually becomes a while true loop, but since the decompiler can't really detect booleans well, it just becomes while 1. If it was actually a while (true) loop, then it would be while 1 from the beginning. It's just an issue with our loop detection is all.

[colinator27]

Is this still an issue, or is it resolved now?

[Kneesnap]

I believe so

On Sat, Apr 4, 2020, 10:03 AM colinator27 notifications@github.com wrote:

Is this still an issue, or is it resolved now?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/krzys-h/UndertaleModTool/issues/200#issuecomment-609058690, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSCIYKGJLEWTANAARUWHL3RK5R5TANCNFSM4H3W6LMA .

[Grossley]

Is this resolved?

[Miepee]

Seems to be resolved. From what I gathered, the biggest issue here was "code not saving as I want it to be" which was fixed with the introduction of profile mode.