Saving Layouts?

For questions about using Classic.

Post » Sun Feb 07, 2016 10:01 pm

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.
Last edited by R0J0hound on Sun Sep 17, 2017 10:32 pm, edited 1 time in total.
B
94
S
33
G
113
Posts: 5,354
Reputation: 73,269

Post » Mon Feb 08, 2016 12:17 am

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. ;_;
B
12
S
4
G
4
Posts: 239
Reputation: 2,428

Post » Mon Feb 08, 2016 1:23 am

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

Image

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.
B
12
S
4
G
4
Posts: 239
Reputation: 2,428

Post » Mon Feb 08, 2016 2:23 am

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.
B
94
S
33
G
113
Posts: 5,354
Reputation: 73,269

Post » Mon Feb 08, 2016 2:38 am

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.
B
12
S
4
G
4
Posts: 239
Reputation: 2,428

Post » Mon Feb 08, 2016 3:41 am

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.
B
12
S
4
G
4
Posts: 239
Reputation: 2,428

Post » Mon Feb 08, 2016 4:52 am

Yeah, the python errors are kind of obscure in Construct, for one the line numbers are way off. That "NoneType' object is not callable" usually means that object doesn't exist.

The function is not iterable error and probably some others could be if the object names conflict with the python names.

A cap could help me knock out a few of the bugs. I'll have time tomorrow.

That last major problem intrigues me, probably some issues with my load function.
B
94
S
33
G
113
Posts: 5,354
Reputation: 73,269

Post » Mon Feb 08, 2016 6:42 am

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.
B
12
S
4
G
4
Posts: 239
Reputation: 2,428

Post » Mon Feb 08, 2016 7:29 pm

Ah, so I guess families don't work then. Well they do partially but they're setup differently so we get that object is no callable error. Basically it's some issues with the runtimes source itself, and let's say I'm purposely avoiding going that route to avoid a myriad of errors because compiling with a different compiler introduces too many issues. Most of which I was never able to solve.
So I guess just listing all the object types would work though, barring any other gotchas.

It's quite the Pandora's box. The work needed to work around stuff or even trying to fix the source itself quickly seems to exceed re-writing something from scratch...
B
94
S
33
G
113
Posts: 5,354
Reputation: 73,269

Post » Mon Feb 08, 2016 9:57 pm

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.
B
12
S
4
G
4
Posts: 239
Reputation: 2,428

PreviousNext

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 2 guests