Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register

Logic gates are having different outputs based on the location of the input block. Grazer, please.

edited March 2019 in Bugs
Yes it's me again, with another problem.

So, im trying to make it so when the rock miner doesn't detect any more small or large rocks, it gives a output. But when I use a NOR gate to output when there's no input, it outputs even when there is still a input.

Related videos:

Might be my mistake, and I could just make a custom NOR gate, but my game is already laggy as it is and I don't want to have to add unnecessary lag.


  • edited March 2019
    @ToastMaster64 I am also having issues with nor gates, it just started today as far as I know. Also I like your youtube profile picture ;)
  • edited March 2019
    can we get a couple other people to test this out?
  • edited March 2019
    When I try it, the NOR gate doesn't activate until there are no rocks.
    It works fine for me
  • edited March 2019
    Welp @JR 01 it doesn't seem to work for me or caleb, have you tried it with your own game?
  • edited March 2019
    Now that you I'm looking back at it, its doing what your describing.
    The weird bug is that it's fixed whenever you just move the gate.
    Like don't change or disconnect anything, but just only drag the behavior

    After moving it, you may be able to just move it back to where it was, its kinda a weird bug and should be fixed after this.
  • edited March 2019
    WOW @JR10 that made even WORSE, now it's outputting when there's still 2 inputs!

  • In my game, the NOR gate is just always outputting whether it has an input or not.
  • The NAND gate and XNOR gate don't work either.
  • edited March 2019
    Try moving the small rock collisions too
    and ig in a way to where the cords aren't bending too much.
    Its not supposed to act like a cinc in a water hose.
    Moving a few things around eventually gets it to work for me.
  • Mine still didn't work after trying to move it around. (sigh)
  • Hey @Caleb Strawberry 3, post a link to your game and I'll see if I can do anything.
  • @JR 01 still doesn't work
  • rq, try moving the small rock collision to the left side of the whole set
  • This is actually not a bug. What you’re seeing here is how the engine actually doesn’t do multiple inputs simultaneously, but prioritizes the upper-left most input first. That’s why your logic is acting a little unexpected.
  • Ah, so that's why it works when I only move behaviors to a specific spot
  • He couldn't get it to work where ever he moved it, so we solved the problem by adding me to move it where it works.
  • Thats stupid, change my mind
  • @ToastMaster64

    This is actually very important because a lot of the behaviors and behavior nodes such as spawning an object could become very unpredictable.

    Here’s an example.... Back then when the spawn behavior first came out, the spawn slot was on top of the other two, so it would spawn the object first before actually updating the coordinates. (And a currently existing example is the emit and it’s angle value being in the wrong place)
  • I also believe this helps the engine run smoothly
  • @CrimsonBlackGames “ What you’re seeing here is how the engine actually doesn’t do multiple inputs simultaneously, but prioritizes the upper-left most input first.”.

    Ok this is blowing my mind. Is this mentioned anywhere? I’ve been developing an “arrangement” system while I build games to keep things organized, but have not taken this bug/function into account. Are there other hidden aspects that work like this? Is it as simple as top left input = 1st processed or is there more to it than that? Does this just apply to behaviors in a single object or between objects too? And what about bundled behavior placement or parent/child behaviors?
  • September 2017, on page 5 of my SB3 update log, I was having trouble with the mobile editions’ Dpads that used messages.

    Grazer responded:
    Hey @jngthree - this took some head scratching, but I think I figured the D-Pad problems out. The issue is that the mailboxes were not sorting correctly. When you move quickly from one button to the next, two messages can get sent to the ship in the same frame: "Stop" and "Go". When the ship checks its mailboxes, if it happened to check them in the right order then they worked, otherwise they didn't. Shooting is the same issue.

    I fixed the mailbox sorting, but you need to make a tweak to the logic: in the "Gun" object, you need to make sure that the "Stop" mailbox is to the left of the "Go" mailbox, so that "Stop" always gets checked first (all triggers fire from left to right and top to bottom). This way when the Gun has both a Stop and Go message at the same time, it will stop and then go again.
  • wow, I never knew that before. I find it surprising that so many people seem to not know about it for how important that could be.
  • ya, it's almost like grazer should tell us this stuff
  • I've added a section in the User Guide explaining the behavior blocks' evaluation order:
  • edited July 2019
    oh did I mention this still happens too?
    Let me just play this out.
    >be me making some code
    >add logic gates to the code
    >this dumb stuff happens
    >Me "oh ill just move every logic gate in the code"
    >My face when I have to disconnect every logic gate because I cant move it without moving EVERYTHING.
    >Picture Related

  • @ToastMaster64 - hold the shift key to move just one block at a time
Sign In or Register to comment.

| make games in your browser
@ 2017, All rights reserved.

Contact us

Get In Touch