BG1, PRELOAD BG2, PRELOAD

Logic Blog

Emitter Blocking Theory

Rating: 7 votes, 5.00 average.
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 Spoiler - geekNotes: On Why this Disparity



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 Spoiler - geekNotes: on Emitter Thermo Hacks



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.


.

Updated 03-30-2010 at 11:07 AM by rtm223

Categories
Logic Blog

Comments

Page 1 of 2 1 2 LastLast
  1. comphermc's Avatar
    Assistant!? Bah.
  2. rtm223's Avatar
    Does "faithful lapdog" work better for you?

    But be honest, you want to do that derivation, don't you?
  3. lbpholic's Avatar
    Well done dude after skimming through this looks very detailed i will read through properly when i have the time but well done.
  4. comphermc's Avatar
    Yeah, sure, I'll do a derivation.

    First, let's look at the t/2. For all intents and purposes, this can be regarded as just time. Remember that with pistons, the time calculation includes a return trip. In honesty, I'd use a capital "T" in that expression to denote the Period, but I won't be faffed with the details. Anywho, let R=t/2, where R is the amount of time in which you would like the platform to fully extend. We set the timing of the piston to be 2R, which you can hopefully see from this expression. (If not consider that t/2 = (2R)/2 = R, as expected)

    At any rate, once we have R, we can consider the expression R/(L-l). This is a simple expression for inverse-velocity of the platform. R is the time and (L-l) is the total distance covered by the platform. We don't normally think about inverse velocity, but it may help to just call it 1/v. Therefore, let us consider that 1/v = R/(L-l).

    If you didn't completely follow that last point, just know that the units will agree. Inverse velocity, 1/v, is time divided by distance. As is R/(L-l).

    So, now when we multiply R/(L-l) by d, we are completing the calculation. Simple unit analysis shows that d*R/(L-l) gives us units in seconds, which agrees with rtm's assessment.

    ---

    Alternatively, just consider that 2(L-l)/t is the velocity. By dividing width of the platform, d, by the velocity of platform, we arrive at the time it takes for the platform to clear the emit zone. Putting this together, we have:

    P = d*t / 2(L-l), or equivalently P = d*R/(L-l)

    ----

    This R value is important, as it is what you should put as the lifetime of the emitted objects (as it's the time if takes for the platform to fully extend).



    (Lapdog works)
    Updated 02-23-2010 at 06:35 PM by comphermc
  5. ladylyn1's Avatar
    Just read it all.

    You're really working out the game's engine! You must have considered working for MM at some time.

    I am definitely using that escalator method in my next level, sounds very cool.

    Thanks again for the idea.
  6. trip090's Avatar
    my mind has been blown. im still picking up the pieces (hard to do with no brain XD). this is really useful. thanks!
  7. Burnvictim42's Avatar
    Oh well done again, some fine sneakery you've pulled off there with emitter blocking. And speaking of sneakery, I actually indavertantly stumbled upon a copy prevention method using this technique. In *cough cough, LBPCTG* I have a rather integral component of logic that uses your demitter, as it needs to be replaced more than once, now this works all fine and dandy, EXCEPT for the fact that it likes to remit every time i mess with pause mode (as the key switch is hooked up in an actively emitting position). If i do not remove this emitted object in create mode, it will become a solid object in play mode (as in the game does not detect that it had come from an emitter), and will block the demitter from functioning properly (as it checks for blocks and is thwarted). So in effect, if i do not remove this blocking piece of logic, the level is rendered useless (and good luck finding it anyone else :P).

    Again, well done, i love the idea of conveyors and waterfalls, this method seems to be far superior.
  8. rtm223's Avatar
    @comphy - Ta, and good point about the R value, although you may want to set your emitted objects to have less life than this, just to ensure that they don't get to the end of the piston (as they will break the object behind them ). Personally I'd set the length to be way more than you need and time the lifetime so that they disappear at the correct point. It prevents the lifetime having any dependencies on anything else and giving yourself a large margin of error means that it can be easilly tweaked using trial and error.

    As a side note, conphy has a system set up where it wasn't possible to tweak the timings so he emits the next object late and uses a faster winch to pull it for the first (insert short period of time) and pulls it into place behind the previous emitted object. Generally for conveyors and the like it's nice and easy if you use sensible lengths on your platforms (not 47.5 units like my waterfall lol)

    @lyn and trip: I'm just getting started with emitters, the dark matter no-blocking thing is something that I thought pretty much everyone knew TBH, I've had that conveyor design in my head for months, but no reason to use it until a couple of weeks ago.

    @Burnvictim: the switches in my copyable level do away with the issue of the one-shots firing. Also There is a chance that the one-shot firing thing can screw you over if someone joins you in multiplayer, so it's best to never have your one-shots left active as much as possible - unless the system will happily recover from and additional firing, which doesn't sound like it is the case for your application.
  9. Incinerator22's Avatar
    Most people think of dark matter emmiter merging as a way to fuse bombs, but the way you use such simple tricks to make revolutionary gameplay mechanics is remarkable. Thank you for sharing this!
  10. Rogar's Avatar
    Bar far? I gather you failed to find that proofreader?

    Glad to see you moving away from winch logic. It's cool in theory, but they never do what I want them to do. And they need a disclaimer that one of the parts should be static; I got my front gate jumping all over the place.
  11. rtm223's Avatar
    Haha, I wrote that paragraph when I was tired and drunk lol. It was full of spelling mistakes, but of course "bar" and "far" are real words.

    Incidentally, "bar far" is a pretty close approximation of how I'd pronounce it, so yeah, that's probably why


    And winch logic is still the bomb! The emitter stuff just allows for different and unique stuff added into the mix.
  12. comphermc's Avatar
    I checked out the R-value thingy. It never broke for me. As soon as I made it .1 seconds longer, it started breaking, but not when it was right on.
  13. thekevinexpress's Avatar
    Ok, so you basically lost me after basic emitting blocking rules, but hey, those were pretty handy!
  14. rtm223's Avatar
    @comphy: yup you're right, and I'm pretty sure it's safe, but I'd stil put a margin of error on the length / lifetime, to be sure. Plus - I set my min distance to 0, but if you look at the platform, I don't move it to 0, because I'm lazy so I need to set my lifetimes to
    @kevin: Try making that emitted sponge swing as it's kind of a good example of the concept. Then have a go at the conveyor - ignore the timing issues to begin with and just get some platforms emitting. It might be the sort of thing that just clicks when you do it, rather than reading it.
  15. VnGamer234's Avatar
    Very nice! The conveyor belt is much better compared with the wheel-based ones, definitely using it. Also the waterfall completely stunned me, amazing.
  16. Hibbsi's Avatar
    I'm glad that you brought this up. I'm a bit late finding this blog entry, but whatever

    Anyway, I also love emitter logic, I was working on (but got distracted from indefinitely) a Maze War 3D first person maze that was 99% emitter-powered. When working on it, I found some helpful things (not sure if I missed these if you said them already):

    -Emitting DM into DM, or DM/other material combined, can save space, as they can be emitted in the same place on the same layer, and therefore can make organizing a bit easier.
    -It looks awesome.
    -It's fast.
  17. Mastadom's Avatar
    My god, my head asploded.


    I can see how this will be extremely useful in future projects. Thanks for taking the time to write this up! I'll be sure to read your other blogs when I make sense of what I just read.
    :P
  18. MrLongJohn's Avatar
    Well darn.
    I thought you might cover the effect on the last emitted object at once (based on the emitters settings) by the next emitted object. In my experience, most of the time the incoming object will cause the past object to disappear, but this inconveniently stops working every now and then. Am I missing something?
    Oh, and by the way, great tutorial!
  19. Gravel's Avatar
    finally got around to 'reading the manual'... wow. Not sure what lbpc (or more singularly... I) would do without deep thinkers like you... Thanks so much again. An example of rtm's brilliant escalator theory can be found in my prologue level to the Great Tree. Not advertising for me... I love it and just want to make sure everyone gets a chance to share your genius.
  20. mutant_red_peas's Avatar
    Nice. I'd definitely try the conveyor (as I'm looking for a decent one) and the waterfall and when I get good at them THEN I MIGHT try the escalator. Hey, that's a cool word. Escalator.


    Lol.
Page 1 of 2 1 2 LastLast