How To Cheat The Thermo

[Aya042]

Introduction

To be more specific about "the thermo", I'm guessing this method will only let you cheat the following thermos (see comphermc's excellent Comprehensive Thermo Overview and Guide for more details)...

• Complex Shapes (investigations ongoing)
• Materials (you can use all 172 materials in a level simultaneously)
• Moving Objects (you can exceed the usual limit of about 1400 up to the 'shapes and objects' limit of about 2500)

...however, it's possible that a variation of this technique may allow you to cheat some of the other thermos too.

Edit: And indeed it does. My newer thread How To Seriously Cheat The Thermo makes this one look like the random mutterings of a mad man.

However, I'll leave this one here for posterity.


Method

N.B. I'm using 100 objects for this example, but you can theoretically use any number you like, up to the maximum number of blocks of dark matter which it's possible to place in a level.

1. Pause the simulation.

2. Create 100 blocks of dark matter, capture them all as a single entity, then delete the blocks.



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):-



Emitter
Lifetime: ∞
Max Emitted At Once: 1

Grab Switch
Behaviour: One-Shot

4. Unpause the simulation, set the emitter to emit the previously captured set of 100 blocks somewhere nearby, and then toggle the "Inverted" setting on then off again to trigger it once.

5. The objects you now have are thermo-calculated as the same 100 blocks of dark matter that are associated with the emitter's thermo calculation. What this means is, any changes you make to these objects don't affect the thermo at all. It still calculates them as being 100 blocks of dark matter regardless. Here's a picture where I've used this technique to have all 172 materials in a level at the same time:-




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, without increasing Max Emitted At Once, or else you'll lose all changes you made to the emitted objects.
• 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 that this cheat hasn't always worked in previous versions of the game, so bear in mind that MM may 'fix' this exploit in a later patch.
• You don't have to create all the blocks you'll need in a single hit. If you just emit, say, 100 at a time, then when you need another hundred, simply increase "Max Emitted At Once" by one, and trigger the emitter again. It seems I can tweak a 100-block emitter's setting up to 25 before the thermo goes mental, which implies you're limited to about 2500 blocks of DM.

[rtm223]

Hmmm, I can see how you are extending the materials thermo, but not the complex shapes thermo.... Moveing objects yes, if you glue to dark matter via an intermediate piece and crush that...

It used to be the case that changing to play mode / saving the level would lose the association between the emitted object and it's emitter, which would completely undermine this technique. Although rewinding used to do that too and I'm pretty sure that's been fixed recently, so probably this has too.

[Aya042]

Hmmm, I can see how you are extending the materials thermo, but not the complex shapes thermo.... Moveing objects yes, if you glue to dark matter via an intermediate piece and crush that...

I'm working on the assumption that the thermo calculation for the emitted objects is always the same as how the objects were originally emitted, regardless of how much editing you do, therefore adding an arbitrary number of vertices to one of the emitted objects will have no bearing on the complex shapes thermo calculation (which comphy's guide claims is roughly proportional the the sum of all vertices used). However, that's kinda awkward to prove right now.

As for the moving objects, that's easy to prove. The thermo difference between placing 100 blocks of dark matter compared to 100 blocks of, say, sponge, it quite apparent. So when I emit 100 blocks of dark matter, material change them all to sponge, and the thermo doesn't go up at all, that stongly implies that those 100 moving objects are not counted on the moving objects thermo.

I'm fairly certain that this technique works, but feel free to prove me wrong.

[rtm223]

(which comphy's guide claims is roughly proportional the the sum of all vertices used).

I'm willing to place money on the fact that number of vertices is only part of the equation for complex shapes. I don't know exactly what the rest is, but it's not just a vertex count

Sounds right though, if you were to emit blocks of DM (say 2499 of them, if my memory is correct), then corner edit your entire level out of that..... My god the posibilities are endless It would be tedious to test though as you'd have to do all the corner editing manually. Seems like a sound theory. Maybe capture an object that nearly maxes the complex shapes thermo and edit that for a while?

As for the moving objects, that's easy to prove. The thermo difference between placing 100 blocks of dark matter compared to 100 blocks of, say, sponge, it quite apparent. So when I emit 100 blocks of dark matter, material change them all to sponge, and the thermo doesn't go up at all, that stongly implies that those 100 moving objects are not counted on the moving objects thermo.

Lol, yeah just tweak... I didn't actually think of that

I'm fairly certain that this technique works, but feel free to prove me wrong.

As I said, my only doubt is that you can lose the association, but I think that got fixed up - probably to stop you losing the association when people join midway through a level. Seeing as rewind no longer does it, players joining no longer does it, it's probably safe that changing to play mode no longer does it either.

[comphermc]

Aya, you just blew my mind. First one to make a level that completely crashes a PS3 wins a shiny penny.

[Aya042]

...if you were to emit blocks of DM (say 2499 of them, if my memory is correct), then corner edit your entire level out of that...

That's kinda what I was suggesting.

It also seems that you can paint over them with the same material type (just added this to the OP), and the thermo doesn't go up either, so it's actually not much harder to do it this way than creating the materials from scratch.

As I said, my only doubt is that you can lose the association...

Well, so far I've listed the only ways I've found to lose the association. It seems that saving and reloading a level maintains the thermo savings. But, as I also said, my testing of this is not comprehensive.

My next test is to see how many different material types I can use at once without overflowing the hardware texture buffer (if it's in use). I'm also curious to see if attempting to overflow the buffer might provide a consistent way to recreate the transparent sticker glitch.

[Doopz479]

Aya, you just blew my mind. First one to make a level that completely crashes a PS3 wins a shiny penny.

I've done that without cheating the thermo...

[Luos_83]

I'm willing to place money on the fact that number of vertices is only part of the equation for complex shapes. I don't know exactly what the rest is, but it's not just a vertex count

Vertex count, polygon count, shader, Polygon optimisation-complexity
(I am not sure of shader, but most engines I have worked with store the shader (Shadows created on object) in the object itself.)
I also "Assume" the LBP engine will optimise Polygons in objects, optimisation in complex objects can actually result in being more complex for memory.

My next test is to see how many different material types I can use at once without overflowing the hardware texture buffer (if it's in use). I'm also curious to see if attempting to overflow the buffer might provide a consistent way to recreate the transparent sticker glitch.

Transparant stickers means the alpha channel in the created sticker got activated,
This might have nothing to do with stressing the buffer but just a random bug glitching while making a sticker, probably affected by the bg where the sticker is made and there are so many variables that I am starting to think simple overflowing the buffer wont cut it.
Me and adi's Arena/Magpie levels often overflowed the buffer causing either me or adi to crash when rewinding/selecting large/complex objects and no sticker we created glitched.
variables.. variables..
For all we know a speck of dust on the guys disc resulted in this glitch.

[rtm223]

Aya, you just blew my mind. First one to make a level that completely crashes a PS3 wins a shiny penny.

I've done that without cheating the thermo...

Comphy, I can crash your PS3 from across the atlantic without cheating the thermo lol

That's kinda what I was suggesting.

An alternative, would be to create a scene (scene c), capture it, emit it into the level, move it somewhere else and use the resources there to create a new scene (scene a). Place a third scene (scene b) inbetween the two.

Player plays through scene a, gets to scene b, emitter is triggered, scene a vanishes and scene b appears.


It will be interesting to see what this does to the game. Other thermo hacks are only possible by freeing up thermo elsewhere during play mode. This is the first hack I know of in create mode, which would mean that the entire thing is required in memory at once. Obviously having no idea how things are stored in the PS3's memory during playtime means we have no idea what the actual results of this would be. If you add hundreds of verteces beyond the limits of what is normally allowed, that data has to get stored somewhere

[Luos_83]

If you add hundreds of verteces beyond the limits of what is normally allowed, that data has to get stored somewhere

Eventually objects wont appear, their collisions are there but the engine is not able to render any new objects/stickers.
This can be undone by deleting complex objects in area's the player wont visit again.
Also removing complex objects after the player is "done" with them will probably empty out the memory again.
but best is just to optimise the shape offcourse

[Keldur]

I'm no supermind of LBP, so I am simply going to say what most of us who come through this thread think: Thanks.

Out of curiosity and interest, have you already used this technique in a full length level? However, if you don't have objective data, a subjective opinion would also work. Do you think this is reliable when applied in a full length level?

Somebody lock this thread exclusively for Spaff!

[rtm223]

Eventually objects wont appear, their collisions are there but the engine is not able to render any new objects/stickers.
This can be undone by deleting complex objects in area's the player wont visit again

Ummmm, that's my whole point. This is what you normally do with thermo hacks. You destroy the previous areas, creating space, then overload the thermo into that space.

Here we are (potentially) overloading memory to begin with. All the verteces are going to be in working memory at the start of the level and the physics engine will be using them. There is nothing to destroy yet!

[Luos_83]

Here we are (potentially) overloading memory to begin with. All the verteces are going to be in working memory at the start of the level and the physics engine will be using them. There is nothing to destroy yet!

good luck!

[Aya042]

Vertex count, polygon count, shader, Polygon optimisation-complexity...

I agree it's almost certainly more complicated than a simple vertex count, but unfortunately (without seeing the source code) we can only speculate about exactly what contributes to this thermo. However, I think it's reasonable to assume that the more vertices you have, the higher this thermo is going to get.

Transparant stickers means the alpha channel in the created sticker got activated...

Indeed. The only reason I'm suggesting this is that the best working theory about this so far is it's somehow caused by an occasional rendering failure on a material texture, and this might provide a way to recreate such a failure. But, as I said, it's highly speculative.

Me and adi's Arena/Magpie levels often overflowed the buffer causing either me or adi to crash when rewinding/selecting large/complex objects and no sticker we created glitched.

It's very easy to recreate a situation where the materials appear with warning sign symbols on them, but from looking at a video of someone exploiting the glitch, that isn't the way to do it.

For all we know a speck of dust on the guys disc resulted in this glitch.

Perhaps, but the fact that it's happened to more than one individual would suggest there's something more to it than a random speck of dust.

An alternative, would be to create a scene (scene c), capture it, emit it into the level, move it somewhere else and use the resources there to create a new scene (scene a). Place a third scene (scene b) inbetween the two.

Maybe I'm misunderstanding, but I don't think that would work. If you modify the blocks, then recapture, they lose their association with the emitter, even if you capture the emitter with them, so when you place that 'scene' into the emitter, it charges you the full thermo cost.

If you add hundreds of verteces beyond the limits of what is normally allowed, that data has to get stored somewhere

I don't think the game penalizes you that much for the actual amount of memory that the vectors take up, after all, it's completely marginalized by the amount of space that the maximum number of custom sticker bitmaps would take up.

Ditto for prize bubbles, which despite taking up very little thermo, actually have to store all the data about the objects contained within, somewhere in the level file.

You can get a rough idea of how much storage space a level needs by exporting it to a file and seeing how big that file is. I'd be willing to bet that those levels which use lots of custom stickers, and/or have prize bubbles which contain objects with lots of custom stickers, take up a lot more space than those which just use the maximum number of vertices possible.

Also bear in mind that you don't have to emit all the blocks in one go. If you just emit, say, 100 at a time, then when you need another hundred, simply increase "Max Emitted At Once" by one, and trigger the emitter again. It seems I can tweak my original 100-block emitter's setting up to 30 before the thermo goes mental, which implies you're limited to about 3000 blocks of DM.

[Luos_83]

I agree it's almost certainly more complicated than a simple vertex count, but unfortunately (without seeing the source code) we can only speculate about exactly what contributes to this thermo. However, I think it's reasonable to assume that the more vertices you have, the higher this thermo is going to get.

Not true, sometimes more vertexes can result in more optimal polygons, resulting in being smaller in filesize.