Archive: 37 posts

---

I vaguely remember somebody saying something about a glitch that would let you make gas invisible and non-deadly to sackboy by making it thin. Like in a thin or theck layer so sackboy can't run into it. Or, maybe he was talking about using the layer glitch to put it outside the play area: I can't remember. If there is a glitch to make gas thin or theck, does anybody know how to do it? I tried doing a forum search, but "gas" is too short of a word, so the search engine just ignores it.

2010-03-16 04:18:00 Author: Sehven Posts: 2188

---

I recall that it's possible to mak thin gas, but it's invisible and can't kill you. I don't know if you could planeshift through it or not and I don't know how to make it either. Have you tried gasifying a theck block yourself? A very interesting thought.

2010-03-16 04:38:00 Author: Incinerator22 Posts: 3251

---

I thought I had heard of being able to gassify theck material. I'm off to sleep though. Guess you can check for yourself...

2010-03-16 05:32:00 Author: comphermc Posts: 5338

---

If there is a glitch to make gas thin or theck, does anybody know how to do it? I tried doing a forum search, but "gas" is too short of a word, so the search engine just ignores it. I do have an thin-layer gas object, but it's invisible. What effect are you trying to achieve?

2010-03-16 12:40:00 Author: Aya042 Posts: 2870

---

Isn't (wasn't?) this similar to the plasma glitch, where you kill a creature with a hazard and then capture it before it dies?

2010-03-16 12:43:00 Author: rtm223 Posts: 6497

---

He wants to use it as part of a stabilizer... and I think rtm may be right.

2010-03-16 12:45:00 Author: comphermc Posts: 5338

---

He wants to use it as part of a stabilizer... you can make this work with out making the wheel thin. the gas stabilizer can be operational "inside" a thick layer wall. Keep it far enough from the edge and it's non-lethal.

2010-03-16 15:06:00 Author: IStwisted Posts: 428

---

Yeah, I know that I can just put it inside, and that's what I'm currently doing (actually, I'm keeping a hole cut in the material it overlaps to make it easy to see the gas and select it if I need to reset the stabilizer after moving the vehicle). But it would be nice to have the option of using a thin layer instead: using the overlapping method, I still have to have a thin layer behind it so I have something to bolt the gas to. Unless a thick layer of gas can be bolted to a theck backplate. Hadn't thought of that until just this minute. And if thick gas can't be bolted to theck backplate, I wonder if a golfball can be gassed and bolted to theck. When it comes to my mech building, I'm always trying to keep things as efficient as possible: have to keep those layers open for other things. Aya, next time I see you online, I'll shoot you an invite if that's ok with you. Thanks for the tips everybody. I'd only read about this glitch once and didn't really care at the time, so I never looked into it. So if it's part of the creature killing thing, does that mean any of its properties are broken? For example, when you kill peach floaty to get a material that sackboy can walk through, it doesn't float any more. Does the gas still float?

2010-03-16 20:58:00 Author: Sehven Posts: 2188

---

I do have an thin-layer gas object, but it's invisible. can you still place mag keys on it?

2010-03-16 21:58:00 Author: IStwisted Posts: 428

---

can you still place mag keys on it? Yes. In fact, in anticipation of Sehven's intentions, I tried it out in a rotational sensor configuration, and it seems to work - even underwater, but my testing wasn't particularly thorough. Oh, and it's proper gas, as in deadly gas, not the result of some creature brain hack. I don't know how to create it, so it's copied from someone else. Weird thing is, you can't unlethalise it, even after making it thick.

2010-03-16 22:05:00 Author: Aya042 Posts: 2870

---

I tested gas sensors with oLMCo yesterday and they seem to be perfectly reliable, even underwater: water is a HUGE weakness with the floaty sensor. Actually, it's probably the transition from air to water that screws up floaty sensors, not being totally immersed in it, but either way gas sensors seem to be immune. I'm not really sure what the physics properties of gas are, but it seems to be immune to the drag/inertia issues that we've been discussing in that other thread. I guess I'll have to glue a huge block of gas to one side of a rocket to see for sure. I also suspect that it has no bearing on an object's weight (like if you made a scale and put equal weights of material on each side and then glued a big block of gas to one of them, I don't think it would affect it). To make a sensor out of gas, it still has to be balanced, though: bolted in the center; so maybe my guesses on gas physics are off. Anyway, it seems that it's the most accurate tilt sensor possible in lbp, and quite a bit more reliable than the floaty ones I've been using.

2010-03-16 22:29:00 Author: Sehven Posts: 2188

---

IS it part of the trasmorph glitch where you can resize stuf? In theory that could work for making gas thin. (this is where you get sed item, put a big block of sponge around it. capture it. make an emitter emit it for infinity life and max emit one. Change it how you want it. emit it and capture that, bish bash boom.

2010-03-16 22:31:00 Author: flamingemu Posts: 1872

---

Fun fact... gas has zero mass and, as expected, doesn't interact with anything if not connected via a bolt, rod, piston, etc. I have used gas as the material between a series of connectors, with no stability issues. I'm not sure it would be worth it to make logic this way, but it's an interesting thought nonetheless. I used in in Interstellar Infiltration. The spacecraft at the end was on a piston, and then there was a piston attached from the ship to a gassed light, which has a piston attached to yet another gassed light. Yet, there was no sagging, and it worked very well.

2010-03-16 22:34:00 Author: comphermc Posts: 5338

---

Thanks, flamingemu. I'll have to try that. [edit] Didn't work. It was wierd: the thicken/thin buttons just moved it between layers. I had to double check to make sure I was pushing the right buttons. Comph, that's really interesting. Are you saying that gas cornerstone piston rigs are immune to the sagging you normally get, or was it more the way you built yours that did that? Awesome level, btw. [edit s'more] Got the thin gas from Aya. Works perfectly and, as an added bonus, doesn't make the flies buzzing sound that you normally get with gas. Tried gassing the cornerstone of one of my starfighter ships 'cuz Comph's comment intrigued me. Disastrous failure. I have no idea why, but as soon as I started moving, the cornerstone shot out from under me until the piston broke. Did I just not understand the comment, or is it possibly a design issue with my ship?

2010-03-16 23:54:00 Author: Sehven Posts: 2188

---

Sorry but what is theck

2010-03-17 02:04:00 Author: Shhabbazz Posts: 746

---

It's a complex glitch where you can divide a regular thick layer into two more, theck and thack layers (I don't know who in the right mind named them these, lol). Theck aka Checkpoint-thick material is the same as regular thick material except sackboy and thack materials can go in front of it. Thack aka point bubble or golfball thick material is the same as regular thick materials except it can pass in front of theck materials. Looks-wise, thecks are slightly thicker-looking than thins and thacks are fatter than thecks and thins but smaller than regular thicks.

2010-03-17 02:31:00 Author: Incinerator22 Posts: 3251

---

Comph, that's really interesting. Are you saying that gas cornerstone piston rigs are immune to the sagging you normally get, or was it more the way you built yours that did that? Awesome level, btw. No, not the cornerstone, but as every piece in the 'chain'. For example, go DM > gas > gas > gas > gas > etc. You will not get any sag anywhere as long as you have gas connected to more gas. I've seen people make glass rails supporting long chains of floaty material, but if you use gas, there is no need. Also, as far as I can tell, gas doesn't tax your thermo any more than using the regular material. Lol, I can just imagine all of the failure that must've accompanied using gas as a cornerstone.

2010-03-17 03:05:00 Author: comphermc Posts: 5338

---

Lol. Gas is completely unpredicable when connected to complex unstatic objects. But comph, how hard did you test them? If that's true, that the don't sag or snap at at, that's amazing.

2010-03-17 03:09:00 Author: Incinerator22 Posts: 3251

---

Got the thin gas from Aya. Works perfectly and, as an added bonus, doesn't make the flies buzzing sound that you normally get with gas. So does this thin layer gas still visible? you can still change the gas color? If visible, that could help me for the level I started...

2010-03-17 03:10:00 Author: dajdaj03 Posts: 1486

---

I'll go try some more thorough testing. Edit: well, it worked sufficient well for as many as 6 in a row. Beyond that, I think rounding errors become a problem.

2010-03-17 03:11:00 Author: comphermc Posts: 5338

---

Thin gas is invisible, and sackboy can't layer change through it. I guess that means it could be used to keep sackboy in one layer, but 2-3 layer objects could still pass through it, unlike a wall of invisible material.

2010-03-17 04:44:00 Author: Sehven Posts: 2188

---

Beyond that, I think rounding errors become a problem. What do you mean by rounding errors? Also, sehven, have you tried using the vulnerable creature trick?

2010-03-17 04:47:00 Author: Incinerator22 Posts: 3251

---

That was patched some time ago: before potc, I think. And yes, I did try it anyway. It makes thin gas that acts exactly like the stuff Aya gave me so that's probably how it was created, but since the patch happened, there's no way to keep it from disppearing after you kill it with a creature brain. Rounding errors are a glitch in lbp. I believe the theory is something to do with the ps3's floating point calculations getting rounded to the whole numbers we use in the game, but after so many of these calculations, the rounding is off. That's why we get the 160+ hour bug.

2010-03-17 05:50:00 Author: Sehven Posts: 2188

---

Haha, when I read theck the first time, I thought someone made a spelling mistake and that everyone else was teasing them. Then as I read on, I reealised. I might also mention that someone on the Gamespot forum asked if you could make thin gas quite a while ago, but no one knew the answer...

2010-03-17 07:06:00 Author: The Last Stop Posts: 240

---

Rounding errors are a glitch in lbp. Rounding errors are a fundamental issue with representing a continuous value in a digital computer system, which is inherently discrete, it's not a problem with the LBP code. There is only a certain level of accuracy available to a given floating point system so every value represented is in fact an approximation of what the true value should be - the difference between the actual value and the rounded value is a rounding error. Carrying out calculations on approximate (rounded) values and then rounding the results gives coumpounded rounding errors over time, as you continually re-adjust values to fit into the level of accuaracy available in hardware and may well diverge from the further from the true result. For example imagine I have a system that can only handle 1 decimal place. In this system I wish to calculate the square of 2.54. The correct answer is 6.4516. In my 1dp system, I must round the initial values, to give 2.5*2.5 = 6.25, then the output must be rounded, giving 6.3. My initial values were inaccurate by 0.04. The result is inaccurate by 0.1516. As more and more calcualtions are carried out on the values, the answer becomes less and less accurate (or at least less and less reliable - you may end up getting more accurate by luck) I don't really know how that relates to the converstaion or 160 hour bug, but that is what we mean by rounding error.

2010-03-17 11:39:00 Author: rtm223 Posts: 6497

---

Got the thin gas from Aya. Works perfectly and, as an added bonus, doesn't make the flies buzzing sound that you normally get with gas. Awesome. I mean I was expecting it to work, since anything with zero mass shouldn't be affected by inertia, but you never know if it will work in practise without trying. Hopefully it should also work underwater too. Sorry but what is theck From a previous post... ...each thick layer can be subdivided in two other layers. A checkpoint exists in the back part of the thick layer (referred to as the 'theck' layer), and sackboy exists in the front part of the thick layer (referred to as the 'thack' layer). This allows sackboy to run past a checkpoint, and not get blocked by it. There's a way to create materials with these thicknesses, although it's easier just to copy them from someone else, effectively allowing you to have 10 layers (4 thin, 3 theck, 3 thack), instead of 7 (4 thin, 3 thick). I don't know who in the right mind named them these... Me neither, but they're not all that bad mnemonically. As I said before... I don't mind these names that much. I've always thought of them like... theck: as thick as a check point thack: as thick as a sack person There is only a certain level of accuracy available to a given floating point system so every value represented is in fact an approximation of what the true value should be - the difference between the actual value and the rounded value is a rounding error. Yep. Floating point values are inherently inaccurate, and are generally best avoided in code. Here's an example from the Python interpreter... >>> 1.0 - 0.7 0.30000000000000004 >>> 1.0 - 0.7 - 0.3 5.5511151231257827e-17 So instead of getting back zero, you get 5-ish times ten to the power -17 == 0.00000000000000005 - a very small number indeed, but not zero. This is what I think is the problem with three-way switch dead zones - the angle of the lever never returns to zero, meaning that it always outputs a value once moved from its default position. I don't really know how that relates to the converstaion or 160 hour bug, but that is what we mean by rounding error. That's due to the fact that floating point values are stored as two integer values - the mantissa and the exponent. e.g. 500 == 5 times ten to the power 2 == 5.00000000e2, so it's stored as the two integers 500000000 (mantissa) and 2 (exponent) - well, not quite, but that's the general idea. Now since the size of the mantissa is limited, then as the exponent rises, the difference between two successive expressable values increases. When the exponent is 2, I can express 500000000e2 (500) and 500000001e2 (500.0000001), but when the exponent becomes, say, 20, then I can express 500000000e20 (500000000000000000000) and 500000001e20 (500000000100000000000), but none of the values in between. So what is generally speculated about the 160-hour bug, is that when the exponent of the simulation time exceeds a certain value, it's no longer capable of expressing intervals short enough for 0.1s piston, then 0.2s and so on.

2010-03-17 14:02:00 Author: Aya042 Posts: 2870

---

So what is generally speculated about the 160-hour bug, is that when the exponent of the simulation time exceeds a certain value, it's no longer capable of expressing intervals short enough for 0.1s piston, then 0.2s and so on. Well, that seems vaguely feasible, but a massive, massive assumption to make TBH. It also doesn't explain the specifics of the 160hr bug. There seems to be about as much evidence supporting that concept as there is against it (i.e. none).

2010-03-17 14:41:00 Author: rtm223 Posts: 6497

---

Well, that seems vaguely feasible, but a massive, massive assumption to make TBH. It also doesn't explain the specifics of the 160hr bug. There seems to be about as much evidence supporting that concept as there is against it (i.e. none). Well, it was discussed a couple of times on LBW (who have just changed their forum software version - not too keen on the new version so far). From this thread (http://forums.littlebigworkshop.com/t5/PS3-Workshop/Speed-problem/td-p/191941), my original speculation based on integer math... Simulation engines typically work by storing a list of events which will occur at some time in the future, along with a timestamp representing when that event will occur. Now this timestamp is usually measured in a very small unit of time, such as 1 millisecond. When you start playing a level, or building a level, the counter starts ticking away, and the engine does its job, but when the counter reaches a certain size, it becomes too large to store in a CPU register, and resets back to zero, which would make the engine fail. So what MM might have done is to allow the length of time that each tick lasts for to vary. So when the counter would overflow, they simply double the time per tick, and halve the counter. As a result, the events become less precise as time progresses. They probably figured, "160 hours should be enough - no-one's gonna take that long to play a level", but perhaps they didn't consider that they might take that long to actually build a level, and there's no way to reset the counter. N.B. This is highly speculative, but it would account for the results that people are seeing. FWIW, if they're using 10,000 ticks per second, that would overflow a 32-bit integer in about 120 hours. ...at which point I was directed to a much older thread (http://forums.littlebigworkshop.com/t5/PS3-Workshop/Wobble-bolts-just-stopped-working/td-p/75483), with an official response about this issue from Anton from Media Molecule (http://www.mediamolecule.com/about/whos_who/#Anton)... Thanks for that, the problem reproduces very nicely here. 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! I'll have a go at fixing this so it doesn't happen in future updates. 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? Anyway, I've reset the time counter on that level to make the joints behave again, hopefully this won't mess up anything else! Sorry about that, that is a really daft bug!! Cheers, Anton ...and later... Glad to hear it worked. I've discussed the problem with Dave and he wants to fix it so I've left it with him - we agree it's worth fixing. 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, so its a bit surprising that you could accumulate 160 hours on it? I guess if you forget to pause before leaving it, but then again half your level can wander off if you do that anyway. :/ ...and tameturtle's speculation that it was a floating point problem... It might help if you'd refresh your knowledge of the binary representation of floating point numbers (for example here: IEEE floats on wikipedia (http://en.wikipedia.org/wiki/Ieee_float)). You're absolutely right that it is roundoff noise though. It is caused by the mantissa being multiplied by the base to the power of the exponent. As the latter increases, the resolution of the representation must decrease given the finite resolution of the mantissa. Using more bits for the mantissa is exactly what is needed to reduce this loss of resolution. ...and later... An SPE can operate on 16 8-bit integers, 8 16-bit integers, 4 32-bit integers, or 8 single precision floating-point numbers in a single clock cycle, as well as a memory operation. [...] For double-precision floating point operations, as sometimes used in personal computers and often used in scientific computing, Cell performance drops by an order of magnitude [...]. (Source: Cell Processor on Wikipedia (http://en.wikipedia.org/wiki/Cell_processor#Synergistic_Processing_Elements_.28 SPE.29)) Single-precision floating point is 32 bits wide, double is 64. It's fully understandable MM would go for singles, there's an awful lot of numbers to crush after all. Implementing the time counter in double precision means you have to do an extra conversion every time you feed it to the Cell. Floating point representation is indeed pixellated, the problem is that the pixels get larger as the numbers get higher. The only alternative is fixed-point calculation, which has a fixed grain size. But it is a grand royal pita to work with. For example, fixed-point will wrap to 0 (or the largest negative number if it is a signed format) once the maximum representable number is reached - that is even less desirable than what we have now. ...and enough of the mindless pasting. Point is, we don't know for sure if it's integer or floating point, but either way there's gonna be a limitation on the total number of expressable values, so there's only so high you can count in either system before you either overflow or lose precision.

2010-03-17 15:56:00 Author: Aya042 Posts: 2870

---

So... that confirms that the bug exists and we still know nothing of what causes it Although the info on cell performance on doubles / singles is what I found, prior to your response, that made me alter my post Interesting to see that MM seem to be struggling to fix this though, even after such a long time of being aware and "wanting" to fix it. Of course now I have a link to the fabled level that had it's clock reset, so I can pester spaff about getting myself similar customer service

2010-03-17 16:12:00 Author: rtm223 Posts: 6497

---

So... that confirms that the bug exists and we still know nothing of what causes it Well, the only facts we have are what Anton said about it, which is that "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.", so "the precision of joints starts getting really creaky" after about "160 hours". The assumption that they're using either integer or single-precision floating point values for the timestamps is not unreasonable, given the processor architecture. The alternative to fixed-width values such as these is to use bignums (http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic), but since those aren't supported natively, which is hardly surprising given their variable-width nature, it would be a major performance hit to use those. Interesting to see that MM seem to be struggling to fix this though, even after such a long time of being aware and "wanting" to fix it. Assuming I've guessed their implementation correctly, it would require a major change to the LBP level format, so it's not that surprising that they're somewhat hesitant to roll out a fix. However, in addition to sending your level to MM to have the counter reset, you can also fix the problem yourself, by copying and pasting your entire level into a new moon crater. I've done it before for someone else, and it works just fine.

2010-03-17 16:34:00 Author: Aya042 Posts: 2870

---

And this coming from the guy who critisised me for speculating on the thermo However, in addition to sending your level to MM to have the counter reset, you can also fix the problem yourself, by copying and pasting your entire level into a new moon crater. I've done it before for someone else, and it works just fine. Except for the fact that capturing large objects often makes them unstable, capturing the entire level causes the system to crash and splitting the level, pieceing it back together, rewiring logic back and forth across the entire level and then retesting would take at least an entire day, assuming nothing were to go wrong... except for all of that, it works just fine I think I'll at least ask the question before going to that much effort

2010-03-17 16:46:00 Author: rtm223 Posts: 6497

---

...capturing the entire level causes the system to crash... Your level perhaps. Worked fine when I tried it. You must've done something naughty in your level.

2010-03-17 17:02:00 Author: Aya042 Posts: 2870

---

You can create your own thin gas (https://lbpcentral.lbp-hub.com/index.php?t=17247-Invisible-Walls&p=303535#post303535) but if you want ready made just search my copyable "Premium collection of Glitches" level. I think you can make checkpoint layered gas same way if you want.

2010-03-17 18:40:00 Author: waD_Delma Posts: 282

---

You can create your own thin gas (https://lbpcentral.lbp-hub.com/index.php?t=17247-Invisible-Walls&p=303535#post303535) but if you want ready made just search my copyable "Premium collection of Glitches" level. Actually, that's where I got mine from. As for recreating it, I thought that particular method wasn't possible any more, but I haven't actually tried with gas - I was trying to recreate a plasmafied object with a similar method, but didn't have much success. I might have another go later on.

2010-03-17 18:59:00 Author: Aya042 Posts: 2870

---

I tried it. It doesn't work any more. There's no way to keep a dead creature from disappearing. Or at least nothing I've tried has kept it from disappearing... and I tried a LOT. I really freakin' wanted a plasma led a while back, so I spent a good long while trying. While I suppose there's no actual concrete evidence for floating numbers causing rounding errors, I'm pretty convinced that it's the culprit. Call is speculation or whatever, but I accept it as fact. I don't know who in the right mind named them these, lol). I don't know who named theck, but Kinetik07 named thack. (http://forums.littlebigworkshop.com/t5/PS3-Workshop/New-layer-not-theck/m-p/105122) Well, maybe he got the name from somebody else, but I got the impression that thack was his idea.

2010-03-17 19:42:00 Author: Sehven Posts: 2188

---

Double post. Sorry. Found another use for invisible gas. I've been working on this since last night, but didn't want to say anything until I was sure it would work. For my mechs, I've always made the logic center external (all those moving parts--there's just nowhere to put them on the mech), and that's what I'm doing with my new one too, but I want to emit the weapons separately from the mech, which means either rigging the emitters well enough that the gun's logic center emits out of the way and not intersecting anything else (not impossible, but a pita to set up) or making its logic internal, which just isn't practical.... unless you use thin layer gas for the logic! The mech has a relay which sends the fire signal to the gun, and the gun's logic controls the firing and the overheating timer. I even managed to build an invisible SR latch onto the gun. It all works perfectly except the piston/winch combo that controls the 8 second timer: it gets thrown off by the mech's movement, but that can easily be remedied by swapping the piston+block with a wobble bolt+wheel. So yeah, thought that was worth sharing. Thin layer gas has drastically changed what I can do with the game. If you don't have any, I definitely recommend picking it up from WA_delmaw's level. You can even have multiple moving parts occupying the same space. I'm even giving some thought to making the whole mech's logic internal (probably won't, though: it'd be a nightmare to rebuild and packing everything into that small space would mean I'd have to be ridiculously careful about the placement of mag switches/keys to keep them from triggering the wrong switches).

2010-03-17 23:22:00 Author: Sehven Posts: 2188

---

It won't let you gasify it, the game thinks your trying to gasify a chekpoint so it does the same

2012-07-15 06:34:00 Author: Unknown User

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

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.