How To Seriously Cheat The Thermo

Introduction

It seems my previous post on the subject wasn't good enough for some people... ;)

Quote:

---

Originally Posted by comphermc

Quote:

---

Originally Posted by Aya042

Out of curiosity, which thermos tend to be the most problematic when building a typical level?

---

Shapes and collected objects. Make it go away! :cry:

---

...so after several hours of deep thought, and trial and error, I found a way to make comphy's day (and probably a few other people's too).

This method is kind of the same as the previous one, but in reverse. i.e. rather than emitting dark matter and 'editing' it to make it what you want, just emit what you want, and 'edit' it to make it dark matter.

This time, you can theoretically cheat all the thermos, by making any object, set of objects, or theoretically your entire level, only cost as much as one block of dark matter!


Method

1. Capture a single block of dark matter.

http://www.lbpcentral.com/forums/att...chmentid=13893


2. Capture the object, or set of objects you want to get for free, as a single entity. Here I'm using a variety of fairly complex MM objects which take up about 10 of the 16 notches on the thermo, since I'm too lazy to build anything that complicated for the purposes of a tutorial. :p

http://www.lbpcentral.com/forums/att...chmentid=13892


3. Create another dark matter block, attach an emitter and a grab switch, and wire the grab switch to the emitter. Use the following settings (leave unspecified settings at their default values):-

http://www.lbpcentral.com/forums/att...chmentid=13854

Emitter
Lifetime: ∞
Max Emitted At Once: 1

Grab Switch
Behaviour: One-Shot


4. Set the emitter to emit the previously captured object, or set of objects somewhere nearby, and then toggle the "Inverted" setting on then off again to trigger it once. Since you'll need to unpause the simulation to emit the objects, you'll have to be careful of gravity affecting those objects.


5. Now set the same emitter to emit the previously captured single block of dark matter somewhere nearby, but don't trigger it. As soon as you select its emitted location, watch in awe as the thermo drops to near zero, as you've just tricked the thermo into believing that the objects you previously emitted should be thermo-calculated as the same single block of dark matter that is associated with the emitter's thermo calculation.


Caveats

There's a few rules on what you can and can't do with the emitted objects in order to retain the thermo savings. These lists are by no means exhaustive, but should give you a general idea:-

Things you can do

• Move or resize the objects.
• Change the material types of the objects.
• Extend (with a brush the same material), cut into, or corner edit the objects, although if you split an object into two pieces, then one of them will not count as being one of the emitted objects.
• Glue or attach to another object with any connector.
• Attach mag keys, switches, etc.
• Embed another material inside, although the embedded material won't be 'free'.
• Lethalise and unlethalise the objects.

Things you can't do

• Delete any of the emitted objects. If you do, then the emitted objects are no longer deemed to be the same as the ones in the emitter. It seems that you can crush one of the objects with a heavy object, and it will still be okay.
• Delete the emitter which emitted the objects. If you do, then the objects lose their association with the emitter and will take up their full thermo space.
• Trigger the emitter again, or else you'll end up with just a single block of DM.
• Copy and paste any of the objects. Well, you can, but the copy won't count as one of the emitted objects.

Other tips

• It should be pretty obvious when you break the association with the emitter, because the thermo will suddenly jump. If this happens, just rewind and rethink. :)
• Be aware that cheating the thermo in this way makes it much easier to create a level which the game engine can't handle, so be careful.
• rtm has suggested cheats of this nature haven't always worked in previous versions of the game, so bear in mind that MM may 'fix' this exploit in a later patch.
• Capturing and emitting certain combinations of objects seem to prevent you from subsequently selecting individual objects independantly. I'm not sure what the exact criteria are for this to occur, but you can always work around it by emitting problematic objects separately using another emitter.

Now you're just being silly ;)

You are unbelievable... WOW

Quote:

---

Originally Posted by rtm223

Now you're just being silly ;)

---

I thought you might like this. I'm expecting SS redux to be twice the size of the original. :p

There are still a few oddities with this, particularly when emitting multiple objects at the same time. Now, as I said, you can emit them separately if you like, but what happens when you use up the collected objects thermo with all the emitters and grab switches you need to leave lying around?

Simple, just emit those emitters from another emitter, and you can get all those for free too. Your entire level should never require more thermo than:-

• Two blocks of dark matter
• One emitter
• One grab switch

Funky, eh? :)

Of course, this still has the same limitation as the previous method. Once to push things too far you can't actually add new material to the level without the use of an emitter. Which yesterday was too hard for the average creator ;)

Surely this does register on the Invisible thermo, as in Game Memory, but the visual representation doesn't catch it?

Quote:

---

Originally Posted by rtm223

Of course, this still has the same limitation as the previous method. Once to push things too far you can't actually add new material to the level without the use of an emitter. Which yesterday was too hard for the average creator ;)

---

I actually said "too annoying". :p

I guess you could argue that you'll still have the complex objects limitation, but since this technique makes it so simple to build your level in smaller pieces on different craters, then emit them into a single level, and piece them together, that you might be able to get away with it, although you'll still be "playing with fire".

This is only based on your observation that you could seemingly break the complex object limitation if you only ever emitted parts into your level, rather than placing them in the old-fashioned way, but since I haven't actually tested that theory, I'm taking your word for it.

Therefore my claim that this can break all the thermos is based on your word, so if I'm wrong, it's all your fault. ;)

:O nice ill try it out

Quote:

---

Originally Posted by Aya042

so if I'm wrong, it's all your fault. ;)

---

Ah, the ol' passing of the baton of blame. Nice.

---

Seriously, though. Are you rain man? Quick, how many toothpicks?

http://luciezook.files.wordpress.com...toothpicks.jpg

Quote:

---

Originally Posted by KernelM

Surely this does register on the Invisible thermo, as in Game Memory, but the visual representation doesn't catch it?

---

I'm really just judging it from the POV of what the visible thermo tells you. Now there may be other limitations, which I stipulated to in the OP, but there's really nothing I can do about those.

Another oddity I have noticed, which might be attributed to "invisible" limitations is that eventually, some blocks of material will fail to render, but I'm not sure if this is due to an invisible "objects too close together" limitation or an invisible "too many objects" limitation, because my tests generally involved cramming as many blocks of DM into as small a space as possible, just to make things easier.

However, since it actually started happening long before I even hit the standard 2500 objects limitation, I'm more inclined to believe that it's just a case of the objects being too close together, which is generally less of an issue in a real level. Although it was perfectly happy to let me emit more than 2500, albeit invisibly, into the level.

On the other hand, it was perfectly happy with rendering 2000 mag keys (which is over the usual limit of 1400) on the screen at the same time. So if you just want some uber-complex logic, you'll probably be okay.

Quote:

---

Originally Posted by comphermc

Ah, the ol' passing of the baton of blame. Nice.

---

Not that I really need to. I think I used enough instances of the word "theoretically" in the OP to absolve myself from any blame. :)

Quote:

---

Originally Posted by comphermc

Seriously, though. Are you rain man? Quick, how many toothpicks?

http://luciezook.files.wordpress.com...toothpicks.jpg

---

None. I only see 50,500 pixels. :p

Quote:

---

Originally Posted by Aya042

I guess you could argue that you'll still have the complex objects limitation, but since this technique makes it so simple to build your level in smaller pieces on different craters, then emit them into a single level, and piece them together, that you might be able to get away with it, although you'll still be "playing with fire".

---

That is exactly what I was thinking about it the other day. This is going to be one of those things that we will either have to prod gently to see how far it can go, or wait for someone to really go mental with it and see what state they end up in :p

On a side note, I'm not going to be using this in setbacks. To much risk to subject my baby to it, much as I'd love to ram the thing with extra detail.

Quote:

---

Originally Posted by Aya042

Quote:

---

Originally Posted by comphermc

Seriously, though. Are you rain man? Quick, how many toothpicks?

http://luciezook.files.wordpress.com...toothpicks.jpg

---

None. I only see 50,500 pixels. :p

---

Lol, this reminds me of a conversation the other day. I'm still waiting on an answer comphy:

Now, I was thinking about this a bit more and am wondering about the practicality of it all. It all rests on the following question: Can you copy the 'Cheating' objects and emitter block and transfer them to a new level, while maintaining the trick?

If not, I see one of two problems:

1. If you need the glitch, then you are tight on space. Good luck getting the objects into the level to pull of the glitch in the first place.
2. You did the glitch before building the rest of the level, and even though your thermo says you have plenty space, you reach the ceiling for whatever thermo you are tricking, and it won't let you place anything new.*

Forgive me if I am not understanding its uses in its entirety.

*This is all based on the assumption that the limit still exists, but the thermo is not telling you about it. Hm... perhaps I need to either read the thread again, or do some testing.

:)

Edit: Okay - I'm going to try something. I'm going to capture the beginning of my latest level and emit it, thereby tricking the emitter. Then, I'm going to see if I can add more to it. If I can, I will be giddy as a teenage schoolgirl, and will report my findings.

Quote:

---

Originally Posted by comphermc

1. If you need the glitch, then you are tight on space. Good luck getting the objects into the level to pull of the glitch in the first place.
2. You did the glitch before building the rest of the level, and even though your thermo says you have plenty space, you reach the ceiling for whatever thermo you are tricking, and it won't let you place anything new.*

---

1 is an issue, although you could use yesterday's technique to help get around that. 2: just emit the new objects into the level. You can't place, but you can emit. This invisible limit is identical to the visible limit, but it only affects things you place manually as far as I could tell yesterday.

At the end of the day, it may well not be that practical... And it may just crash your system. As we've seen, a heavilly maxxed out level is highly liable to crash anyway and this will only add to the strain on the engine.

http://www.lbpcentral.com/forums/att...4&d=1268340876
I seriously could not be bothered... I avoid logic any more difficult than Logicpack beginner... That's my main weakness. So this looks freaky as heck to me. I don't know how you find it fun...
Ps. Javi move out of the way your heads too big! :D

Nice job Aya.

Holy crap! It worked, I was able to cleanly add 21 more bubbles to level. Wow, awesome!

Quote:

---

Originally Posted by comphermc

Can you copy the 'Cheating' objects and emitter block and transfer them to a new level, while maintaining the trick?

---

No, but why would you need to?

The way I see it, for a new level, you'd do something like this:-

1. Build section 1 of your level in one crater, and capture the whole lot.
2. Build section 2 of your level in another crater, and capture the whole lot.
3. Go to a third crater, and set up two emitters to emit both those sections into the level, as per the OP.
4. Pick up the whole of section 2, and link it to section 1.
5. Result: one level twice the size you could get using traditional techniques, and still zero thermo.

For extending an existing level, just capture that level in its entirety, and use the same technique to link it to a new part.

Point is, for safety, build the sections of your level using traditional techniques, but don't let any single section of your level exceed the thermo. Always re-edit the original craters, then join them back together on a different crater. That way, if the merged level does have problems, you still have the original pieces to work with.

Of course, this can get annoying if you have many wires you need to connect when you're joining the sections together, but you can minimize this by splitting the whole level into sections where they required the least amount of interconnection.

Imagine the Ama Toor project as one level... this find is crazy!

Quote:

---

Originally Posted by ladylyn1

Imagine the Ama Toor project as one level... this find is crazy!

---

I don't know that one, but comphy's Aperture Science series might be a good test case for this, since the levels pretty much carry on one from the other, and they're already fully independant from a wiring POV. If he could successfully link all three parts (or even just the first two parts) into a single level, that would be a pretty good indication that this might actually be useful from a practical POV.

This couldn't have come at a better time... thank you sooooooo muuuuch!!!!!! :)

Quote:

---

Originally Posted by Aya042

Of course, this can get annoying if you have many wires you need to connect when you're joining the sections together, but you can minimize this by splitting the whole level into sections where they required the least amount of interconnection.

---

You could some sort of interface between sections, like a central bridge where everyone gets an address and you can send each other data. In fact, we should get started on the ISO standard right now, or everyone will start drifting apart into level-interconnectivity hell. ;)

Great work!
This could be really helpful for me :D

*picks jaw up off floor*

wow - ok I know I won't be trying this but I'm glad someone is and if people can make this work (and it sure looks like they can) I'm really looking forward to bigger and more complex levels.

Excellent work Aya (and RTM & comphy too) :)

Quote:

---

Originally Posted by Rogar

You could some sort of interface between sections, like a central bridge where everyone gets an address and you can send each other data. In fact, we should get started on the ISO standard right now, or everyone will start drifting apart into level-interconnectivity hell. ;)

---

Y'know I thought about something like that, i.e. using uber-complex logic to mux the outputs from multiple wires onto a single wire, but I thought that'd be too geeky for most people. :)

I mean, you can already do it with a remote three-way, i.e. mux two directional wires onto one, although you can't have both active at the same time.

However, this might finally let me build my simulation of a simple microprocessor, like the Intel 8008. It only uses a few thousand transistors, so I ought to be able to do it with a similar number of connectors, mag switches and mag keys. The closest thing I've seen so far is rymdisen's "Fibonacci Computr" (sic) level, which actually has three registers, a data bus and an 8-bit full adder to calculate the Fibbonacci numbers.

I still think I'd be out of luck with my ZX Spectrum emulator though. ;)

Thanks for this, I'll try it out soon.

Big kudos for figuring this out, but I must say that this is the first exploitable glitch in lbp that I've been afraid to use. I'm sure you all will be doing a fair amount of testing to see exactly what you can and can't get away with (maybe I should even try a test: I've got a 3 part level that was really meant to be a 1 part, but I had to chop it into pieces and put them in seperate craters to continue building them... maybe I can try emitting them back together and see if it really works).

Anyway, the thing that really makes me nervous is that this isn't like other glitches: you're not getting a material that's a combination of others or sticking an object in a layer it shouldn't be able to go. You're messing with the way the game engine deals with resource/memory allocation. As you said: "Playing with fire." While I wouldn't expect a future patch to ruin levels with 3d glitched stuff or material glitched stuff, I could see a future patch easily messing up thermo exploits and making levels completely un-loadable, whether Mm does it on purpose or not.

Quote:

---

Originally Posted by Morgana25

wow - ok I know I won't be trying this but I'm glad someone is and if people can make this work (and it sure looks like they can) I'm really looking forward to bigger and more complex levels.

---

Oh yeah me to! I'm now waiting for a calculator that can do adding, subtracting, multiplication, division and lets stick in maybe a bit of decimals and powers and ooh how about pi? To far? :p

I've done a little bit of experimenting and im now going to publish Planet X with the extended thermo... lets see if it works.

Not useful to me.

I prefer to create with limitations; too much space will result in levels that are unnecessarily long or needlessly complex. It's not for me.

Just follow the rules that they give you, guys. :B

Quote:

---

Originally Posted by Sehven

Big kudos for figuring this out...

---

Y'know, despite the number of complicated ideas I had about this which didn't work (including several variations on SteveBigGuns' approach to emitter-based thermo-cheating), when I look back at it now, it seems so simple and obvious in retrospect, that I'm almost ashamed that it didn't occur to me ages ago.

To be fair, I've never built a level big enough to even vaguely tax the thermo, so it was never really a priority, and I've only recently discarded my hatred for emitters, since I've always found them to be painful to configure, and quirky in their operation.

Quote:

---

Originally Posted by Sehven

...but I must say that this is the first exploitable glitch in lbp that I've been afraid to use.

---

I don't think you're alone there, and you probably should be a little cautious. This is a very new, and highly theoretical technique, which hasn't had enough time to go through many practical tests - hence all the warnings in the OP, but even without the thermo limitations, the game shouldn't let you create levels which crash the PS3.

So, if we assume that the reason that the thermo exists is to prevent you from creating levels which won't run smoothly, then it seems as if the thermo is a little too paranoid in some cases (e.g. materials and collected objects), and a little too forgiving in others (e.g. framerate slowdown with high object density, or when using certain lighting effects). At least now you have the choice to override its paranoia, when you believe it's appropriate to do so.

Quote:

---

Originally Posted by Sehven

I've got a 3 part level that was really meant to be a 1 part, but I had to chop it into pieces and put them in seperate craters to continue building them... maybe I can try emitting them back together and see if it really works.

---

That's exactly the sort of thing I'm hoping will be possible. I'd be very interested to know if you have any success with that.

Quote:

---

Originally Posted by Sehven

You're messing with the way the game engine deals with resource/memory allocation. As you said: "Playing with fire."

---

Well, maybe I was being a little over-dramatic. :)

With regards to memory allocation, I strongly suspect that there are hard limits in there somewhere, but that they're just much higher than the thermo normally allows. I mean, for all we know, maybe the development versions of LBP used by their level designers, actually have a "disable thermo" option somewhere.

Quote:

---

Originally Posted by Sehven

I could see a future patch easily messing up thermo exploits and making levels completely un-loadable, whether Mm does it on purpose or not.

---

That's probably the greater concern, which is why I suggested building levels in the traditional way, but in a more modular fashion, where no single module ever overrides the thermo, and then assemble them using this method. Worst case scenario is you lose the assembled version, but you still have the individual parts - giving you the option to republish as a series of levels.

Quote:

---

Originally Posted by Aya042

I don't think you're alone there, and you probably should be a little cautious. This is a very new, and highly theoretical technique, which hasn't had enough time to go through many practical tests - hence all the warnings in the OP, but even without the thermo limitations, the game shouldn't let you create levels which crash the PS3.

---

Unfortunately that last part is incorrect. I can tell you from experience that the game absolutely does do that. I have been in levels that do crash my PS3 every time. Infact my friend Alvaro is doing a new level as we speak and he's invited me into it twice and both times it's crashed both of our systems. I have since asked him never to invite me in that level again as I've only recently had the YLOD and I don't want it happening again.

Lol. Tomorrow I'm going to try exactly what you suggested... tacking together Aperture Science 1 and 2. If I can pull it off and it still works, that would be incredible. Wow, that level would be long!

:p

Quote:

---

Originally Posted by mistervista

Quote:

---

Originally Posted by Aya042

...the game shouldn't let you create levels which crash the PS3.

---

Unfortunately that last part is incorrect. I can tell you from experience that the game absolutely does do that.

---

I said "shouldn't" not "doesn't". Every game has bugs in it, and I know of at least one method which is guaranteed to crash LBP every time. Point is, I've exploited this glitch in a number of cases and suffered no adverse effects, and, conversely, I've exploited no glitches at all, and suffered very adverse effects, such as major profile corruption.

Quote:

---

Originally Posted by comphermc

Tomorrow I'm going to try exactly what you suggested... tacking together Aperture Science 1 and 2. If I can pull it off and it still works, that would be incredible. Wow, that level would be long!

---

If you can pull it off, it would indeed be awesome. Let me know how you get on with that.

Wow, interesting discovery you did :)! Thank you very much for sharing this knowledge.

Indeed the possibilities this thermo trick gives us are vast, making us tempted to do lots of stuff.

One can only hope he / she doesn't go overboard with this trick as consequences could be bad.

Rename the thread:

How To Bit**-Slap The Thermo :p

This is unbelievable! I better make use of it quickly before it gets patched and haunts me forever...

Quote:

---

Originally Posted by Sehven

Anyway, the thing that really makes me nervous is that this isn't like other glitches: you're not getting a material that's a combination of others or sticking an object in a layer it shouldn't be able to go. You're messing with the way the game engine deals with resource/memory allocation. As you said: "Playing with fire." While I wouldn't expect a future patch to ruin levels with 3d glitched stuff or material glitched stuff, I could see a future patch easily messing up thermo exploits and making levels completely un-loadable, whether Mm does it on purpose or not.

---

Hmmm, they seem to make a point of preventing people from creating the glitch, rather than preventing already glitched objects from being broken. So for example, a sensible patch, based upon the approach that MM seem to take would be to alter the code so that the disassoiation from the emitter occurs WHEN you change te object in the emitter. This would leave existing levels using the exploit working fine, but prevent it from being used in the future.

Similarly, for the other variant, force the disassociation when someone edits any part of the object linked to the emitter.

I'm still just as wary as you are about this, I'm just saying it would be perfectly possible to patch this in such a way that it wouldn't break existing levels. I'd still caution people from using it for many many different reasons though!

Yes, but that only applies if the patch is a deliberate attempt to fix this glitch. There's always the possibility (at least I think there is: I don't know much about game code) that a future update just might happen to change the way memory allocation (or whatever else is involved in the limits set by the game) works in a subtle way that one wouldn't notice in most levels, but could completely ruin overloaded levels. Kind of like how leerdammer changed the way that save data works, it's possible that a future update could change how the thermometer works.

I admit that I find it unlikely... but it's enough of a possibility that I'd be wary of spending weeks or months on a level using this particular exploit. As Aya said, though, levels can be designed modularly and kept in separate craters so you don't lose everything if that happens, but it would be a shame to lose all the plays/hearts/comments of a published level if it were to happen.

Anyway, you (Rtm) and Aya are pretty level-headed and seen to have a very good grasp on logic (like actual logic... as well as lbp logic) so I'm sure you'll do alright with the glitch. I just don't think I'll be making extensive use of it.... might be fun to go back and make my "Starfighter" level longer, though: the thermo forced me to cut it way shorter than I originally planned, and I could probably build a whole new level with the existing tools in a relatively short amount of time.

I played around a bit with Morgana and Jwwphotos earlier, trying to exploit the thermometer as much as we could. Our testing was far from exhaustive, but when we really started to load up on the objects in the level (mind you, the thermo says it is nearly empty), the framerate dipped, but nothing ceased to work.

Then we proceeded to fill the level with non-emitted, traditional complicated stuffs. When we maxed this out, it wouldn't allow us to place anymore, while giving the "this object is too complex" message that you get when a shape cannot be cut into anymore. I think this was mentioned already, but it's interesting. At any rate, once this was finished, we started deleting the emitters. The thermo spiked each time we did this, and eventually overheated. Like I said, this was not exhuastive, and there were 3 of us just screwing around, so I'm not sure how much beyond the limit we had gotten.

---

As for my Aperture Science Redux... I ran into a little niggle. Both levels are very horizontal, and run completely left-to-right. fitting them seamlessly won't work without a redesign. Perhaps it's that time, eh?

I will, in the very least, attempt to fit both levels into a single one, albeit not necessarily in working order.

how to seriously blow up your ps3...thanks...alot :kz:

lol jk

you can always just put one ontop of the other and just have the player teleported to the start of the second half once they are finished with the first :D

Quote:

---

Originally Posted by comphermc

I played around a bit with Morgana and Jwwphotos earlier, trying to exploit the thermometer as much as we could. Our testing was far from exhaustive, but when we really started to load up on the objects in the level (mind you, the thermo says it is nearly empty), the framerate dipped, but nothing ceased to work.

---

Well this sounds about right really. You are pushing the engine and so it can't get everything done in realtime, so you lag. At least this is a nice indicator. You can push things and the game communicates something back to you before breaking :)

Any idea roughly how much you fit into a level? And littlebigdude has a point, if initially this is just for the purposes of testing, then just place them above each other and add a teleporter to begin with.

Quote:

---

Originally Posted by Sehven

...it's enough of a possibility that I'd be wary of spending weeks or months on a level using this particular exploit. As Aya said, though, levels can be designed modularly and kept in separate craters so you don't lose everything if that happens, but it would be a shame to lose all the plays/hearts/comments of a published level if it were to happen.

---

A valid concern, although as rtm pointed out, MM have done a pretty good job (unlike Sony Cambridge with the infamous Strawberry Cheesecake update :p) of ensuring that updates to the game don't ruin existing levels, but merely prevent you from using certain glitches in the future.

Quote:

---

Originally Posted by Sehven

Anyway, you (Rtm) and Aya are pretty level-headed and seen to have a very good grasp on logic (like actual logic... as well as lbp logic) so I'm sure you'll do alright with the glitch.

---

I probably won't even use it myself, since I generally don't tend to build large levels (or indeed any levels at all). Frankly, the main reason I attempted to find a better way to cheat the thermo was because comphy kinda challenged me to, and I always enjoy a good challenge. :)

As for rtm, he's already suggested that he won't risk using this on SS redux, and I don't blame him. He's clearly spent a long time building that level, and would be extremely annoyed if he finds he's unable to edit it after the next patch.

Quote:

---

Originally Posted by comphermc

Our testing was far from exhaustive, but when we really started to load up on the objects in the level (mind you, the thermo says it is nearly empty), the framerate dipped, but nothing ceased to work.

---

Pretty much the same results I got.

Quote:

---

Originally Posted by comphermc

Then we proceeded to fill the level with non-emitted, traditional complicated stuffs. When we maxed this out, it wouldn't allow us to place anymore, while giving the "this object is too complex" message that you get when a shape cannot be cut into anymore.

---

Interesting. With the previous technique, I started getting this message long before the thermo reached the top. I haven't tried it with the new one yet.

Quote:

---

Originally Posted by comphermc

As for my Aperture Science Redux... I ran into a little niggle. Both levels are very horizontal, and run completely left-to-right. fitting them seamlessly won't work without a redesign.

---

Hah! I was wondering if that might be the case, but I assumed you'd already taken that into account. :)

Quote:

---

Originally Posted by rtm223

Well this sounds about right really. You are pushing the engine and so it can't get everything done in realtime, so you lag.

---

That sort of behaviour I was expecting, after all, you get that without using this 'hack', like when the game briefly pauses with long emitter chains.

I've done a bit of games programming before, although nothing as complicated as LBP. With a 'simulation' game like LBP, there's generally two 'expensive' parts: the simulation engine, and the rendering engine. The difference between the two is that the simulation engine has to consider every active object in the whole level on each simulation tick, whereas the rendering engine only has to worry about what is actually visible on the screen, although it's still much more expensive than the simulation engine. This will almost certainly be the reason why:-

1. it won't let you put many objects close together
2. it won't let you zoom out the camera particularly far

The more interesting point is that neither of the two engines use all that much memory, they're just highly CPU-intensive, so as you continue to increase the number of objects in the level, it will just slow down. Generally you only crash the system when you either run out of memory (which with virtual memory is very difficult to do), or your code just sucks (which is far more common). :)

The other symptom I've seen, where objects fail to render, might actually be a limitation of the PS3's underlying graphics API. The code says to the API, "here's all the polygons I want you to draw on this frame", and eventually the API replies with "that's too many, I can't do any more". Other games (e.g. GTA4) work around this limitation by reducing the detail as you zoom out, but LBP seemingly doesn't do this, presumably because you can't zoom out that far in play mode, or even in create mode.

The problem with the thermo, is that it always considers the worst case scenario, e.g. its limitation of 1400-ish moving objects at once is based on what it can reasonably handle in the worst case, i.e. where they're all moving at the same time. In a real level, however, this isn't the case. Generally the player will be confined to a single part of a large level, meaning that it's okay to have 14,000 moving objects, as long as only 10% of them are moving at any particular time.

This is why I believe that the game can quite easily handle much more than the thermo will let you, and as long as know why the limitations exist, you should be able to figure out when it's appropriate to exceed them.