Logic Blog - updated 2011/02/06

[rtm223]

Logic Blog returns!

Although today, I'm not entirely sure if anything in there counts as logic, and also it 100% not what I told you was going to be next, but meh, deal with it. Actually what happened was, the next blog was supposed to be that worked example, but seeing as I kept you all waiting so long it didn't seem right to publish a worked example that had no new techniques in it. So I've gone off on a tangent and today we look at basic
Emitter Blocking Theory, and applications thereof.

[harjot90]

Is this a level too?

[rtm223]

Nope,

I specifically wasn't creating levels alongside this as the intent was to teach people techniques, rather than produce one-off application-specific devices.

As logic blog 2.0 kicks off, this may well change as I think there are a lot of things where the techniques are going to be better demonstrated by example


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

And on that subject, I'm wondering what exactly I should do about logic blog 2.0? It makes sense to begin during the beta I think, but I'm unsure whether it's going to make sense to publish it hidden away in the beta section of the site, or continue it in the blog area, as before, even though some people aren't in the beta.


Anyone not in the beta got any thoughts on this??

[waD_Delma]

I'm not in beta and in my opinion you should post them to blog area. I want to know much as possible about lbp2 to compensate my betalessness.

[TheAffected]

I agree with waD_Delma. I am not in the beta and would very much like to see them.

On a similar note I am curious if you have published anything regarding the score modifier activating objects and conditions in a linked level?

Ciao!

[rtm223]

OK, I'm gonna kick this off again soonish, although bear in mind that even a couple of weeks into the beta I'm not planning on doing a beginner's guide to LBP2 logic. Sure I could cover the little bits and pieces like how to make a perm or a set-reset and crap like that, but that's all common knowledge (or will be for anyone who spends more than a day with the game) and... it's not very interesting. So I'll stick to some topics that are a little less than obvious and continue with the mission plan of pushing back the boundaries of what is possible.

On the other hand, I'll probably start producing bits and pieces to throw out into the community that are somewhat simpler and example applications - something that I avoided previously.


I'm also looking for the following:
1. A catalogue of the new switches in LBP2, basically images all of the sensors and logic devices.
2. Some kind of software for putting together graphs very quickly - I'm currently using excel, but the truth is it's quite faffy to actuall yget all the maths correct to produce a graph, when all I really need is a sketch.

So if anyone can help me with those then that'd be great.


WRT the score sensor, I will do at some point. At the moment upsilandre has his published in the beta with prizes and it's a much easier method to understand than mine.

[rtm223]

Shameless bump, I managed to power through this first instalment of Logic Blog 2, and what a beastie it is - huge wall of text awaits those brave enough here.

It's over 4000 words longs, so Id advise you to take it in stages, section 2 can be skipped initially (though it's probably well worth reading at some point), and realistically each of the sections is a logical stopping point if you need a break. It probably needs an extra proof read, but I don't feel like doing it right now, so I apologise for errors.

As ever, comments, feedback and questions in the thread or in the blog, please

[piggabling]

Thank you, Mr. rtm. I will look at it right now!

EDIT: Way longer than I expected...

[Aya042]

As ever, comments, feedback and questions in the thread or in the blog, please

Nice. Just one minor nitpick...

3.1.Toggles, Randomisers and Select Switches
These have no concept of analogue input and will only respond to the digital aspect of the input signal(s). The outputs do have an analogue component, however this will take a value at 0% or 100%, nothing in between.

Assuming "Select Switches" refers to "Selectors", this is not strictly true. If a "digital signal" is equivalent to, say, a battery at either 0% or >0%, the Selector also responds differently to a signal at <0% in the Cycle input, which causes it to cycle in reverse.

[rtm223]

In this case aya, I consider the "digital" signals to be tri-state (0, 1 or -1), hence me saying that they aren't really digital. In actual fact I have a feeling there is a difference between a true binary signal and a tri-state signal (wrt to the meaning of zero in directional signals), but I'm not 100% atm and I'm certainly not sure which components output bi and which output tri, if that is indeed how it works. Either way they fit very closely into the same processing model, which is very different to the analogue. Certainly close enough that whilst my primary focus for the logic blog is analogue processing, I will be lumping them into the "other" category.

So the the selector and the counter increment inputs do not respond to the analogue components of the signal - they respond to the binary / tri-state / digital signal.

EDIT: Way longer than I expected...

You and me both mate

[Sehven•]

Loving this analog stuff. I think it's not too much of a stretch to think that a mech could be built (there I go with mechs again) that has a variable walk speed (I could do that in lbp1 if it weren't for the fact that pistons can't be given direction+speed controls at the same time) and that uses different walk animations for forward/backwards.

Anyways, the logic blog has always been about technique and methodology, expanding or improving the toolsets available in an application agnostic manner.

That part made me laugh 'cuz the first thing I was gonna' ask was "what would you use this for?" I guess I tend to look at logic that way: without an application, it's hard for me to wrap my head around. I never took calculus in high school so some of that stuff was over my head (I had a bad teacher for trig--all of her students were struggling--so I just lost my taste for complex math) and I'm just now starting college after a 13 year hiatus.... which is not a plan I recommend (it wasn't meant to be a hiatus--I simply didn't think I needed school. I still don't, but you gotta' have that %&*$ paper to get a decent job... now I'm rambling about my life story so I think it's time to shut up).

[rtm223]

I might kick off next blog with some graphical examples of speed values into the timer, try to cover it more visually and dump the references to calculus. I think it's useful for those familiar with calculus to understand that it is integration, but in reality I think all it takes is a few examples to get your head around it.

As for applications, it's a tricky one because with more advanced techniques, the applications are a bit more complex normally, but I wouldn't be doing this if there weren't plenty of applications there, I assure you. I'll give you a simple one that I implemented last night:

I made a little simple jumping vehicle, using movers and direct control and things and it annoyed me that you could be moving at full speed going left, jump and hold right and your air control was so great that you could land further back than where you started. I didn't want to remove air control completely, so I simply added a filtering system than limited the analogue stick signal to the range +/- 50%. Any signal >50 becomes 50.

Arguably, a division by two would have been better and give the player finer control, but that's tricky. Another option would have been to subtract 50% from the magnitude (so 45 > 0, 75 > 25). As it stands the simple limiting gives enough of a feel of reduced control in the air and so the gameplay is improved.


This is where I feel the analogue gives us more than digital in many ways - something like that can adds nuance of detail to the gameplay and empowers you to create mechanisms that feel right.

[Aya042]

In this case aya, I consider the "digital" signals to be tri-state (0, 1 or -1), hence me saying that they aren't really digital.

I knew you'd say that.

Actually I agree to a certain extent, which is why I called it a "minor nitpick" and not a "glaring mistake".

I think it's always going to be a little confusing to those who have a digital electronics background, and perhaps requires new terminology to differentiate it from that. At the very least, I think it might be useful to include your definitions of "digital" and "analogue" w.r.t. the way in which you use them, at the top of the post, clarifying that "digital" signals are effectively ternary (-1, 0, 1) rather than binary (0, 1).

At the same time, I'm not convinced that there is necessarily a "signal duality" (i.e. two separate signals), but rather that that all signals are analogue, and components react to them in different ways. Some components only respect whether it's zero or non-zero, some only respect the magnitude of the signal (ignoring the sign), and some only respect the sign (ignoring the magnitude).

I think the distinction you're making in the blog entry is not which components are "analogue" vs. "digital", but rather which components are most useul in dealing with analogue signals, i.e. those which respect the full range of an analogue signal and/or have the capacity to output something other than -100%, 0, or +100%.

...the first thing I was gonna' ask was "what would you use this for?" I guess I tend to look at logic that way: without an application, it's hard for me to wrap my head around.

I had something of a similar reaction myself, although not that "it's hard for me to wrap my head around", but more that "why would I bother trying to understand this without a useful application?", however simply adding something like this...

I made a little simple jumping vehicle, using movers and direct control and things and it annoyed me that you could be moving at full speed going left, jump and hold right and your air control was so great that you could land further back than where you started. I didn't want to remove air control completely, so I simply added a filtering system than limited the analogue stick signal to the range +/- 50%. Any signal >50 becomes 50.

...into the blog entry suddenly turns it from pure theory into something more practical, and I think you'll find more people might actually take notice of the article by simply putting it into the context of a useful application.

[rtm223]

Of course you knew I'd say that, I'm quite predictable! Much as this is probably quite predictable:

At the same time, I'm not convinced that there is necessarily a "signal duality" (i.e. two separate signals), but rather that that all signals are analogue

I'm not buying that for one second.

It's quite easy to generate any given analogue value and have it interpreted as 0 or a 1, depending on how that value was generated - regardless of the device interpreting the digital signal. The timer is a perfect example - the digital output is 0 until it fills, then 1 until it empties - therefore at every analogue value in between (0.001 to 99.999, or whatever), the binary value can be either 0 or 1, this component alone completely debunks your model (which, incidentally, is the model I originally assumed). So I am very much making a definition between two signal types on the line. The signal combiner is another great example of a single component that debunks the model. You can produce analogue 0-99.999 with a digital 0 or 1, and analogue 0- (-99.999) with 0 or -1.

[Aya042]

I'm not buying that for one second.

Hmm'kay. I clearly haven't done as much experimentation in that regard, so I guess I'll have to take a closer look at these components. I'll put together some sort of 'voltmeter' device which displays the analogue and digital value of a signal (although if you're correct, the definition of "digital" might be too hazy to make this practical) , and see if that helps. I had a quick go at an analogue one yesterday, but if there is some sort of digital disparity, hopefully this will help to reveal it.