Can I Save A Frame Position To A File?

This questions may/may not have been asked before, so sorry if it was. I looked through the "Similar Threads" section, but none seem to help me.

I am currently making an application where the player can modify the world. I am using "Save/Load Frame Position" to accomplish this across frames, but obviously, when you close/reopen the application, all saved progress is gone.

So my question is, can I save the frame's position to a file somehow? And then reopen this save when the user loads the world?

Thanks for the help!

Sure you can ;)
you may have a look at "ini", "array" (the most widely used save-file objects)

in short you need to save a file with the frame number you're currently in,
in order to restore it later

there are surely many threads around talking about inis and arrays as save-mediums
in short: inis are easier to use (probably) and easier to crack, very slow (but speed is not an issue in your situation)
arrays are more flexible and powerful, a bit harder to crack, harder to use for starters

if you need something more secure, you'll have to look at encryption or anti-file-corruption methods

if windows only, you may also consider the "named variable object", has a builtin file encryption feature that would make your save file pretty safe

Thanks for the suggestion, schrodinger. I have looked at Ini, Ini++, and Arrays. My game is a sandbox-style game, and the user can manipulate a lot of aspects of the world. Would I have to save the position of every group of objects that I'm using to, say, a .ini file? For example, the Breakable Group, and the Landscape Group? Or is there a way I can use the "Save Frame Position" event and just save the frame's position to a file?

Look in the Guides, Tutorials, Examples, Widget forum. There are a few examples that Sparkman made using the INI object. Works perfect. I made a simple save position of an object/character if you need it.

Edit: Here is exactly what you're looking for: http://community.clickteam.com/threads/95869-Undertale-Save-Game-Tutorial?highlight=save

Thank you so much KLiK-iT! As of right now I have the positions saving/loading! This project uses a lot of new things that I've never done before and .ini was one of those things. I'll post back here again if I begin to have troubles, but as of right now, all is great! :D

That's great JBoneCode..!!

Yay.....another issue...:(

I am trying to have a "Delete World" function, and I cannot get the Frame to restart from scratch. I have tried using multiple .ini files(one for saving the initial positions, one for saving every time you leave the Frame), as well as the File Object to delete the .ini file itself.

This issue, as well as another issue are the only things keeping the Save/Load from being 100% successful. The second thing is it won't save the position of the placed blocks, (group.Breakable), when it originally did. I checked the Groups of the objects and they appear to be the ones I have desired to be saved.

I'm so close to getting the Save/Load thing done so I can move onto other, smaller bugs.

Here is the picture, and since there is a lot of code, I can re-upload another set of images in 2-Parts if this is too small. Thanks again!
Attachment 19273

---UPDATE 1---
I fixed the Delete World issue, it turns out the File Object worked better on another Frame. However, I still need help with the group.Breakable issue. Thanks!

Here are the images of my updated code. It should be easier to read now.

Attachment 19281
Attachment 19282

Bump.

I'm sorry to do this, but my game heavily relies on this feature.

All suggestions are appreciated! :)

Sorry just to clarify:
you need to save "breakable" group positions - but your ini doesn't save them?

While it correctly saves other groups (foreground, physical etc.)?

Hard to say without having a look at the code - can't see anything odd in the events you pasted
this may have to do with something else possibly..?

Sure you're not mismatching .inis since you said you're using more than one
(in the file saving / file loading action...?)
or are you using a single ini with more than one "files"
(you change the file name or set multiple ini objects?)

Quote:

---

Sorry just to clarify:
you need to save "breakable" group positions - but your ini doesn't save them?

While it correctly saves other groups (foreground, physical etc.)?

---

Yes, I need the Group.Breakable positions to be saved. These are the blocks that the user can place. The event is a Create object event earlier in the code. The other Groups save fine.

Quote:

---

Hard to say without having a look at the code - can't see anything odd in the events you pasted
this may have to do with something else possibly..?

Sure you're not mismatching .inis since you said you're using more than one
(in the file saving / file loading action...?)
or are you using a single ini with more than one "files"
(you change the file name or set multiple ini objects?)

---

Sorry, I should have made this more clear. I was using two .inis when I was trying to figure out the Delete World function, but I have fixed that issue with the File object, and am now using only one .ini.

Can see no reason why it shouldn't work - particularly because other groups save fine and you deal with all groups in the same way!

You can't obviously share your file?
Maybe stripping down extra things and leave only the bug with just a few objects to test?
(this procedure sometimes leads to finding a solution also XD)

I'll try this strategy out, and if it doesn't work I might post the .mfa. I hope it works! XD

Here's the simple .mfa. It's how the real game functions, except I save the positions when you leave the Frame, not when you click a button. The saving/loading of the "statue" works, but the Group.Breakable once again, doesn't save.

Attachment 19313

I see.. the issue is due to all the objects having same name (being multiple instances of the same object)

So you should try a slightly different approach for bricks, see example:

Attachment 19314

Thanks schrodinger. Since things are working in the .mfa I expect them to work in the real game. However, I have multiple blocks in the real game. Would I copy the Event:

On loop load_bricks:
ItemValue( "position_saver", "Random_block_X" + Str$(LoopIndex("load_bricks" ) ) )
ItemValue( "position_saver", "Random_block_Y" + Str$(LoopIndex("load_bricks" ) ) )

Into every block the same, or would I have to change anything specific in the event?

Thanks for all the help, we're almost there! :D

You have different block types right?

Then I would slightly change the code,
can think of two solutions:

1) manage different block types inside the same active object ("Random_block") just by saving their different appearence in different animations,
than set a value in each block to store its block_type
save block type in the INI: ItemValue( "position_saver", "Random_block_TYPE" + Str$(LoopIndex("load_bricks" ) ) )
load block type when you create the object
and on any block creation force animation to block_type

2) manage different objects with same qualifier and save each of different types with their respective names (make all names same length)
(fire different foreach loops for each type)
save "block_name1", "block_X1", "block_Y1" in the INI
then on loading you can use "create by name" --- expression --- left("block_name", number of characters of name length)
and then place object X,Y position referring to its qualifier

if you need I can make an example of solution 1 or 2
(but tomorrow.. now have to go! :()

Hey schrodinger, thanks once again for the help!

I think Solution 1 would be the best for my game. An example would be great if you have the time, because I want to make sure I input the events correctly.

Ok, here's an example:

Attachment 19326

you can right-click the template to change block type
I've made 5 block types (different increasing animations) you can make as many as you want
just make the animation "looping" to make it remain active
(or else you can "always --> force animation to block_type", whatever you prefer)
Block "type" will be stored in alt. value block_type of random_block object

Since we're using only one block, there's no need now for the block qualifier, I've removed that

for any question drop a line!

I almost have the Save/Load features working entirely, except for two issues:

1) When I leave the World Frame and reload it, the textures reset to the "NoBlock" texture.
2) When I close the Application and reload it, the positions don't save.

I'm hoping this is just some mis-transferred code. Do you know where the source of error could be/what events could be causing this? Thanks!

1) in the latest example this is working correctly, so maybe something slipped off during the code transfer
you should make sure that:
a) all your blocks get a "block_type" on creation
b) when you save your blocks you also save "block_type"
c) when you load your blocks (destroy all current blocks - recreate all blocks from ini) you also set their "block_type"
d) you always change block animation to "block_type" / OR change it on creation and set texture animation to "looping" (otherwise they will change and return to "stopped")

2) you mean that the application should auto-save content when you close it?
You can do it pretty quick just by adding:

(button save clicked <-- your existing save condition)
+OR
+end of application

to your "save button" clicked event

you can find end of application / end of frame conditions in "storyboard" controls, along with "start of frame"

ORs are another thing I haven't used often. Would this be a filtered or logical operator?

Also, I have the Save occurring when I leave the frame, and the Load occurring at the Start of Frame. Would this affect anything?
Here's what I have:
Attachment 19360
Block Creation

Attachment 19361
Changing the Animation of the "Template", or the Active you would click on to change Block Types.

Attachment 19362
Loading Data

Attachment 19363
Saving Data

Attachment 19364
Saving/Loading Loops for the Blocks

Sorry to be dragging this Thread out so long. I know there are other issues that need attention, so I want to hopefully wrap this up!

You can go with any OR, in this situation would be the same.

On the loading issue:
maybe I spotted something on the very last line of last image,
you seem to reference a different INI file (has a "shortcut" icon differently from the ones above)
this could explain why loaded blocks have no "block_type".

If this doesn't solve the issue,
there's something I can't clearly grasp on the loading codes,
you're clearly doing something specific basing on global values A & T but don't know what X)

Thanks once again! ;D

The positions AND block type of the blocks are saving and loading between frames. However, the "End of Application" error is still present. Could it be due to a missing "Set File to [...]" Event? I also tried adding an OR operator to no avail.

Also, the Global Values are when you return from a specific frame. EX: T would set a Group's position outside of the Frame because it would be unused further.

Set file should be needed just one time per frame (before any operation), as long as you always use same file

I've just tried the "end of application" code on previous uploaded example and seems to work fine,
how are you "shutting down" the application? Through events or through Windows "close" red X button (or both?)

If you do this through events (like button pressed --> close application)
you can maybe try:
button pressed ---> save stuff ---> close application
?

Hard to say what may be wrong!
Can you recreate this not-working on the example above?

I was doing the "End of Application". Although, I feel like a Clickteam Noob with this mistake. X)

I was thinking, "It will save when the application ends...on any frame". I have it set so the Close Button in Window Settings is disabled, and the only way to close the Application is to go back to the Main Menu.

Would I have to mess around in Global Events? Or, is there some other way I can accomplish this in the World's Frame?

If you use qualifiers you can't set this in global events unfortunately,
as qualifiers can't be used in global events

Guess the most practical way (beside not using qualifiers) would be hard-coding this on each frame
(put all code inside a group and copy-paste this group through frames)

You can try "end of frame" events,
or simply embedding the save code into your "go-to-menu" button
(user click "go-to-menu" ---> save stuff ---> go to menu XD)

I was testing out the actual landscape objects, and these save fine when I close the Application. Could this point to an issue just for the block's saving then? Also, since the only things with qualifiers now are the landscape objects, would this open any potential for Global Events again?

Hard to say without inspecting the code,
I would try testing step by step
and see what/when goes wrong - single action at time

You see, this is working fine in previous file:

Attachment 19384

so it should work in your official app as well...

I think this .mfa file sums up my issue. You close the game on another frame. If there is no simple way to save the files in this way, what would I need to "hard-code" into each frame, and under what event? (End of Frame, End of Application, etc.)

Also, I tried rearranging the order of code in the actual Application. It didn't have any effect, unless there's something specific that needs to go first in the Save Events.

Attachment 19398

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