Argument Relative Assignment Fix

Reporter: RobertBColton  |  Status: open  |  Last Modified: May 08, 2020, 01:35:01 AM

This fixes an issue with emake's drag and drop conversion that was causing argument_relative not to be assigned correctly. It specifically was making TKG's Key to Success game have collision bugs when run from emake. The problem was that JDI has a setting to treat = assignment as == comparison like old GM, which interferes with the behavior of the converted drag and drop code. LGM plugin solved this problem by using the := assignment operator, but everybody on Discord pushed me to just make it its own separate statement so it's more human-readable. With this change, TKG's Key to Success works perfectly from the command line.
>Codecov Report

Merging #1991 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #1991   +/-   ##
  Coverage   30.95%   30.95%           
  Files         197      197           
  Lines       19115    19115           
  Hits         5918     5918           
  Misses      13197    13197           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b0375a3...95209cf. Read the comment docs.


This also has the possibility to introduce regressions. Does Key to Success feature a "Question" action that is relative? You might have broken them.

  1. Do we have tests for any of this? Actual tests, not just running one game.
  2. Does this change (or a similar change) also need to be made to LGM's Action generator?

We don't have drag and drop tests yet, no, but they are needed. This change does not need to be made to LGM's action generator, no, because it uses the := assignment operator from GML, because the author knew well enough that JDI converts = to == in parentheses. That was the mistake I made, I didn't understand why := was being used in lgmplugin, and thought it looked silly.

I don't know about your first question, but I did test Key to Success against this and this makes it work the same as LGM.


IIRC, the result of an action_if_* function is used directly in an if-statement when emitting code. That's why we inlined the assignment. I am asking you if you've tested with any of those. I doubt Sam happens to be using a DND if with argument_relative.

I still don't know the answer to that, but I do believe it was specifically a question action broken in his game. Also, while lgmplugin used the result inline, emake uses the __if__ fix for "applies to" fix like GMS. The lgmplugin actually still needs that fix, however I've found issues with it IIRC which is why it's not yet merged into the plugin.
Please sign in to post comments, or you can view this issue on GitHub.