Saving Layouts?

Trying to think about ways I can optimize things and survive in the horrible hellscape which is 'being trapped in a CC project'. Figured if I could export levels and load them I would be able to get rid of that whole 'bloated EXE with 20 copies of the same code' issue. Fortunately if I can't deal with that, with the amount of content left to do, I'll be left with an EXE, load time and ram usage that is embarrassing, but acceptable. But I'd like to fix that.

So the biggest issue with saving anything that I'm having is variables. So plugins like S seem to be good at sucking down a bunch of stuff and saving it, but S doesn't account for object variables from what I tell? Which would make it totally unusable. Then that would lead to the situation where I would have to manually export and load all the variables on everything and that would be an absurdly unacceptable amount of work. So is this at all possible? Would I need to write a plugin to make it manageable? Could it be done in a python script?

One gross method I played with a little bit but doesn't seem stable or safe is using save states. I could get some stuff working but it seemed far too gross and broken to fully consider, but maybe? Current method involved renaming the layout to be saved as what would be the 'loader' layout and then saving it and switching the layout back. It works pretty okay in test caps but getting it to work in a full game is something I haven't tried to do yet because I remember hearing some weird things about saving and loading being a bit wonky and also this being a real hack.

So any thoughts or ideas or other hacks, here? Whatever idea has to be a pretty robust solution. If there is an edgecase there is a decent chance I'd hit it.

You probably could use python to do it. The Sprite.NumVars expression gives the number of private variables and then you can do something like this to loop over all the variables.

for i in range(Sprite[0].NumVars):

Sprite.Value(i)

The trick here is you can access a value by it's index instead of by it's name.

I don't have time to make a full solution but you can access everything you need from python. Next you'd need to come up with a way to save and load that data to and from the disk. It's not hard just takes a bit of thought.

Excellent, good to know! And I have a few people I can probably bug to try and help me with this if I have any problems. Hopefully if this ends in a clean solution, I might end up with something to share, but who knows.

My "I Had Hope" game loaded all the levels from simple INI format files, but I didn't write a level editor/layout to INI saver for it (might have an example of that in my Examples Kit download in the signature too though).

Source code to IHH alpha is up at http://ihadhope.blogspot.ca/p/download.html

I wonder about the ini thing simply because the scope is so big, level wise. Like upward of 6000 objects. I could do python to capture the variables (... can you use python on the currently 'picked' object? Somehow I doubt my life will be that simple but who knows.... evaluated python command maybe? Is there any even vaguely decent python docs on how its integrated?)

But hey I guess I can give this a try without the variables and just see it it can hand;e things with a reasonable load time.

Heeeey 9 seconds to load a level (excluding a lot of details and important variables and whatever). That's.... not good enough. And I'd say I'm on an optimal system (reading off an SSD and stuff).I'm guessing the ini plugin is the bottleneck here but who knows. I might be asking the impossible out of poor construct.

Bloated EX issues add like 20 seconds or something to the booting of the game, but that seems preferable to slow loads every death. Maybe if I do all the object attributes in single strings I can cut down on reads and speed things up. Gonna try that next.

I think this direction might be boned though because I realize there isn't a way to detect collision settings, which I use very very very frequently. =/

You can access the picked objects using the SOL object.

So say the object name is "sprite", then in Python you would loop over the picked sprites with:

for obj in SOL.sprite:

obj.x=2

There are some older posts with more details about Python that may also help. Anything accessible with events is accessible from Python, well except many conditions such as triggers can't be used in Python but that's about it.

Give me a day or so and I'll wip up an example.

Awesome, thanks everyone. Interested to see what you have in mind, r0j0

So my 'objects as huge string' experiment was massively successful. Load time is like a second or two. Gotta figure out selection too for handling things like width and height. Creating objects by name/oid doesn't seem to do selection, sadly? But I'm sure there is a way to do most recent object or something?

Anyways, works at a reasonable speed. Also sad that there is no expression for visibility either. That is a pain. (Though I guess I can work around that one fairly easily) I could wrestle some edgecases if I have to though.

I suppose I could do something goofy and set tiles that are non-colliding as like opacity 99 or something. It'd be a pain to track all that shit down but I definitely could.

Hmm, sounds like what is effectively a JSON storage format if it's all one big string, I think in that case you might find the HashTable or Binary object even faster for saving and loading it all at once (Binary object saves to encrypted file too which should make cheating harder!).

I've not tried them for this though, but the process shouldn't be too large of a code difference from your current system (HashTable might be the most event-friendly approach).

HashTable usage: example-tips-hashtable-object_t69861

Edit: Also this works for me for getting the most recently created object UID after it's created by name then applying some code to it in the next tick: https://dl.dropboxusercontent.com/u/471 ... DCheck.cap

Getting that to work with the loop you have might be a matter of doing sub-events to check what the object being created is though, so depending on all the types of objects that might be a lot of code.

Hashtable load speeds = immediate. AWESOME. This is getting quite reasonable.

Doing a few things shouldn't be too bad. I'm pretty sure sprites and tiled backgrounds are the only two object types that need to be saved.

edit: Yeaaah I can see that being a problem now. Especially the 'next tick' part (spending 6000 ticks generating a level is no go).

I'm trying to do a thing where I make another set of hash keys with like oid : x : y with all the other parameters to try and identify things and run through that list the next frame, but for whatever reason that has problems too (size mismatches on random objects and such. Enough headbanging for tonight. Especially curious if python could help with any of this. Anyways, thanks for all the help.

Ok, here's a python version.

https://www.dropbox.com/s/73o1wa4ts21uf ... y.cap?dl=1

/examples31/saveLoadpy.cap

The first script under the "start of layout" is the meat of it. It has two functions to save/load to a json file.

The first function is save. As an example it can be used like this:

save("myfile.txt", Sprite, Sprite2, Family3, tiledBackground)

Basically the first parameter is the filename and you add the object types you want to save as the following parameters. You can use as many types as you need. Sprites, tiledbackgrounds and families of either should work.

Load is simpler, you just use a filename as a parameter. For example:

load("myfile.txt")

Other nice to knows:

The file is saved in the working directory i think but if you want it to be saved to the apppath use:

System.AppPath+"myfile.txt"

If you want to only save the picked objects use SOL.Sprite instead of Sprite.

Saving tiledbackground's instance variables will crash so it's not done.

Finally there isn't a way to find out what an object's collision mode is in events so it can't be done in python.

It can't save instance variables? Thaaaaat's annoying but I guess I can work around that too (not too many that have variables, so I can just use a sprite object overlapping them on startup to give variables or something). Collision mode is annoying but like I said, I guess I could do some gross "opacity 99" or something to indicate non-colliding. Never use gradual opacities for anything anyways.

So... this is manageable! And as such, R0j0... you, as if you didn't know already, are amazing and I just have to thank you for TIME and TIME again, helping me with stuff and allowing me to get the most I can out of a project that has taken years. I really can't thank you enough for your help and support with this long dead editor. ;_;

Sadly getting a lot of errors trying to get this to work with the test implementation.

I get this when trying to save even a single object on a relatively empty layout with the game. I had to rename some stuff and kill some families to get past some other python issue s(gonna have to track down those cleaner scripts) so could it be left over from that?

Second issue... Any way to get this to work with families? It'd be way easier to add everything to a serialization family than have like a list of 700 objects or whatever. I mean, I''ll do the list if I have to, but that'd be way nice.

I'll have to work with it more. There are probably some typos and bugs I still need to work out. It should work with families as is, they just don't show up in the editor.

I'm not by the code currently but I'm curious how that index error can happen. As long as the objects are just sprites and tiledbackgrounds it should work. I'll see if I can add more error checking to give more readable errors. If you need other objects to be saved I can tweak it I think.

As far as accessing the tiledbg variables, there is a solution, but it would require some Python files to be included with your game. Basically it would access the memory directly. It could also solve the issue of accessing the collision mode.

If you want I can package up stripped down cap of a stage with my current implementation of it. for testing?

Families "work". If I make a new sprite on your test and throw them into a family and save the family, it "works" but it doesn't get the individual objects right (Like having a bunch of grey boxes and a green box in a family, it'll save, but all the boxes will be grey boxes when it loads).

As for accessing memory --- requirements aren't a big deal and if you're willing to do that, that'd be AWESOME but they are things within my power to work around so if it's a pain in the ass for you, well... just know they're not problems that are going to muck me or anything.