LBPCentral Archive

Home

LittleBigPlanet 1 - PSP - Tearaway -Run Sackboy Run

LittleBigPlanet 1

[LBP1] Help! [Archive]

160 Hour Bug Recovery?

Archive: 72 posts

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 (http://www.lbpcentral.com/forums/entry.php?866-Waste-Not-Want-Not-Part-1), LittleBigDave said:
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

2010-04-04 04:32:00

Author:
Nanluin

Posts: 98

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.

2010-04-04 04:38:00

Author:
warlord_evil

Posts: 4193

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.

2010-04-04 05:59:00

Author:
Sehven

Posts: 2188

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.

2010-04-04 07:36:00

Author:
Silverleon

Posts: 6707

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.

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.

2010-04-04 11:48:00

Author:
Aya042

Posts: 2870

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?

2010-04-04 16:09:00

Author:
schm0

Posts: 1239

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!

2010-04-04 16:15:00

Author:
jwwphotos

Posts: 11383

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.

2010-04-04 17:39:00

Author:
Sehven

Posts: 2188

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.

2010-04-04 18:48:00

Author:
OneEyedBanshee

Posts: 1370

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 (https://lbpcentral.lbp-hub.com/index.php?t=23971-Thin-or-theck-gas&p=416799#post416799) for a summary.

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.

2010-04-04 19:32:00

Author:
Aya042

Posts: 2870

Thank you for the responses, everyone.

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&apos

on my Moon. So far, the problem appears to be fixed, and with only a few hours of relocation angst.

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.

Well, the 160-hour bug has certainly been acknowledged by MM, check out this post (https://lbpcentral.lbp-hub.com/index.php?t=23971-Thin-or-theck-gas&p=416799#post416799) 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

2010-04-04 21:58:00

Author:
Nanluin

Posts: 98

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.

2010-04-04 22:23:00

Author:
Aya042

Posts: 2870

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.

2010-04-04 23:00:00

Author:
OneEyedBanshee

Posts: 1370

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.

2010-04-04 23:58:00

Author:
Aya042

Posts: 2870

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.

2010-04-05 00:51:00

Author:
julesyjules

Posts: 1156

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!

2010-04-05 01:18:00

Author:
comphermc

Posts: 5338

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&apos

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

2010-04-05 01:54:00

Author:
Nanluin

Posts: 98

(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.

2010-04-05 02:31:00

Author:
warlord_evil

Posts: 4193

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.

2010-04-05 05:51:00

Author:
Sehven

Posts: 2188

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.

2010-04-05 09:31:00

Author:
Unknown User

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.

2010-04-05 10:32:00

Author:
Sehven

Posts: 2188

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

2010-04-05 12:09:00

Author:
Unknown User

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.

2010-04-05 12:54:00

Author:
Silverleon

Posts: 6707

2010-04-05 13:21:00

Author:
Ungreth

Posts: 2130

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.

2010-04-05 13:50:00

Author:
jwwphotos

Posts: 11383

2010-04-05 14:19:00

Author:
Ungreth

Posts: 2130

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.

2010-04-05 14:33:00

Author:
julesyjules

Posts: 1156

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.

2010-04-05 14:41:00

Author:
Silverleon

Posts: 6707

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!!

2010-04-05 14:43:00

Author:
jwwphotos

Posts: 11383

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

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.

2010-04-05 17:27:00

Author:
Nanluin

Posts: 98

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

2010-04-05 17:40:00

Author:
Nanluin

Posts: 98

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.

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.

2010-04-05 18:53:00

Author:
Sehven

Posts: 2188

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.

2010-04-05 19:31:00

Author:
jwwphotos

Posts: 11383

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.

2010-04-05 20:09:00

Author:
Sehven

Posts: 2188

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!

2010-04-06 01:09:00

Author:
TheCountessZ

Posts: 537

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.

2010-04-06 02:33:00

Author:
Aya042

Posts: 2870

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.

2010-04-07 11:05:00

Author:
Kiminski

Posts: 545

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.

2010-04-07 11:37:00

Author:
Nuclearfish

Posts: 927

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?

2010-04-07 12:20:00

Author:
Sehven

Posts: 2188

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

2010-04-07 13:13:00

Author:
Emogotsaone

Posts: 1030

You could, but it would be very difficult to manoeuver the capture box around the level if the level is huge. The you'd have to place it in the new level by trial and error, so it doesn't go over the level boundaries.

My level had this bug, so i had to cut it into 4 chunks, then captured them.

2010-04-07 13:30:00

Author:
Rhys125

Posts: 841

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?

I was hit with it three times. It happened way faster than 160 hours too, I had dodgy 0.1's after just a day or so.

When I first started building it, I was unaware of the causes at that stage so I did rack up quite a few hours unpaused. This led to the usual lack of response at 0.1 then 0.2 right up until 0.5 and then the pistons finally going nuts (at I assume 160 hours) and either not working at all or juddering about all over the shop. This happened twice and it wasn't until I'd finally found that response from MM on the workshop about pausing, that I finally got the motivation to move the level again.

After the move I remained in Pause mode as much as I could, but that proved quite difficult considering the problems I had with pistons/bolts not copying over properly. As I said they'd either vanished completely or the settings that worked perfectly well in the old level had totally borked in the copy, so I had a fair bit of tweaking to do. Having said that, almost all of the tweaking was done in one afternoon and I honestly don't think I had it in Play mode for any longer than an hour. All further building was done paused and I was careful to rewind, but it still gradually set in again and it felt like it was even quicker than the first time, although that may have just been because I was constantly checking.

After the third move I built the rest of the level in workshops. Not noticed it happen any more, but then I've not really been in the level much.

As for MM.. I'm just really disappointed tbh. Their lack of communication on the subject is infuriating, they're just ignoring the problem. If there is literally nothing they can do, then they should at least explain the problem, so I don't have to read endless posts about poor creators losing all their hard work. I wish I'd known about it beforehand.

Anyways, I'm not one to maon, so....

2010-04-07 13:57:00

Author:
Kiminski

Posts: 545

When I first discovered the bug about a year ago, I had found the posts on LBW and added my situation. I had gotten the suggestion to have Mm reset the clock and it seemed there had been a few lucky individuals that had that done by sending an email. I've sent quite a few emails and even completed a bug report in the Beta on the issue, but I have never had a reply.

Seems to me if they do have the ability to do this, then add it as a feature to reset the clock. Heck.. I would even pay for that little option if it came in something like a Creator Pack 2!

2010-04-07 14:10:00

Author:
jwwphotos

Posts: 11383

When I first discovered the bug about a year ago, I had found the posts on LBW and added my situation. I had gotten the suggestion to have Mm reset the clock and it seemed there had been a few lucky individuals that had that done by sending an email. I've sent quite a few emails and even completed a bug report in the Beta on the issue, but I have never had a reply. This actually made it all a whole lot harder to swallow tbh. Why should whatshisname on LBW get his level fixed and not me? I sent 3 emails and didn't hear anything back. I even begged lol. 8 months work down the pan, I was desperate!

Seems to me if they do have the ability to do this, then add it as a feature to reset the clock. Heck.. I would even pay for that little option if it came in something like a Creator Pack 2!

Me too Jww! I just don't think they're that bothered though as it's only affecting a handful of creators. It's just a shame that that small minority happen to be the ones putting the most work in. Makes me sad.

2010-04-07 14:44:00

Author:
Kiminski

Posts: 545

I also emailed them to no avail. I don't expect them to reply personally to each and every one, but surely they know a lot of creators have had a crappy time because of this thing. If it wasn't for the unofficial information i found through this forum I would have given up the game entirely at that point. My guess is either it's unpatchable, or it affects too small a percentage of the general LBP community for them to consider worth patching.

2010-04-07 14:51:00

Author:
julesyjules

Posts: 1156

I was hit with it three times. It happened way faster than 160 hours too, I had dodgy 0.1's after just a day or so.

Interesting.

As far as I'm aware, no-one's actually done any controlled experiments on exactly how much unpaused time is required to trigger the initial symptoms (i.e. 0.1s pistons failing). So far, the "160-hour bug" moniker is based solely on this quote (http://forums.littlebigworkshop.com/t5/PS3-Workshop/Wobble-bolts-just-stopped-working/m-p/76069/highlight/true#M15345) from MM...

It looks like you left your level running for a week or so in total and there's this lame bug where the precision of joints starts getting really creaky after that amount of time!

[...]

Do you tend to leave your PS3 on overnight with levels unpaused in create mode or did you put 160+ hours into making this level?

...and, as a consequence, it's believed that 160 hours is the magic number, which is about a week.

However, if you read the quote carefully, it's ambiguous as to whether this is the actual amount of time it takes for the bug to occur, or whether it's just the amount of time which happened to be on the simulation clock of the level that was sent to MM for analysis.

Therefore, it's possible that the bug will actually start occuring after just a few hours of cumulative unpaused time.

All further building was done paused and I was careful to rewind, but it still gradually set in again and it felt like it was even quicker than the first time, although that may have just been because I was constantly checking.

Perhaps you made a mistake during the rewinds? Not every action in create mode generates a rewindable event, which is why the "placing a block of DM before unpausing" technique seems pretty effective for all those who use it.

The only reason I question, is due to this other quote (http://forums.littlebigworkshop.com/t5/PS3-Workshop/Wobble-bolts-just-stopped-working/m-p/76468/highlight/true#M15412) from MM...

The timer counts cumulative unpaused time in create mode, and that gets stored as the state of the level when you save it so it adds up over all create sessions.

The timer doesn't tick forward if the game is paused...

...and seeing this guy is one of the lead developers for the game, I have no good reason to doubt his assertion that leaving the simulation paused is an effective means of circumventing this issue.

2010-04-07 14:58:00

Author:
Aya042

Posts: 2870

This actually made it all a whole lot harder to swallow tbh. Why should whatshisname on LBW get his level fixed and not me? I sent 3 emails and didn't hear anything back. I even begged lol. 8 months work down the pan, I was desperate!

Me too Jww! I just don't think they're that bothered though as it's only affecting a handful of creators. It's just a shame that that small minority happen to be the ones putting the most work in. Makes me sad.

Yeah.. I have no idea. Maybe their fix is a bit harder than reaching in with a utility and flipping a value. The number of requests made it too difficult to respond? Who knows..

Sad really. Makes me wonder why there isn't a huge warning sign on the box or in one of the tutorials.

2010-04-07 15:02:00

Author:
jwwphotos

Posts: 11383

I've sent quite a few emails and even completed a bug report in the Beta on the issue, but I have never had a reply.

I sent 3 emails and didn't hear anything back.

I also emailed them to no avail.

A bit of research yields this thread (http://forums.littlebigworkshop.com/t5/General-Discussion/Save-game-problems-how-you-can-help/m-p/64665) on LBW which used to be stickied. However, the fact that it no longer is, might suggest that it's no longer valid. Furthermore, if you read that thread, it says...

The specific problems we are looking for are:

1. Profile won't load and the game quits to XMB with no message. Other profiles load and the affected profile can be loaded as another player, just not the main player.

2. You get a "Failed to load level" message on a level on your moon, even if you're offline.

...so I guess the guy who got his 160-hour bug fixed was just lucky.

For those who attempted to contact MM to get their levels fixed, did you follow the instructions on that thread precisely?

My guess is either it's unpatchable, or it affects too small a percentage of the general LBP community for them to consider worth patching.

Maybe their fix is a bit harder than reaching in with a utility and flipping a value. The number of requests made it too difficult to respond?

If you read the original thread (http://forums.littlebigworkshop.com/t5/PS3-Workshop/Wobble-bolts-just-stopped-working/m-p/76069/highlight/true#M15345), it sounds as if resetting the clock is fairly trivial for them, although Anton suggested that doing so may cause other problems with the level. However, with maybe 100,000 customers and only 20 staff at MM... well... you do the math.

As for a long-term fix, if such a fix would require changing all the data types which store simulation time variables, then not only would a patch have to make the appropriate changes to every level on your moon, it would also have to patch any exported level files in the save data area, and all 2 million+ published community levels.

There's probably an easier way to fix this, but, frankly, there are far more serious bugs with LBP than this one, some of which can seriously corrupt your profile and/or make you lose one or all of your levels for good (check out this (https://lbpcentral.lbp-hub.com/index.php?t=24986-Playstation-freezes-when-I-try-to-edit-play-my-level) for example). At least with this one, it's possible to fix the problem yourself, and has probably been categorized as a 'low-priority' issue in whatever bug-tracking system they use.

2010-04-07 15:49:00

Author:
Aya042

Posts: 2870

frankly, there are far more serious bugs with LBP than this one, some of which can seriously corrupt your profile and/or make you lose one or all of your levels for good (check out this (https://lbpcentral.lbp-hub.com/index.php?t=24986-Playstation-freezes-when-I-try-to-edit-play-my-level) for example). At least with this one, it's possible to fix the problem yourself, and has probably been categorized as a 'low-priority' issue in whatever bug-tracking system they use. I really hope that's not the case. If it just meant capturing the whole level and plonking it into a new space I couldn't agree more, but we're talking about levels that have taken sometimes months and months to build and contain a lot of information. My level was far too big to move in one piece, I had to literally delete whole sections to try separate it all, the whole move took me days and days. I'd much rather have lost a few hours work because I'd forgotten to backup.

Profile bugs have been pretty much sorted with the introduction of backups anyway. While I feel very sorry for anyone who suffers a corrupt level/profile, any digital data is prone to corruption and it's our responsibility to take precautions.

2010-04-07 16:40:00

Author:
Kiminski

Posts: 545

I really hope that's not the case.

Well, obviously not working for MM, I can't be sure (I only live about 10 minutes from their office - maybe I should pop in and ask them?

).

I merely base it on my experiences in software engineering, and what Anton said about looking into fixing it. Now since he said that, what, a year ago, and nothing's yet been done, I can only assume that it's either been marked as low-priority, or it's just too much of a pain to fix, and has been marked as WONTFIX (or whatever the non-bugzilla equivalent they're using is).

Either way, I doubt we'll see a long-term fix for this at any time in the future, although I hope I'm wrong about this. If the alleged integration of the PS Move into LBP requires any substantial core changes to the game engine and level format, then they might take the opportunity to fix this at the same time, but this is just speculation.

My level was far too big to move in one piece, I had to literally delete whole sections to try separate it all, the whole move took me days and days.

Don't let my somewhat unemotional writing style fool you into thinking that I don't sympathize for you, because I do. It's just that sympathy, unfortunately, isn't really going to help you out very much with this.

All I can say is that I have done the whole level-moving thing in the past for someone else, for an incredibly substantial level which they'd spent about a year working on. In this case, I successfully managed to capture the entire level as a single entity, and transfer it to a new crater. The only things that needed fixing afterwards were about six or seven pistons which were attached directly to the floor. The whole thing was fully operational again in about an hour.

If you still have a level with this problem, or get one in the future, I don't mind having a go at trying to fix it on your behalf, since, frankly, your levels are awesome enough to make it worth my while.

Profile bugs have been pretty much sorted with the introduction of backups anyway. While I feel very sorry for anyone who suffers a corrupt level/profile, any digital data is prone to corruption and it's our responsibility to take precautions.

Indeed. But my point was that, for those ignorant enough not to realise this, it's possible to lose a huge amount of work, with no chance of recovery. At least those people who are unaware of the 160-hour bug have the option of transferring their level to a new crater, and, even though it's a complete pain, it's arguably better than having to start from scratch.

2010-04-07 17:34:00

Author:
Aya042

Posts: 2870

All I can say is that I have done the whole level-moving thing in the past for someone else, for an incredibly substantial level which they'd spent about a year working on. In this case, I successfully managed to capture the entire level as a single entity, and transfer it to a new crater. The only things that needed fixing afterwards were about six or seven pistons which were attached directly to the floor. The whole thing was fully operational again in about an hour. If you still have a level with this problem, or get one in the future, I don't mind having a go at trying to fix it on your behalf, since, frankly, your levels are awesome enough to make it worth my while.

Lol thanks very much, I'll bear that in mind.

Unfortunately it just wasn't possible with my last one, I kept getting the red exclamation mark every time I attempted to place it whole, so that was a definite no go.

Gawd.. it's all coming back to me now lol.

Finally managed it in parts, but lost a lot of decorations that had been stuck to invisible materials and contraptions and despite having nothing attached to the floor at all, I still lost almost all of my connectors, or at least had the settings go nuts and break the objects they were attached to.

That said, maybe a fix for this problem doesn't need to deal with the actual bug at all, but merely offer us an easier way to copy our levels over to a new space...

2010-04-07 19:05:00

Author:
Kiminski

Posts: 545

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

The fully recovered level is now complete and published (Level Showcase link: Sack Scout Camp (https://lbpcentral.lbp-hub.com/index.php?t=25687-Sack-Scout-Camp)). Thanks for the help, everyone, in solving this problem.

-- Nanluin

2010-04-21 20:13:00

Author:
Nanluin

Posts: 98

Looks like I never knew what the 160 hour bug was... seems I,ve been working around it forever... currently the best I can manage on a piston is .05!!!! In the words of LOST's James Ford, "Son-of-a-B...."

2010-06-17 19:05:00

Author:
Gravel

Posts: 1308

Pretty simple to recover. If you need a spotter to help capture and move the whole thing over lemme know. I should be on this evening.

2010-06-17 19:08:00

Author:
jwwphotos

Posts: 11383

Wow, this bug is still a problem as of today! I know this is an old thread but I absolutely had to post my thanks to all of you. I had NO idea what's been going wrong with my level. I had .01 pistons not working and a very important set of emitters just wouldn't work all of a sudden. That level would be out by now if it weren't for this glitch

Anyway thanks to all who commented here, this will help me figure out how to solve my problem, whereas I had no clue at all what to do before!

2010-08-15 18:23:00

Author:
KAPBAM

Posts: 1348

I
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.

that's definitely the way to go. avoids other problems aswell. such as breaking other objects in your level.

that said, my level has the bug

was inevitable as i've been constructing this star destroyer for well over a year. the level has been rebuilt several times.
fortunately it only effected two pistons (all other pistons are set on 'direction&apos

. one piston had to be replaced with a Wobble bolt. the other (moving a bounce pad) still launches sack persons the correct distance., but studders a little in the process.

the level is a huge, & intricate monstrocity. moving it piece by piece to a fresh level would take me weeks. too many pieces are attached together. plus i can't remember where all the wires go

wish i joined LBPC earlier, so i could have learnt about such bugs before it was too late.

2010-08-17 09:23:00

Author:
sellfcon

Posts: 79

This bug freakin' sucks! Agghh!!! I think I have it again. It always happens in the end process of my level making. i kept the level in pause and rewinded after any events after something moved. This is the 3rd freakin time....but its wierd this time around. I have a .1 piston working from some emmiter logic that activates the piston to work but I try putting a new piston in at .1 and it wont work but the other does. And from my experiences, usually it'll gradually go up from .1 to .2 and so on but this time it went straight to .3. Any piston .3 or below wont move and this happened suddenly. Its really going to be frustrating to move this thing because it uses a heavy amount of decorations. This is because when you place an item with decorations on it some of them disappear for odd reasons. I might just work through it

2010-08-18 20:33:00

Author:
L1GhTmArE

Posts: 519

Just got this *&@$**## bug. I ONLY work in PAUSE mode, playing to test and then rewinding. What's more I have already thermo-hacked my level so it's going to be a REAL pain to fix this one.

WHY does it do this when I edit in pause mode????

Edit: Actually wasn't that bad - most of my level is simply dark matter boxes with emitters on so it worked straight away.

2010-09-22 14:26:00

Author:
thor

Posts: 388

You know what what happened to me the other day, I was hit with the unglue bug, but it only hit one iddy bitty section of my level,now these bugs are starting to be picky about what how they want to ruin our prescious created levels!

2010-09-22 15:08:00

Author:
damaz10

Posts: 771

Well I kept wondering why my waterfalls got worse and worse, then I finally lucked out on this post, because I thought it was somethign else. I only work in pause because all my levels have starting events that I can't let play otherwise it willdestroy the logic. I am at .5, my level is bigger than the level size (I have a gas cloud that goes wuite a distance out of the level. This makes it impossible to capture...or rather paste back in. I had to share tons of logic to finish this level, so rewiring will be next to impossible with devices taking all three layers sharing one mag switch because I ran out of thermo for switches wayyy back. The level works, but not as well as I would want it with some of the effects being stuck at .5. I only realized this was the issue when my other level had the pistons all stop from .4 and the mag switches and the other items unglue from the gas and repaste on the other material ??

2011-01-24 10:33:00

Author:
celsus

Posts: 822

Kills me every time I read these posts.

Anyway, thought I'd better mention that 0.5 seemed to be the last step before my level was broken beyond repair (Big fat juddery mess!), so I wouldn't hang about in create mode for too long if you can help it.

2011-01-24 16:16:00

Author:
Kiminski

Posts: 545

Kills me every time I read these posts.

Yup.. me too.

2011-01-24 16:34:00

Author:
jwwphotos

Posts: 11383

Lol, wonderful. I think I will make a few more copies and try my best to capture them. What happened after the .5 stopped working? I captured both levels, but with them taking up the entire space, and both having a little fog that gos off the level bounds completely I am not able to paste them in. I have to go and find all items that have nudged to the out of bounds and move the fog back in (one goes about 1/3 a level off the level), and I am sure that will take me time. I emailed MM, but not sure how much they will care about a LBP 1 level. I wonder if importing levels to LBP 2 will help?

2011-01-24 17:50:00

Author:
celsus

Posts: 822

Can you possibly make a copy of the level and then delete the fog? Then try to capture? It might be handier.. Also with someone spotting for you, it might be much easier.

The timeline of the level is simply that. Regardless if LBP1 or 2. It is the precision of math calculations based upon a very large number (the current time in the timeline of the level) causing the issue. Publishing in LBP2 will not reset the timeline. The only way to do that is capture your level, even if in sections, and paste them in a brand new untouched level.

2011-01-24 17:56:00

Author:
jwwphotos

Posts: 11383

Thanks for the warning, I almost published them LBP2. I am off to try for a twentieth time to capture the level. I pulled teh fog and all other items out of the out of bounds area, but it still is not capturing random parts.

2011-01-25 20:33:00

Author:
celsus

Posts: 822

2011-01-25 20:40:00

Author:
jwwphotos

Posts: 11383

What happened after the .5 stopped working?

It's hard to explain, but basically every moving part in my level either stopped working altogether or would only move in a blurred pulsing judder. - So when extending a piston from say 0 to 100 it would perhaps take 100 tiny bursts of movement to get there. Horrible!

I really can't believe this is still an issue in LBP2, it's crazy! I get that the problem may be unavoidable, but would it have been that difficult to provide us with an easier way to reset the timer? It's totally devastating to see months and months of work get destroyed like this.

2011-01-25 21:29:00

Author:
Kiminski

Posts: 545

2011-01-25 22:20:00

Author:
celsus

Posts: 822

I have to agree, I sent an email to MM, but not reply yet. I have just tried deleting the fog and clipping all the edges in, but now when I paste it in the new level it causes the PS3 to freeze. Three times in a row now, with three differemt captures and once using a second controller and blank profile for the capture.

I had an issue with decorations disappearing that I'd had stuck to invisible Dark Matter, but got round it by emitting the level instead. Obviously a different problem to what you've been getting, but could be more stable option perhaps?

With regards to LBP2, I'd definitely publish a copy to try it out. The higher zoom levels alone will make it easier to paste the level.

2011-01-26 11:30:00

Author:
Kiminski

Posts: 545

Lol, I just tried copying the level and pasting it LBP 2 and it froze the PS 3 there too, then on reboot the system sent a error report to Sony. I have to remake it for LBP2 anyways because it is emitting half of an object for some unknown reason, and that makes the level impossible to defeat. Plus the camera thermo and logic will allow me to make the entire ship. I just hope the emitter is not a sign of the 160 doing it's coup de grace.

2011-01-26 22:18:00

Author:
celsus

Posts: 822

I have a bug in LittleBigPlanet 2 where the physics at the right of a level is acting oddly, like objects going inside other objects, and floating in the air then going back to its place, is that the 160 hour bug? Or is it a new bug? New error of the 160 hour bug?

2011-02-05 17:13:00

Author:
EleoMod

Posts: 122

I have a bug in LittleBigPlanet 2 where the physics at the right of a level is acting oddly, like objects going inside other objects, and floating in the air then going back to its place, is that the 160 hour bug?

Sounds like a different bug - there's plenty to choose from in LBP2.

2011-02-05 22:41:00

Author:
Aya042

Posts: 2870

LBPCentral Archive Statistics

Posts: 1077139 Threads: 69970 Members: 9661 Archive-Date: 2019-01-19

Datenschutz

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.