Printable View
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
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.
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?
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
I really thought we had solved it. XD 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.
Oh man, this time I thought we were finally onto it XD
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 XD)
Maybe a screenshot of your main load/save events?
Are those the same I can see posted above?
I did make a few changes, here is the most up to date code:
Attachment 19401
Attachment 19399 ***You can ignore lines 105-109. I added this to the "OR" statement above, so there is no Saving in this area anymore.***
Attachment 19400
The Grid Creation Loops take place right at the Start near the top of the Event Editor. (I double checked.)
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!
It's about time! :O XD :D
Thank you so much, schrodinger! The issue is solved! I can finally start tackling some other smaller bugs. (That are thankfully not game-breaking!)
XD
cool!
best luck with your other bugs then ;D