That's wild that even works.

Okay I am left with one question!

So if you take my example cap and change it to save "Latern" and you load the lantern... the size of it is all mucked. The width gets set to a value that makes no sense (18.somothernonsense). I thought it might be because it 'loops to' an dhas sprite parts of difference sizes and other such issues but it was impossible for me to recreate this in your example.

I can work around it in this one case but it's one of those things that's like "Oh uh.. is this... alright? This isn't going to fuck anything else up is it?" so knowing why it happens would be very useful. D:

So the problem with this is like... what's the best way to do selection since creating objects by name doesn't seem to handle selection right?

Yeah I mean making a list of like 700 objects is a pain but it's a doable pain. Any way to rip a list of object names out of a cap? (I'd have a much easier time excluding stuff not to save, but it's not a huge deal).

Curious to hear what the 'not quite actually an object' issue is though. Hopefully not another deep inset construct nightmare. D:

Yeah I mean making a list of like 700 objects is a pain but it's a doable pain. Any way to rip a list of object names out of a cap? (I'd have a much easier time excluding stuff not to save, but it's not a huge deal).

Curious to hear what the 'not quite actually an object' issue is though.

http://kayin.moe/forrojo.cap is a stripped down cap where the issue still happens. The iteration error I think is because I named my family "save" >_> Maybe not the best call.

Actually I fixed it. The problem was I had no edit box... which I didn't realize until I deleted the one layout with an edit box (which gave me a different error which helped me realize I need to remove that one line of code). So it works! Besides the family stuff, but that's a good sign.

If I try and use the same family I get...

File "<string>", line 1, in <module>

File "<string>", line 9, in save

TypeError: 'function' object is not iterable

or like

TypeError: 'NoneType' object is not callable or something like that which might have to do with things in other layouts? Not sure.

Edit: Another major issue seems to be that the other instances of an object don 't seem to actually exist? So for example, take your cap and set it so sprite rotates slowly... So then you'll have 3 spinning boxs, but once the load happens, only one of them will spin.

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.

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.

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. ;_;

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.

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.

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. =/