Can I Save A Frame Position To A File?

[schrodinger]

You want to save positions each time you go to the menu right?

I think you just need to use previous approach, adapted to this situation,
like, simply, on line 12:

(button save clicked)
+OR
+upon pressing "ESC"

this would trigger saving also when you press "ESC"
thus (since it comes before the jump to frame condition in event list)
just a moment before jumping to "close" frame

[JBoneCode]

I see what you mean, and it does work in the Bug Testing version. However, it still doesn't want to work in the real Application.

I'm not fantastic at code analysis, but there has to be something wrong with the saving or loading of the X/Y Positions. Whether it's saving and not loading, or not saving resulting in nothing to load. I'll look back through the events of the Demo program to compare. Because, it should make logical sense right now. When the User Presses "ESC" --> save data. User collides with Group.Helpful --> save data. Health Counter = 0 --> save data. Start of Frame --> load data.

[JBoneCode]

Additionally, I was looking at the Bug Solving .mfa and transferred the On Load Button click events to the Start of Frame event, and it no longer works.
Since this is my loading method, would this have something to do with it?

[schrodinger]

I wonder if the issue may be due to this:
if you set the load action at "start of frame", it should anyway work

BUT

in your example (wonder if it's the same in the full app?)
the "start of frame >> draw grid" code is placed after the loading code

thus, this will happen:

start of frame>> load and place tiles

start of frame>> draw grid

in this way, the grid will be drawn after >> above the tiles, this is why you may be not seeing them!

You can easily test this just by switching these groups positions (create grid before loading tiles),
or adding a always >> bring to front for block tiles

[JBoneCode]

I really thought we had solved it. However, my Grid generation is one of the first things in the Event Editor, and the Saving/Loading one of the last.

This once again works on the Bug Solving version, but my version is stubborn as always.
There has to be some other problem with the code transfer that I'm missing.

[schrodinger]

Oh man, this time I thought we were finally onto it
100% sure you don't trigger the grid creation loop before the load loop?
(the important part is the triggering: start of frame >>> create grid
onloop events may also be below, but the grid loop must be fired before the loading loop)

I guess at this point we should need some divination code to guess what may be wrong without being there
(but also Teamviewer may provide similar parapsychological powers )

Maybe a screenshot of your main load/save events?

Are those the same I can see posted above?

[JBoneCode]

I did make a few changes, here is the most up to date code:

SaveLoad v3.JPG

SaveLoad v3 (2).JPG ***You can ignore lines 105-109. I added this to the "OR" statement above, so there is no Saving in this area anymore.***

SaveLoad v3 (3).JPG

The Grid Creation Loops take place right at the Start near the top of the Event Editor. (I double checked.)

[schrodinger]

Spotted something, line 111: you must set the file before starting the "Load bricks" loop
(invert first two actions, and push before the loops the "set group" also),
otherwise this won't find the "number_of_blocks" times and fire the loop 0 times!

[JBoneCode]

It's about time!

Thank you so much, schrodinger! The issue is solved! I can finally start tackling some other smaller bugs. (That are thankfully not game-breaking!)

[schrodinger]

cool!

best luck with your other bugs then