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 2 of 2 FirstFirst 1 2
  1. mutant_red_peas's Avatar
    Actually, to be honest...

    I don't grasp the whole emitter theory well AT ALL : (
    It just goes in 1 eye and out the other (because I read it, no-one was there reading it out : )
    That would be pretty awesome though. XD
    Updated 09-26-2010 at 08:23 AM by mutant_red_peas
  2. mutant_red_peas's Avatar
    Ok... I've looked again, but I can't get the platforms to align perfectly.

    So here's what I did:
    1) Trial and error. Random stuff to see if it worked.
    2) The calculation. Tried rtm's algebraic stuff but didn't make much sense of it. Not that I'm dumb, it's just I haven't done that stuff yet.
    3) Made even less sense of compphermc's...... derivation. So.......
    4) I went back to trial and error. Still didn't work. (don't know why... :P)

    If anyone has any tips, maybe 'conveyor belt like rtm's for dummies', please tell me
  3. rtm223's Avatar
    If you check the waterfall tutorial, it has an example with figures in it. If you ditch all of the waterfall specifics and just use rectangles, you should be able to get it matching up.

    The algebra isn't difficult, but there is an assumption here that you are already familiar with algebraic techniques, so I'm not surprised its causing issues if you've not covered that before.


    I'm not around for the next week, but poke me next month for a worked example of a very simple conveyor, if you're still struggling and no-one else has done it
  4. mutant_red_peas's Avatar
    I'd like to take this little opportunity to say: CALLING ALL MARVEL KIT BUYERS: If you have played Freeway Frenzy, I think this is how it works, but the platforms the emitter emits are VERY VERY long. I haven't checked this theory, but it hit me when I coincidentally read this tutorial when I was playing the level, so CALLING ALL BUDDING CREATORS: Make a road level using that theory. Also the tunnel part might only come on properly when you get somewhere so it emits the hanging road signs that make a pan-smash noise.

    I love that noise!
  5. mutant_red_peas's Avatar
    Ok, I kinda got the conveyor to work. It's 'kinda' 'cos I did all the stuff EXCEPT the

    p=

    I decided not to because they weren't emitting quick enough so I set the em to 0.1 and they locked together.

    VICTORY FOR THE DUMB KID!!! XD

    Failure 278 - 1 Me
  6. rtm223's Avatar
    Heh, nice job.

    Looks like you got all the rest of the calculations correct then, as your platforms must be moving at some multiple of 0.1s for a 0.1s emitter to work. There isn't really any benefit in getting the correct value in that emitter timing setting andyways, unless you have a stupidly complex object, in which case the system will save some thermo by having a slower rate of emitting.

  7. Kitkasumass's Avatar
    I don't know if anyone will see this. But I made all the things here in your tutorial. And they all work great. But I was messing around with them in the LBP2 beta and there were some issues. It seems to me that the emitters are a little bit different in LBP2 as of right now. If I just pulled out the waterfall emitter and placed it everything worked fine just like it did in LBP1. But if I saved the piece of waterfall(the exact same one I was already using) and stuck it in the emitter, it didn't work. So I started messing around and I just made some square pieces of material. Still can't get it to line up. I can get it to be within about 1 small grid from each other but that's if it's moving really slowly. The faster I speed it up the more space between objects until it is just emitting every other piece again.
  8. mutant_red_peas's Avatar
    I still can't get a good conveyor......

    The one in my roast was a fluke!


    But I have cleverly (?) devised

    A SOLUTION!


    Now, instead calculating the emitter frequency using numbers we already have, why don't we make up one?


    For example, the emitter frequency is fully dependable on the other numbers as they calculate its value. But say we make up it's value, we can then try to calculate the other numbers from it.


    Now since I'm doing this JUST AFTER I turned off my PS3 for the night, this hit me (why does it always happen then? Can't it happen an hour earlier?!). I tried it once or twice using things I can remember.

    The piston max. lengths and minimum lengths were 350.0 and 5.0 respectively.


    Now using the theory I have just written, can someone work out the other factors?


    I use my calculator and always seem to end up with a long, tedious answer.

    Post a message on my visitor messages page if you have an answer
  9. Kitkasumass's Avatar
    The conveyor is easy. Make your platform 10 small grid units wide. Set the piston to 500 max,0 min and a time of 40 or 80 and the emitter frequency to 0.1 or 0.2. I'm pretty sure that's what I used. But it's still a bummer that you can't do this in the BETA. I wanted to make a waterfall out of that water type glass material.
  10. L1N3R1D3R's Avatar
    I know this is a very late post, but this can be used to make a vertical sponge grab chain in LBP1!
Page 2 of 2 FirstFirst 1 2