Saving Layouts?

That one opened.

Replace the line:

zorder.sort()

with

zorder=sorted(zorder, key=lambda i: i[0])

Then in a few lines below it loops over zorder. Add a check if obj is None, and continue if it is.

for pair in zorder:
		obj=pair[1]
		if obj is None:
			continue[/code:2trboehs]

That seems to work.

It works! God I really need to do something nice for you when this game is finally out. x_x

Hopefully this will be the last python related snag so I can stop pestering you so much.

Getting things working but also getting some crazy float errors in the saving (a 1.1 variable saving as 1.0999999046325684 for example) but I'm having a hard time thinking how that could even be avoidable if its a problem. =/ I guess this is such a minor error though that it should never come up as a problem though.

Oh for anyone going this route (Ahaha I doubt it), I got a bunch of strange behavior with container objects. I don't think that'll be a problem for me (and if it is anywhere, I can work around it), but generally speaking, only save the parent object.

Anyways the float issue aside (which again, I GUESS isn't an issue since I've already had to work around rounding errors in general but sorta just makes me a little queezy), integrating things is going well!

edit: 2 days into porting stuff over and fixing minor things. None of the float issues have been a surprise (not exactly surprising, considering how common rounding errors are even in the best of times) and no other major snags have come up.. So... This... works. :O AMAZING. I won't feel totally safe until the whole game is adjusted over and I can send it to testers, but this is exciting.

Okay random question! So far a super minor issue is the first time a level loads there is a big lag.I'm GUESSING it's construct compiling the python? Because all loads after that are super high. I know using your caploader, I've seen PYC files pop up which I assume are compiled code? Would it be possible to point to a pre-compiled file to remove that lag? It's tolerable and far more preferable to the old state of the game which involved 'taking a million years to load the game on slower computers',

I'm asking this instead of doing this because I tried to do this and keep getting different errors because I don't understand python. >_> Seems if I do "sys.path.append(System.AppPath)" to be able to import things and run the script I get an error globsal name 'System'' not defined error. Again, this isn't critical, but I figure I'm probably missing something small.

If the python files are outside the exe you can just ship the pyc fies generated instead of the py ones. The slowdown is from Construct generating the script to bind objects with python, then of course python also parsing and running it. I don't think it can be improved since the length of the script is proportionate to the number of objects. Unfortunately it can only be made when the game runs, and can't be pre-compiled.

No? Huh, I would figure it wouldn't matter if it was the same exe. Does this get generated the first time python is used? If so I might use try and invoke it at a different time (like at the start of the game rather the first time someone selects a stage from the map screen). Again, not a big deal even if I can't change it, but if I can slightly improve the user experience that'd be rad. (Sorry I'm asking insteads of testing but the game is still in a messed up state as I port everything over)

I thought it was generated and run at the start of the game. It might still happen when the first script is run though, I'm not sure.

Hm. Well, it's tolerable as is, so not the biggest deal.

Small note (both for myself in case I take a break from this or if someone else tries it)... Seems like some objects can sometimes cause crashes on level transitions. Like, you spawn an object, don't do a lot with it and then call it in the next layout and it crashes? And it seems just adding an event (whether or not its true or not like angle = 99999) for that object in the layout before seems to fix it for... some reason? I've had this happen with a total of 1 object and I've tried to recreate the issue and can't. But... whatever, I guess?

Finding obscure bugs in CC can be annoying as hell, so I'll share what I can remember.

Strange things which can crash the game:

-Calling a function as an action, in the same event as an "is overlapping" condition. to fix, put the function in an empty sub event.

-.WAV bit rate. Do not exceed 1411kbps for .wav sounds or crashing will occur. This one was fun to figure out..

I'm SHOCKED i haven't bumped into that function one yet. Also shocked the level loader is working as well as it is. Still kinda slow going moving the levels over because I need to tweak things, but aaaa I'm terrified anything goes wrong because I'm always afraid it's going to be some impossible construct bug.

We need to form the CC Survivors Club.

Oooh here's a new one. Thankfully not python related so I can worry about that a little less, but I save all the level layer data and like what groups to enable in an ini and on one level the parallax was mucked up and it's because it was saving 90% scroll ratio as 89 (I'm... guessing internally the scroll rates are like "0.9"? or whatever, thus the error?). Saving it as a string gives me "89.9999923706055". Fun. Well, I don't use any decimal layer scroll rates so a simple round fixed that. Dammit floats, I'd hope you'd at least work accurately on whole numbers. >:|

Kinda wondering if I should do that in the python script too. Like, round to the nearest second decimal or something...

Ported everything over and released it to testers. There were bugs that had to be squashed but uh... NOT A DISASTER. THE SYSTEM WORKS. IMPROVED PERFORMANCE. \o/