Logic Blog

Emitter Theory
It's Like a Logic blog, but without the Logic!

- Part 1 -
- Emitter Blocking -

Emitters are actually awesome. Unbelievably so. Despite how much I love winches, I think it's pretty fair to say that I love emitters more. I do still prefer wenches to either, but that's very much beside the point... Emitters have taken a lot of flak for so many reasons; some of them unjustified ("emitters kill the thermo" No! Emitters don't kill the thermo, n00bish creators kill the thermo) and some entirely understandable (why oh why do you have to emit something when I rewind and then also make it ignore the laws of pause?). But they've also been responsible for a large number of the ZOMG AH FONUDED A GLIIITCH!!!111QAqQ1!! excitement that we have seen over the months and there is a reason for this. They are by far the single most complex and most subtle of the tools in this game and if we dig around in these complexities we will find that there are some rather interesting features that we can use to our advantage.

Today we will look at the basics of emitter blocking in a very theoretical manner, and how we might use some of that theory in slightly creative ways to achieve some coolness.

------------------------------------------------------------------------------------------------------

1.0 Emitter Blocking
The basic operation of an emitter is to create an object out of nothingness, but what if there isn't nothingness there to begin with? What if there is already an object in the way? Typically, your emitter blocks and nothing is emitted. But, depending on what you are emitting and what is already there, this may not be the case.


1.1. What Happens When an Emitter is Blocked?
At each time it's supposed to emit, the emitter will do a check to see if it is blocked and if it is blocked, then nothing will emit. I know this seems pretty obvious, but the key point here is to think about the emitters doing a blocking check at each time interval, rather than them emitting at that time.

If the emitter is blocked, it will sit and do absolutely nothing for the time period indicated on the frequency parameter, at which point it will check again. So if an emitter is blocked, the blocking only has any effect at the instant at which it does the check. Blocking does not act like an on / off switch, and it definitely does not mean that the emitter will wait to be unblocked and then instantly emit (as I once erroneously claimed ).


1.2. What this Means in Real Terms
So, take the example of an emitter emitting every 5 seconds. It will make checks at t = 5s, 10s, 15s, 20s etc. If it is blocked between 7.6s and 15.3s, then it will still emit at exactly on 5s and 20s. The blocking has no effect on the timings. This is also true of on/off and speed inputs to the emitter.

If you use a one-shot, it will do the emitter blocking check at the time of each one-shot trigger. If you trigger it and it is blocked, you will need to retrigger the input (make it FALSE and then TRUE again) it to get anything out of it.


1.3. Basic Emitter Blocking Rules
On a very basic level the blocking check is something along the lines of

is there an object (or a sackperson) in the way of the object I'm emitting?

Now that is, in fact, what happens when you tweak the object in the emitter - if any object that already exists overlaps (even a tiny bit) with the object you are trying to emit, it won't let allow you to change the object being emitted. However, once the emitter is set up, the rules are somewhat different. So here are the exceptions to the very simple statement quoted above.

1. Dark matter will not block emitted dark matter: The blocking check still occurs, I'm certain of that, but for some reason MM decided that multiple dark matter objects existing in the same place is all fine and dandy. Editing them after they have been emitted is nigh on impossible, but they will exist. And I absolutely love this feature of the game.
2. Static objects will not block emitted static objects: This is effectively an extension from the first rule. Any object considered static (borrowed term from the PSP version), will follow the same rules dark matter. This means any object glued to dark matter, either directly or indirectly. It does not include objects connected to dark matter on stiff rods - these are still considered moving objects by the game engine and, significantly, by the thermo calculation (but that is another matter).
   
   • Update: Objects glued to the floor are considered static, for the sake of thermo calculation, but not for emitter blocking. Thanks to Aya042 over at the workshop for that bit of info.
3. Gas will not block, or be blocked, by anything: Pretty simple this one. As with in the game normally, gas is free to move through any object and so it can be emitted onto anything, and anything can be emitted into gas.
   
4. A Sackperson will not block bubbles: You can emit points and prize bubbles into the same spot as the player exists on.
   
5. Plasma and Paintballs will not block each other Not as big a deal but as in the main game, paintballs and plasma do not collide.

Note: all of these exceptions hold true whether the existing (blocking) object exists in the level normally, or if they are emitted. If they are emitted, it is irrelevant whether they are emitted from the same emitter, or from different emitters.... it just matters whether the object exists at the time the blocking check is done.


1.4. Achieving Overlay of Objects
As I suggested in the section above, you can emit some objects into the same space as others, but you cannot tweak an emitter to emit an object into another, no matter if it fits one of the categories listed above. Basically the solution is to move either the emitter, or the object elsewhere, tweak the emitter and move it back. Simple.

Spoiler - geekNotes: On Why this Disparity

I’ve been wondering why all this seems to be the case and I’ve come down to the conclusion that emitter blocking is just an extension of the in-game collision detection algorithm. As we know, gas can pass through things, sackpeople can pass through bubbles (sort of) so it seems plausible that this is the way in which emitters do their blocking too as all of the same rules seem to apply.

So what about static objects? They are still taken into account in collision detection so how come they don’t seem to be in the emitters. Well my guess is that the in game collision detection algorithm assumes that it will never have to test for static object colliding with each other, in play mode. This would be a logical assumption to make and has probably just been inherited by the emitter algorithm.

However, the game uses different collision detection when placing objects in create mode. Try copying a piece of gas over something and you will see that it cuts a hole, even though logically it can exist in that place without destroying what is already there. This is the same for when we tweak out emitters.

That’s my assumption anyway, seems like a reasonable theory. I wonder if I dig around for long enough into how the engine works MM will just give in and let me see their source...

The whole emitter blocking concept is also most likely the reason why you see a massive increase in thermo for complex objects that are emitted with short timings. The engine has to potentially handle all of the collision detection for each object in the “max emitted at once” plus it has to do blocking detection every 0.1s (or whatever) for the objects coming out of the emitter.

As an extension of this, I recently found a funky little trick that does not have much application, other than being kinda cool and possibly confusing the crap out of people when they see your logics. I had this idea to have a thin layer piece of dark matter with an emitter on it, that would emit a thin layer piece of dark matter with a magnetic key directly on top of itself, which shouldn't be possible, but the following method works:

Place the emitter on a thick layer piece of material and tweak it so that the emitter emits to the thick layer behind the thick piece as shown below.

fig 1.4.1



fig 1.4.2

Pick up the emitter and place it on your thin layer piece of dark matter. It will now emit to the thin layer behind the emitter, which happens to be the layer that the emitter is stuck to!

fig 1.4.3



fig 1.4.4

As you can see, it looks cool as the magnetic switch magically appears in place of the emitter (which is still there, just hidden). Personally, this feels like a very neat way of incorporating key emitters into my logic systems, and saving on real estate, but as I said, not actually very useful... Although maybe you can find an application for it?


1.5. Static vs Moving Objects
Sooo, stepping away from pointless magnetic key hacks and point bubble emitting, lets look back at that static vs moving objects concept. To clarify, if both the emitted object and the object in the way are static, the emitter will not count as blocked and will be free to emit. If either are moving objects then it will fail to emit (ignoring the other rules for the time being)

This all gets interesting when you consider that what is being emitted, and what might be in the way, is not a single object, but could well be made up of a number of objects, some of which are static and some of which are moving. The way in which the engine deals with this is very simple: each part of the object that is emitted is tested to see if it is blocked and if any part of it is blocked, the entire emission fails.

This is easiest to demonstrate with an example, so here is everyone's favourite purple ninja, with an emitted sponge swing:

fig 1.5.1

The dark matter, sponge and string are all emitted as one piece and the emitter is tweaked for infinite lifetime, and 0.1s timing and max 5 at once. So, when we enter the level, and the first 0.1s passes, the emitter does its check. As there is nothing in the space to begin with, no parts of the emitted object are blocked, so it emits, as shown above.

At t=0.2s, the emitter checks again. There are two parts to emit, so we check each one in turn. The dark matter is emitting onto the existing piece of dark matter, which is not considered blocking. But the sponge is a moving object and so it is blocked by the existing sponge. This stops the entire emitter from firing - the blocking check has failed, so we only have the one swing. But let's see if we can do something about that:

fig 1.5.2

Once we have grabbed the swing we can swing it out to the right. At some point when we are swinging, the emitter will test again and it will no longer be blocked. The dark matter - dark matter is still the same (does not count as blocking), but the first sponge has now moved out of the way, so the emitted sponge is no longer blocked and the emitter is free to emit another one:

fig 1.5.3

Note that there are two pieces of dark matter at the top of the swings, but because they are overlaid it looks like there is only the one. 0.1s later the emitter checks again and finds the sponge is blocked (by the second sponge this time. But, if we swing across to the left we can free up enough space to get a third sponge out!

fig 1.5.4

At this point things start to get a bit silly, and swinging also becomes a chore, so it’s best to give up at that point, but hopefully that example explains the basic principle of static vs moving object emission. And remember, these rules apply even if the objects aren't all emitted from the same emitter as they were here.

------------------------------------------------------------------------------------------------------

2.0 Application of Emitter Blocking: Conveyors and More
So this has probably been my least practical blog to date and that really is saying something. There are actually a whole bunch of applications I'd use emitter blocking theory for and it's likely I'll cover them later as they also involve other aspects of emitter theory. But here is a simple concept for you:


2.1. Reinventing the Conveyor Belt
Instead of the sponge swing that we had above, what if it was a platform on a piston, very much like the one below:

fig 2.1.1

The grab switch is set to directional, inverted and connected to the stiff piston. When we unpause the piston will extend outwards at a fixed velocity. But what if we place the object in an emitter? Well, as with the sponge the polystyrene will block the next emission (emitting? IDK ) until it is out of the way, at which point the next platform will be unblocked and able to emit. The result of this is the following:

fig 2.1.1

A row of platforms, all moving at a constant velocity. Essentially, we have reinvented the conveyor belt mechanic for LBP. Typically when I've seen conveyor belts they are platforms driven along by wheels either underneath them, or on the platforms themselves. As such they are a tad unstable as there is a lot more going on in the physics of them - they have a fair amount of freedom of movement. Not so here: it's solid as a rock and if you check the close up, perfectly aligned:

fig 2.1.1

This image should help to explain a little more what's going on:

fig 2.1.1

It shows what appears to be a single piece of dark matter with a single grab switch, but many wires coming out of the grab. Obviously this is not the case, as we can see if we start moving the grabs switches around (below). Similarly there are many pieces of dark matter and pistons there as well, just like in the sponge swing example.

fig 2.1.1

2.2. Getting the Conveyor to Work
Sadly, I've been a little bit misleading on how simple this is to set up (as Morgana can wholeheartedly attest to!). That perfect alignment doesn't just happen by accident, but luckily it is easier than just trial and error if we do some basic Maths.

Essentially, we need to build the system in such a way that the emitter fires at exactly the point at which the platform has moved its full length. This means that the time taken for the platform to move that distance must be divisible by 0.1s, as that is the granularity on our emitter frequency. So, defining our problem as a set of variables:

• Piston Min Length (l)
• Piston Max Length (L)
• Piston Timing (t)
• Platform Length (d) - d because it's the distance we want our platform to move.
• Emitter Frequency (p) - p because it's technically a period, not a frequency - it's measured in seconds MM

Remember when measuring your platform length that small grid squares are 2.5 units. And you really do want to be using the grid for this, trust me. So, the formula you want is

Code:

         d t
p = -------------
      2 (L - l)

For which my glamorous assistant comphermc will provide a full derivation and explanation in the comments section below, because he likes that sort of thing

But basically, plug the values into that equation and that will give you the emitter time (period) that you need to get the correct alignment. If the value for p comes out at something that is not a valid emitter frequency (0.1s, 0.2s etc), then you are going to have to changes some values.

Depending on what exactly you are trying to achieve (specific speed, specific sized objects, etc.), there are various ways to solve the problem, and rearranging that equation might be of use, but I’m assuming basic algebra skills here. Also, setting minimum length to 0 on the piston will help simplify it as well.


2.3. From Conveyor to Escalator
The very close relative of the conveyor belt is the escalator, but in LBP it is far more elusive and traditionally far trickier to construct (I've only seen one or two that weren't really naff TBH) and therefore it's way cooler. But, expanding on the method above it can be made really quite easily. If you simply hang some vertical pistons from the conveyor system then you can make a really nifty escalator, looking like the one below:

fig 2.3.1

If I show you that in create mode, you can see the vertical pistons (horizontal conveyor is hidden in the roof) and a magnetic switch to do the direction on the vertical piston. This means that the platforms come out horizontally for a short time and then begin to rise, just like a proper escalator.

fig 2.3.2

The timing on the vertical piston is such that it reaches the top of its vertical movement just prior to the end of the run, so it levels out again. It's now too late for me to do that Maths for that, you can work it out for yourselves (or just do it trial and error like I did in the example here ). But again: very stable, perfect alignment and pretty low thermo. (two pistons, 2 moving parts and 2 switches on each object).

fig 2.3.3

Spoiler - geekNotes: on Emitter Thermo Hacks

OK, so actually, this conveyor isn’t [b]actually that thermofficient once you count up all the parts inside it. However, it is a perfect example of how we can use nested emitters to save on thermo. If you aren’t really familiar with the technique then check out the Thermo Guide (Tricking the Emitter 2).

The idea is that you can emit and object to emit another object. By setting both to max at once = 1, the thermo only calculates for one instance. However, if the lifetime of the final object is greater than the frequency of the first emitted object, you can produce as many as you want. Just remember to get you big smashy rocks out else it will all break

The same is true of the conveyor and the waterfall below, but considering the sheer number of units (around 25+) that you need to make a decent escalator, it’s the escalator that will really benefit from this method.

2.4. From Conveyor To .... Waterfall?
As the conveyor is based upon a system of stiff pistons, it is quite easy to create a diagonal or even vertical conveyor using this method and the step from vertical conveyor to waterfall seems like a pretty obvious step to me.

Exactly the same concept as the conveyor, but vertical, and a more complex shape. The major plus of this waterfall mechanic are that it flows continually, rather than the flipper-piston waterfall crap* we used to see a lot. Personally I think it looks easily as good as any other waterfall I've seen in LBP, but I am obviously biased. I did take a couple of screens but they don't do it justice, so I've publish a tech demo of it, under the imaginative title of "Waterfall Tech Demo", so you can bask in its glory. Also, more details on waterfall creation can be found in the object showcase thread soon.

Props go to:

comphermc: Stickering Expertise
Javi haguse: Providing Foliage
Syroc: Supplying a box of Sponges

*Sorry to anyone who has used that and I'm not just being disrespectful, I just always thought that flipper piston with a sheet of glass looked bad. As in, no waterfall would have looked better. And it’s even worse with network lag.


.