Putative solution for GUI slot trigger calls present in 2020.4

Started by kreatorKen on Wed, 08/26/2020 - 15:21

Topic category: Troubleshooting, bugs, and solutions

Last seen on 07:39, 14. Oct 2021
Joined Aug 2020

User statistics:

  • Modifications:
  • Forum topics:
  • Wiki pages:
  • Tracker tickets:
  • MCreator plugins:
  • Comments:
Putative solution for GUI slot trigger calls present in 2020.4
Wed, 08/26/2020 - 15:21

Based on the advice I have been given, I have decided to report the GUI slot trigger calls in 2020.4 as buggy. Here is the summary of my observations: https://mcreator.net/forum/65775/procedure-calls-slots-guis-cross-call-each-other which illustrates the cross-trigger calls from the slot object. I have some solutions that could help the problem.

Basically, what I think is happening is that the core code is calling an “on click” trigger when the GUI opens and when the slot is clicked, and that is why the “On change” is called also for the other two slot triggers as well (since they are also being changed). I still think opening the GUI should not call the slot triggers, but my solution below would handle that too.

First, remove the other two triggers and only keep “On Change”. The other two types can be accessed programmatically using the mCreator Procedures.

My main solution is to request a new internal item object in the core engine, one could call it “slot, last item”. Then make a new get block which gets “[get last slot [id] item]” whereby, whatever is (currently) in the slot is called by the normal [get slot [id] item].

To test for a change, we might do something like this:

If [last slot item] == [current item]  -> no change, do nothing.

But, in this regard, I think the mCreator procedures don’t let one pass, i.e. there is not a [pass] block (?right?). I would also ask for making a [pass] block, but I guess on the other hand to avoid that, one can do:

if [last slot item != [current item] –> means something changed

so we don’t need a pass block and we don’t care if the GUI calls the slot “on click” trigger (presuming that is right) either, as we can test for it. For the shift-click, we just do a normal capture using the Procedure coding blocks. Movement of the item back to the users’ inventory can also be handled using the Procedures too.

In an If-then block Procedure then we have:

If [last item]       ==          [current item] then Do …

Air/empty          ==          item-X                 item was added

 item-X                ==        Air/empty         item was removed

 item-X                ==        item-Y                 itemX removed, item-Y added.

 Item-X                ==        item-X                 no change (air/air also no change)