160 Hour Bug Recovery?

Greetings all,

My daughter bought LBP (PS3) for our two youngest boys for last Christmas, and by the time the holiday break was over, Dad (me) was playing the game in the evenings after the kids were in bed and getting the itch to create my own levels for them to play. Now, I'll be the first to admit that I tend to be meticulous, methodical, and perfectionist about learning any skill -- LBP level creation included. I also knew that I had almost two years of game development (by Mm and the on-line community alike) to catch up on, before anything I produced would be worthy of play. In other words, I have been taking my time and learning the ropes, working primarily on a single "training" level for the past three months in the evenings. As of last weekend, the level was about 85% complete (1 puzzle, the chase-finale, and level decoration/dressing remaining), with the Thermo at 10/16 ticks. I could see the finish line.

This week, however, the physics in the level began to "stutter" badly, for lack of a better term, making every moving object unusable. I've gone back to previously saved versions from last weekend, paying close attention to each new bit added in this final puzzle, and no matter how I change / simplify it, the same "stuttering" begins after a few hours, and no amount of deleting (either former or later parts of the level) will fix the problem. This evening, I pulled up the backup file again, and just watched it for a while without making *any* changes, and sure enough, the stutter begins after a few hours again.

Last December, in this thread, LittleBigDave said:

Quote:

---

Also I create almost entirely in paused mode (with frequent play-then-rewind to play-test), which I thought kept me safe from the 160 hour bug (or whatever its called ... the long run time = rounding error shenanigans bug).

---

and this sounds like what I am experiencing now. Needless to say, I'm a bit torqued that Mm didn't bother to WARN me in their Creation Mode tutorials or Manual or on-line material about this --> three months of part-time work is annoying to lose, even if a lot of that was "learning curve" stuff.

So the question is, is there any way to recover a level from this bug? Or, failing that, a way to recover parts (individual sections) of the level, and the rebuild it in a "new" level? If I chop it up into parts that can be "captured" will that work? or is everything in this level corrupted and has to be rebuilt from scratch?

Many thanks for the replies,

-- Nanluin

Just keep the level paused while you create. Unless the player will take hours to complete your level, they shouldn't notice any bug.

If it's really noticeable, you can copy each part of your level, piece by piece, then move it to a new blank level.

I understand your frustration: several of us have been there. Back when this was first discovered, Mm was surprised by it. The didn't imagine that anybody would accumulate 160 hours of unpaused create time, but it's something that several of us have encountered. I've got a level that's suffering from it, albeit pretty mildly. Once I found out why, I did all my editing in pause mode so it never got any worse, but it's still there a bit. Typically, if I need to test anything, I'll unpause, run through the test, and then rewind even if I didn't trigger or break anything, just to keep the clock down.

As for solutions, if you cut it up, capture the bits and move them to a fresh map, that will fix your problem. It's the level itself, not any of your objects, that is to blame. The other option is to export the level to a save file and e-mail it to Mm (not sure who specifically or where you'd find out, but I'm sure a bit of googling would get you the answer) and ask if they can reset the level clock for you. They did that for the first person who reported the problem, but I don't know if they've done it for anybody else.

Do you think you could allow me to se this bug?
I've seen most bugs there might be on the game, this might just be something i've dealt with before and might be able to help you, but i need to see the bug in action to be certain,

It'd be a shame to loose that much work for a simple bug, so i'll try and help in whatever i can.

Add me, my PSN is: Yarudark
I'll see what i can do.

Quote:

---

Originally Posted by Nanluin

So the question is, is there any way to recover a level from this bug?

---

I've done this before for someone else's level. There's no need to chop it up into parts - you can just capture the entire level with the Capture Object tool, and paste it into a new level. It's the level itself which stores the overflowed simulation counter, not the objects it contains.

It might take a while to make the capture box large enough to cover the whole level, it's difficult to tell when you have covered the entire level, and you'll have to reattach anything that's attached to the ground when you paste it into a new level, but that's about the best you can do.

Quote:

---

Originally Posted by Silverleon

Do you think you could allow me to se this bug?

---

Search for @ziggurcat - he still has a published copyable level with an example of the bug.

Nanulin,

I've been in the same boat as you, purchasing the GOTY edition and attempting to catch up on two years of level creation and progress. In that short period of time I've been shown some strange things (glitches) and even worse (bugs.)

I'm wondering if there's anything, such as the aforementioned 160 hour bug, that has been documented/published by the community showing off these bugs?

I'd also be curious to find out if MM can/has/will fix these bugs or has officially recognized any of them? Has anyone sent a bug and a level off to MM to have it repaired and/or given an official explanation?

Quote:

---

Originally Posted by Aya042

I've done this before for someone else's level. There's no need to chop it up into parts - you can just capture the entire level with the Capture Object tool, and paste it into a new level. It's the level itself which stores the overflowed simulation counter, not the objects it contains.

It might take a while to make the capture box large enough to cover the whole level, it's difficult to tell when you have covered the entire level, and you'll have to reattach anything that's attached to the ground when you paste it into a new level, but that's about the best you can do.

---

Yup... I agree. You can try going to a much earlier backup and retrofit it, but the easiest is to capture the whole level as Aya suggests. What is really handy is to have another in to see if you have everything captured as they can watch your capture box. They are also handy to have around for getting it positioned in the other level.

Good luck!

Quote:

---

Originally Posted by schm0

I'd also be curious to find out if MM can/has/will fix these bugs or has officially recognized any of them? Has anyone sent a bug and a level off to MM to have it repaired and/or given an official explanation?

---

Mm has been all over the bug fixing. There used to be a problem where if a score bubble was glue down to your level, collecting it would cause the whole level to come unglued. If you made an object that had gas with any color other than green and captured it, it'd revert to green so it was impossible to emit any other color of gas. When you would rewind in create mode, it would often take forever due to some network call that was made. That's just three examples off the top of my head, and Mm has fixed them all. Over the past two years (it's been two years?! Wait, no. Isn't it more like a year and a half?) the game has gotten better and better. It's much more stable and easy to use, and all kinds of new stuff has been added. Mm is the perfect model of how devs should support their games.

I'm surprised there's a clock, in fact I think it would be a pretty interesting stat to see just how long you've invested in a level. The fact it goes buggy after x is a bit odd and scary nonetheless. I'd also like to see an example. I spent a good while on my last level, not sure about how long I paused/ unpaused. But there is one part that whenever I played for no apparent reason after a while started going weird. It was a stairs attached to pistons that came down after pulling a switch. It seems a bit random when it would occur but one of the steps would start going lower than it should and what I'd call stuttering. The noise of stone sliding past stone started shooting off and players could stand where the step should have been mid air albeit slightly wobbly. Sounds a bit similar to this but luckily it only affected that one set of stairs.

Quote:

---

Originally Posted by schm0

I'd also be curious to find out if MM can/has/will fix these bugs or has officially recognized any of them?

---

Well, the 160-hour bug has certainly been acknowledged by MM, check out this post for a summary.

Quote:

---

Originally Posted by OneEyedBanshee

It seems a bit random when it would occur but one of the steps would start going lower than it should and what I'd call stuttering.

---

This can also be caused by something (usually a large chunk of your level) not being glued to DM correctly, or a connector length conflict (in the same way that you might purposefully create the low-gravity glitch).

It's easy to tell if you have the 160-hour bug - just put a 0.1s piston in somewhere, and if it doesn't appear to move, then you have the bug.

Thank you for the responses, everyone.

Quote:

---

Originally Posted by Sehven

As for solutions, if you cut it up, capture the bits and move them to a fresh map, that will fix your problem. It's the level itself, not any of your objects, that is to blame.

---

I broke the level up into four, somewhat-manageable (from a positioning standpoint) pieces without too much surgical pain, and was able to reconstruct the level in a fresh, blank slot ('crater') on my Moon. So far, the problem appears to be fixed, and with only a few hours of relocation angst.

Quote:

---

Originally Posted by Silverleon

Do you think you could allow me to see this bug?

---

Perhaps after I have the finished / polished level up and published for a bit, I can also put up the broken, partially-complete prototype if there is an interest in seeing this bug in action.

Quote:

---

Originally Posted by Aya042

Well, the 160-hour bug has certainly been acknowledged by MM, check out this post for a summary.

---

I searched the forums for further information, but didn't find those particular threads -- thanks.

The ironic bit here is that I do dynamic geophysical computer models / simulations for a living, and am thus all too familiar with accumulated precision / rounding errors. This one took me by surprise because there are ways of resetting your clock and component state variables (position, velocity, start time) periodically -- I would have done it at the end of each "create" session (or the beginning of the next); as such, each create session begins with its clock set to zero. In the case of this game, such a scheme would be facilitated by the fact that many (if not most) moving objects have at least one static (unchanging) reference point via chained attachment to Dark Mater or to the Floor. Emitted objects have the attachment point of the emitter. That leaves the unattached moving objects (vehicles, things resting on tracks, etc.), which (at the end of your create session) can be permitted to 'settle' under the force of (simulated) gravity until bulk motion stops (within minuscule error bars), and then "new" initial positions stored for the start of the next create session. This is obviously easier to implement when initially creating the simulation engine, more difficult to 'back-fit' after the engine has been created and implemented. If fixing the bug was too difficult / time or $$ intensive, they should have at least put up some warnings for new creators:

"When in Create Mode, spend most of your time with the clock Paused, and only press Play when you need to watch or test the operation of some moving part of your level -- then go back to Pause again. Accumulating too much time on the level's clock in Create Mode (approximately 150 hours) can cause severe problems with the functioning of your level." [Insert Stephen Fry riff here]

Done. New creators warned. Ah, well: at least the community had the information on this problem, once I knew that I needed to come here and research it.

Thanks again,

-- Nanluin

Quote:

---

Originally Posted by Nanluin

I searched the forums for further information, but didn't find those particular threads -- thanks.

---

The forums seemingly use the standard MySQL FULLTEXT index, which by default doesn't index any 'words' with three characters or fewer, so searching for "160 hour bug" is the same as searching for "hour". Took me a while to find that post because of that, but I remembered I'd used the word "anton" in it, which was suitably rare enough to find.

Quote:

---

Originally Posted by Aya042

This can also be caused by something (usually a large chunk of your level) not being glued to DM correctly, or a connector length conflict (in the same way that you might purposefully create the low-gravity glitch).

It's easy to tell if you have the 160-hour bug - just put a 0.1s piston in somewhere, and if it doesn't appear to move, then you have the bug.

---

How do you glue DM incorrectly?! I need to know! There was some pretty vast objects and lots of things connected to those so probably that caused my issue.

Quote:

---

Originally Posted by OneEyedBanshee

How do you glue DM incorrectly?! I need to know! There was some pretty vast objects and lots of things connected to those so probably that caused my issue.

---

I mean in the sense that a large chunk of level isn't glued to DM at all, so it merely appears static due to its large mass, but connectors and so forth can cause it to move around.

Glad to hear you got it sorted, there's a few of us that have got hit by this. Its not necessarily just 0.1 pistons, any piston that wasn't directionally controlled got hit in mine. Visually, mine looked like severe lag, but only on the affected object, everything else moved normally.

Hey, Nanluin.

Sorry to hear you've been struck by the bug. I just have to ask... do you build in the unpaused physics state? I scanned the previous posts and didn't catch the answer to that anywhere. If so, you may be able to yet finish the level if you build carefully in pause mode. Otherwise, everyone else's advice to copy the whole level into a blank one would invariably fix the problem (but it's bound to be quite a hassle). Bring a friend and expect it to lag like crazy when trying to place it.

And just to be clear, you can start to have issues way before 160 hours if you have free moving pistons at .1 to .3 second timings (ie. not attached via switch).

In the future, you may consider building like I do:

Build primarily in pause mode. Anytime you need to unpause the physics, place a block of Dark Matter off to the side. Unpause and do your testing, but do not directly edit anything while unpaused. Rather than pausing again to perform edits, rewind. Placing the DM block gives an action which can easily be rewound to (thus not undoing any connector/switch settings). If the block is already there, just move it slightly to the side (as a rewind action to return to). By being careful in this manner, you can safely avoid the glitch in the future (safely is used loosely here). Personally, I have never gotten the glitch, despite having spent easily that long on levels in the past.

Looking forward to seeing that level. Post it in the showcase when it's ready!

:)

Quote:

---

Originally Posted by comphermc

I just have to ask... do you build in the unpaused physics state? I scanned the previous posts and didn't catch the answer to that anywhere. If so, you may be able to yet finish the level if you build carefully in pause mode.

---

I was building the level in the UN-paused (Play 'button') Create Mode, for three reasons: (a) ignorance of the 160-hr bug and the detrimental effects of accumulated level clock-time, (b) I didn't like the "fuzz" visual at the top of the paused screen, and (c) I didn't like the *sound* that paused Create Mode makes -- I'd rather listen to the birds chirp or what-have-you.

Lesson learned. Next time, turn the TV volume down and keep it paused!

The level really has too much accumulated error, such that EVERY MOVING THING is severely lagged and "stuttering" as it tries to move, to try to save it as is. A couple of weeks ago, I noticed that I was having to go back and adjust up the periods of a few fast wobble bolts (0.3-0.4 sec periods) to about 0.5 sec, but didn't understand what this symptom meant. I don't have any "unfettered" pistons operating that quickly to have noticed it, and the logic networks that use little, fast pistons kept working until the lagging stutter set in.

The re-build it proceeding well. I'll post here when it's ready for prime time and some critique and feedback.

-- Nanluin

Quote:

---

Originally Posted by Nanluin

(c) I didn't like the *sound* that paused Create Mode makes -- I'd rather listen to the birds chirp or what-have-you.

---

There's actually a music player somewhere in the start menu, that pause noise is very bothersome.

Quote:

---

Originally Posted by Nanluin

there are ways of resetting your clock and component state variables (position, velocity, start time) periodically -- I would have done it at the end of each "create" session (or the beginning of the next)

---

This would actually create other problems. Any action that isn't synced to the game clock would be reverted so a synced state. For example, set up a piston and hook it to an on/off switch. Unpause, set up another, pause, and hook the same switch to it. They won't be in sync with each other. While this can be bothersome, if you were to build something in that manner and then adjust the sync settings to make them work the way you want, resetting the game clock would re-sync them... which would mean that they would no longer behave the way you built them to. At least I think it would: capturing and emitting the object will re-sync the pistons as it breaks their association with the game clock, so I imagine resetting the clock would do the same thing. (By the way, if you're going to build a device like I just mentioned, it's best to place all the pistons in pause mode with no unpaused time between them. Then you can adjust the sync however you want and it won't come out of an emitter broken).

There may be other reasons why having the clock constantly reset would be bad, but I don't know enough about what's going on behind the scenes to say for sure.

interesting bug glad you got your level sorted, im assuming going in to play mode to test the level won't effect the clock? I usual test everything in play mode rather than un pausing.

Right. Only unpaused time in create mode counts against the clock. If you unpause, test whatever, and then rewind back to when it was paused, the clock goes back to where it was before you unpaused, so no time has accumulated.

Cool thanks for the reply, be nice if they made the clock visible until it's fixed/if it's fixed.

Quote:

---

Originally Posted by Nanluin

Perhaps after I have the finished / polished level up and published for a bit, I can also put up the broken, partially-complete prototype if there is an interest in seeing this bug in action.

---

Yes, that'd be much appreciated as i am a bug/ glitch hunter, i like to find bugs and glitches, analyze, capture (if possible) and learn how to fix them (if its a bad bug/ glitch) so information in any anomality is appreciated.

Tenement got hit with this bug, but I had never, ever worked on the level outside of pause mode. (I do all my testing in play mode). So don't assume that you're safe building exclusively in pause mode, because I can say with absolute certainty that the 160 hour bug has nothing to do with paused/unpaused.

I got hit with this bug a bit over a year ago which made me rethink how I build anything. I am building similar to Compher in that I never ever unpause and only do it for a short time to check gravity and then rewind. However, after having discussions with Kiminski on her last level having it hit twice and assuring me she was not unpaused, I started a new tactic that has helped me avoid the bug altogether.

This will be a repeat for some, but I build everything very modular and in workshops spending very little time in the actual level itself. This way I can have it unpaused if I want without any concern. I can create several different versions of an object or segment till I am happy. It also helps me test each object and segment to death, before I ever capture and move it into the level. If a particular workshop hits the bug, no biggie... It becomes a warehouse of sorts to just grab pieces and I move on to a new workshop. Once in the level, I only play test in play mode.

Quote:

---

Originally Posted by jwwphotos

I got hit with this bug a bit over a year ago which made me rethink how I build anything. I am building similar to Compher in that I never ever unpause and only do it for a short time to check gravity and then rewind. However, after having discussions with Kiminski on her last level having it hit twice and assuring me she was not unpaused, I started a new tactic that has helped me avoid the bug altogether.

This will be a repeat for some, but I build everything very modular and in workshops spending very little time in the actual level itself. This way I can have it unpaused if I want without any concern. I can create several different versions of an object or segment till I am happy. It also helps me test each object and segment to death, before I ever capture and move it into the level. If a particular workshop hits the bug, no biggie... It becomes a warehouse of sorts to just grab pieces and I move on to a new workshop. Once in the level, I only play test in play mode.

---

Sounds like a good plan...I think I might take this approach in future.

Yeh, I've been doing the same recently, building the basic mechanics for each section in another 'Bits & Pieces' level and just plonking them in and tarting them up when they're done.

What intrigues me the most is that i've been working on 2 single levels for more than a year now and had never had problem s with this bug...

The reason why i'm in terested in it actually.

Quote:

---

Originally Posted by Ungreth

Sounds like a good plan...I think I might take this approach in future.

---

Compher and Morgana think I'm nuts... well, they would anyway!! However after having my girlfriend just hit this bug this weekend and help her recover from it, I don't think I am that crazy. ;) She also did not have it unpaused that long. She has spent quite a few months working on it (gosh.. maybe since December?), but as her tv sits right next to mine I know she didn't have it in play that much. Especially with me freaking out and saying Umm Rewind and keep it paused some 5 or 6 times an evening. :)

A few minor points about this modular thing.. Sometimes those sections have become horribly large and quite handy to have a 2nd in that you trust to act as spotter for moving them into position. For me, it is quite easy since I have that 2nd system next to me. Like having a huge rear view mirror!!

Quote:

---

Originally Posted by Nanluin

there are ways of resetting your clock and component state variables (position, velocity, start time) periodically -- I would have done it at the end of each "create" session

---

Quote:

---

Originally Posted by Sehven

This would actually create other problems. Any action that isn't synced to the game clock would be reverted so a synced state.

---

You're not following me -- although I didn't explain it in detail either. Because every moving object in the game is either moving in a cyclic, oscillatory fashion, is waiting for some trigger action to activate it, or is at some point along a fixed 'track' (trajectory), all time in the game simulation can be treated in a *relative* fashion: maintaining "absolute time" isn't necessary in this instance. To 'calibrate' an oscillating system to a clock, you only need to know where to start the oscillating system within +/- one period (cycle) of time *relative* to the reference clock.

For example. let's say you installed a piston with a 1 second period at time 5:00.400 after entering create mode, and then you exited Create Mode at time 10:00. After creation, the piston went through 299.6 cycles until you exited. From a simulation standpoint, the important bit is that this piston begins its 1 second period 0.4 seconds after each 1 second tick of the system clock -- knowing about the other 299 cycles it went through before you exited is unnecessary information. 'Tracked' objects (emitted here, destroyed there) have a similar lifetime cycle, such that you only really need to know the object's current time relative to the time that it was emitted (with the emitter itself treated as a 'spike' waveform oscillator) -- again, absolute times are unnecessary.

By creating your level in Pause mode, you are essentially doing the above manually -- keeping all reference times for moving objects you've created clustered about a low TLC (time since level creation) clock time. Each create session might advance the TLC a bit, but not by much, and all reference times for moving objects remain in a tight cluster of "absolute" level times, rather than strung out over 160 hours...when it all goes to heck. In practice, when a player enters your level in Play Mode, the simulator doesn't care that your piston went through 5,474,121.6 cycles since you stuck it in the level -- it will simply find the *relative* difference between the current TLC and your piston's most recent 'zero point'....at time -0.6 sec or +0.4 sec (either works in the math).

I'm just saying that the developers *could* have avoided this problem (bug), without detrimental effects to their physics engine. But hindsight is 20/20, and it doesn't matter now -- we have what we have, and its a great game regardless.

-- Nanluin

Edit: And yes, I'm aware that non-linear (chaotic) systems can be set up within the game: LBP Central's own random-output generator (Advanced Logic Pack) is a clever example of this. Even in that case, however, it should still be possible to store an adequate set of state variables relative to the TLC at the end of a particular create session, based upon the periods of the component parts of that non-linear system, rather than having to heft around absolute times.

Quote:

---

Originally Posted by jwwphotos

This will be a repeat for some, but I build everything very modular and in workshops spending very little time in the actual level itself. This way I can have it unpaused if I want without any concern.

---

Thanks for this suggestion. I've already set up "workshop" areas on my Moon for creature / contraption development, and as a warehouse for said creations for later use / modification. I may move up such workshop use to entire level sections when such things can be modularized.

-- Nanluin

I guess that makes sense. I mean, I don't really know a whole lot about programming, but it sounds good to me. Perhaps it would've been the perfect solution, but it seems to me that Mm just didn't see this one coming.

Quote:

---

Originally Posted by jwwphotos

I build everything very modular

---

Do you ever get piston sag with this method? I've had problems with capturing objects that use pistons and then placing them back in the original level or in a new one. In particular, when I rigged my Mark II mech to be emitted, it was a disaster. It used 6 piston to walk and a 7th to open a canopy over the gunner. After captuing, all of the pistons sagged even though they were stiff: one leg sort of angled forward really pad (about 15-20 degrees), the other just got wobbly, and the canopy would sort of drag behind the mech a bit instead of closing up nice and tight like it did before capture. I was able to fix it by deleting and replacing all the pistons on the captured version and then re-capturing. It's been a while since I've run into this particular problem, though, so it may have been patched, or it may have been something about the way I built the mech. I've also heard of several other people getting this problem after capturing.

Hmmm.. I've not had piston sag unless what it is attached to is a bit small for the weight. Especially in piston to block to another piston arrangements. Though I have never built a mech either!!

However, I have had stiff rods not capture and had to repair the missing ones. The object/room was really quite huge so it wasn't entirely surprising to me, especially since the rod was an integral part of a moving elements. It should have captured, but just never would entirely.

Yeah, it's not a huge problem once you know what to do about it (I was going crazy for a few hours when I first tried emitting my old mech, though). I don't know why replacing them with fresh pistons made the subsequent capture work fine. Maybe all the movement of the mech during testing slightly skewed the pistons and when they were captured like that it just went nuts: the repaired version hadn't moved at all when I re-captured it. The effect was quite a bit more subtle in the VT-04 when I tried it, so it's either been patched or I did something different. I don't think I left the VT-04 unpaused very much, and I would always rewind after tests rather than just grabbing it and moving it back so that might've had something to do with it.

Quote:

---

Originally Posted by Ungreth

Tenement got hit with this bug, but I had never, ever worked on the level outside of pause mode. (I do all my testing in play mode). So don't assume that you're safe building exclusively in pause mode, because I can say with absolute certainty that the 160 hour bug has nothing to do with paused/unpaused.

---

I agree with you , Ungreth. I've certainly had my level paused most of the time, unless I was testing gravity or something like that.

It was almost unbearable when I realized I got hit with the bug. I started disassembling everything then realized there was no way I could put the whole thing back together. So I decided to try and copy the entire level. It almost worked. I was able to capture about 99 percent of it. Most of the emitters had fired and a few of the logic and objects were gone. It took me most of Saturday and part of Sunday to get everything right. I even made some improvements...so other than lost time and my life cut short from fright, everything's fine now. :) Whew!

Quote:

---

Originally Posted by comphermc

Build primarily in pause mode. Anytime you need to unpause the physics, place a block of Dark Matter off to the side. Unpause and do your testing, but do not directly edit anything while unpaused. Rather than pausing again to perform edits, rewind. Placing the DM block gives an action which can easily be rewound to (thus not undoing any connector/switch settings). If the block is already there, just move it slightly to the side (as a rewind action to return to). By being careful in this manner, you can safely avoid the glitch in the future (safely is used loosely here). Personally, I have never gotten the glitch, despite having spent easily that long on levels in the past.

---

This is what I've always done since learning about the bug, and I've never had a problem. I pause the level at zero time, and always rewind back to zero time after unpausing. Even small amount of unrewound unpausing from time to time can eventually accumulate to the point where things stop working.

Quote:

---

Originally Posted by Sehven

Do you ever get piston sag with this method? I've had problems with capturing objects that use pistons and then placing them back in the original level or in a new one. In particular, when I rigged my Mark II mech to be emitted, it was a disaster. It used 6 piston to walk and a 7th to open a canopy over the gunner. After captuing, all of the pistons sagged even though they were stiff: one leg sort of angled forward really pad (about 15-20 degrees), the other just got wobbly, and the canopy would sort of drag behind the mech a bit instead of closing up nice and tight like it did before capture. I was able to fix it by deleting and replacing all the pistons on the captured version and then re-capturing. It's been a while since I've run into this particular problem, though, so it may have been patched, or it may have been something about the way I built the mech. I've also heard of several other people getting this problem after capturing.

---

I'm lucky if the pistons get captured at all lol.

When I tried to fix my last TR level, I had to redo pretty much every piston and decoration each time I did a copy and paste. I almost lost the will to live lol.

Quite sad that this has never really been addressed by MM, bar the one off response to one lucky bug reporter. While I'm not even going to begin to understand whether or not this type of problem can actually be fixed, they could at least have implemented an automated work around, to save us the bother. Pretty shoddy really.

At the end of the day, it won't be the people who only spend a couple of hours creating a level that are still playing a few years down the line. We're their future, they should look after us. :)

Encountered this buig with Sacky Potter right at the end when I was working on the final boss. Fortunately each 'room' was a seperate section so I copul;d just capture each one and put it in a blank level. Only thing I had problems with was the intro sequence, which I had to capture as too objects because it was so detailed... and it's pretty difficult to split something that's glued together and connected with pistons into two parts. Got there in the end though.

I'm using the 'workshop' method for my LOST levels, making stuff and experimenting in there then just bringing stuff over to the main level. I might capture each level section as an object as I finish it too, just to be save so I have a backup so if the bug does occur I've got it all split up already.

Quote:

---

Originally Posted by Kiminski

Pretty shoddy really.

---

If it were anybody else saying this, I'd be telling them off right now. But I think you've earned the right to call Mm on this one. You had to deal with the 160 hour bug twice on Helgardh, right? Or was it three times? Either way, it was too many. From what I saw in that original thread, Mm's solution was to reset the level clock: it'd be nice if they'd give us the ability to it ourselves.

Some of the talk in this thread has got me wondering. Does it actually have to be 160 hours of unpaused time? Or is the unpaused time bug separate from the 160 hour bug? When I got it, all that happened to me was that I lost some of my .1 second pistons and wobbles (and then I lost my .2 second ones a few days later), but some of the stuff in this thread sounds much more severe. Did you actually rack up 320+ hours of unpaused time in Helgardh, or did you get the bug even when building in pause mode?

Hey, just a little thought i had. Could you capture your whole level as an object and then move it to a new map?