Even if one makes the effort to send the stick values via Variables it will end up using more gadgets to encode it at the destination, so I would always opt for Wireless Receivers for that one.
Cool cool... So I do the same thing but skip the centralisation, basically. So in a character say, I'd have a controller sensor. Each chip that handles controls will have input notes labelled what the control does. Then I wire directly into that. If there are nested chips in there, I pass the control through with nodes so the inner chips can get the same stuff. If a control should be "onpress" then I have a sig-manip between the controller and the chip that will use that signal. If there's something in the world like a door that's activated by square for example, then the player is still controlling the character, so I use the character's controller and probably power a trigger zone to let the door know it should open. If I have another separate contolled thing, say a menu, I have a controller sensor in there and it's all set up the same way. So, instead of centralising absolutely everything about the controls, I guess I centralise for each mode of control the player will be in. Like, matching their mindset of what they are doing. Also I just leave the controller sensor out in the open in the main chip like a mad man ;P
@@AecertGaming No issues, just clean microchips now! I once used transmitters and receivers for all of my in/outputs and it worked but was way to thermo heavy. I had no idea there was a frame delay either. This is a far superior method
I came up with the same method in Gamemaker a few years ago. The only problem of naming the variables to be what they do in the game, rather than the actual button names, is that it gets a little confusing when using them for game menus. Its an awesome method though.
I disagree that that is a problem/gets confusing. Name them "menu up" "menu down" "menu select" etc. For menu you up, you can wire in up dpad and up joystick, for example.
Great video! You've helped me through many issues. I do have a quick question. Is there any simple way to do cued inputs? Say you activate an animation with a button, then hit that same button while the animation is still in progress. Is there a way so that when the animation ends, it receives the next input automatically and plays again?
Any downside to hooking the boolean buttons like Bumpers and X△▢○ Into a global trigger zone/tags, and Non boolean buttons like the triggers into wireless transmitters where the 1 frame delay wont mater much b/c its variable anyways? For alpine I did that instead of this because I knew I was ganna have A LOT of variables and didn't use em all up. (ended up only using about 70)
If anything, I feel frame delay is more noticeable on analogue buttons, because it's got more points of reference where you're likely to see the output lag behind your current input. Also, trigger zones and tags do have a frame delay, so I would not recommend it for any direct input. If you're able to, then I'd recommend switching to the variable method for all buttons, and it should improve the feel of Alpine Dream a little bit. Only variables set to 'Persist in Dream' count towards the 128 limit, so there's no downside to using them without a persist.
Apart from the frame delay, no. And I'd say for a lot of games a frame delay won't be noticeable or change the gameplay. Like, the most common situation where you want to transmit a button press like this (whatever method you choose) is to activate something in the world. Oopening a door 1 frame late will make no difference to gameplay and will not be noticeable to the player. Whereas if you're making a very tight PVP 2D fighting game, you want as little delay as possible. So it very much depends on the game you're making, and how important timing is to you. I almost always use a zone-and-tag setup, because I don't make the kinds of games where super tight timing matters.
Keyframe + Switch is still better, as with variables you are using 3 gadgets in total. Transmitting numbers can be done as well with Sliders. Glory to Keyframes.
Id argue variables are better because you can place a variable modifier wherever you want, then scroll through the list to find the control you want, as opposed to being bound to the keyframe. You are right though it is slightly cheaper, but not by much.
@@AecertGaming I usually create a backup microchip with all keyframed switches in it and once I need one I just copy it out of there. On the other hand this might be even the same cost like the variable method. As the backup switches count just like variables as the third gadget. Maybe I'm over complicating it too much and variables might be the better way to do it. It's definitely the more convenient way. I just wish we could get the full list of gadget cost + hidden cost/wires ect. by Mm
Great idea. I've been using Keyframes which TapGiles suggested to me once. Plug control into a Keyframe and Keyframe the power switch of a Not gate. Kinda the same thing i think? Question: do variable gadgets Have invisible wires that count towards the wire count like Keyframes?
Yup that's very similar! The only benefit of using variables is that you can just slap down a variable modifier and it will work. Oh and also it transmits a number, not just on or off. Yup variables also have invisible wires.
@@AecertGaming Oh that is much more convenient than cloning every time. Thx! Also I've noticed that keyframing does send a variable signal so it works with joystick signal as well.
Even if one makes the effort to send the stick values via Variables it will end up using more gadgets to encode it at the destination, so I would always opt for Wireless Receivers for that one.
I use receivers and transmitters for controller sensor inputs as well, the cleaner and more reliable that way
Cool cool...
So I do the same thing but skip the centralisation, basically. So in a character say, I'd have a controller sensor. Each chip that handles controls will have input notes labelled what the control does. Then I wire directly into that.
If there are nested chips in there, I pass the control through with nodes so the inner chips can get the same stuff. If a control should be "onpress" then I have a sig-manip between the controller and the chip that will use that signal.
If there's something in the world like a door that's activated by square for example, then the player is still controlling the character, so I use the character's controller and probably power a trigger zone to let the door know it should open.
If I have another separate contolled thing, say a menu, I have a controller sensor in there and it's all set up the same way.
So, instead of centralising absolutely everything about the controls, I guess I centralise for each mode of control the player will be in. Like, matching their mindset of what they are doing.
Also I just leave the controller sensor out in the open in the main chip like a mad man ;P
About to update my project to this logic technique! Thanks man
Hell yeah! Let me know if you have any questions/issues
@@AecertGaming No issues, just clean microchips now! I once used transmitters and receivers for all of my in/outputs and it worked but was way to thermo heavy. I had no idea there was a frame delay either. This is a far superior method
That is a pretty neat trick. I'll possibly use it someday
Thanks!
I came up with the same method in Gamemaker a few years ago. The only problem of naming the variables to be what they do in the game, rather than the actual button names, is that it gets a little confusing when using them for game menus. Its an awesome method though.
I disagree that that is a problem/gets confusing. Name them "menu up" "menu down" "menu select" etc. For menu you up, you can wire in up dpad and up joystick, for example.
The more I learn about how "Dreams" works, the less I comprehend it
Ikr
I feel vindicated all these years later that a logic genius like Aecert uses the wireless controller method from LBP2.
Great video!
Thank you :)
Great video! You've helped me through many issues. I do have a quick question. Is there any simple way to do cued inputs? Say you activate an animation with a button, then hit that same button while the animation is still in progress. Is there a way so that when the animation ends, it receives the next input automatically and plays again?
I've been using a similar setup instead of nodes I have wireless transmitters.
Any downside to hooking the boolean buttons like Bumpers and X△▢○ Into a global trigger zone/tags, and Non boolean buttons like the triggers into wireless transmitters where the 1 frame delay wont mater much b/c its variable anyways?
For alpine I did that instead of this because I knew I was ganna have A LOT of variables and didn't use em all up. (ended up only using about 70)
The variable limit only applies to saved variables. The normal ones that do not save between scenes have virtually no limit
@@aCavemanNamedJaR Oh thats right, still though, Is there a downside to using tags/trigger zones for bools?
If anything, I feel frame delay is more noticeable on analogue buttons, because it's got more points of reference where you're likely to see the output lag behind your current input. Also, trigger zones and tags do have a frame delay, so I would not recommend it for any direct input.
If you're able to, then I'd recommend switching to the variable method for all buttons, and it should improve the feel of Alpine Dream a little bit. Only variables set to 'Persist in Dream' count towards the 128 limit, so there's no downside to using them without a persist.
Triggerzones also have a 1 Frame Delay
Apart from the frame delay, no. And I'd say for a lot of games a frame delay won't be noticeable or change the gameplay.
Like, the most common situation where you want to transmit a button press like this (whatever method you choose) is to activate something in the world. Oopening a door 1 frame late will make no difference to gameplay and will not be noticeable to the player.
Whereas if you're making a very tight PVP 2D fighting game, you want as little delay as possible. So it very much depends on the game you're making, and how important timing is to you.
I almost always use a zone-and-tag setup, because I don't make the kinds of games where super tight timing matters.
I use wireless signals to send everything instead of variables because i have too many variables in my game
Yeah that's fair. Although starting all the variables with the letter 'C' helps with that
are you still working on the rpg?
Not actively, but i fully plan on coming back to it.
Keyframe + Switch is still better, as with variables you are using 3 gadgets in total. Transmitting numbers can be done as well with Sliders. Glory to Keyframes.
Id argue variables are better because you can place a variable modifier wherever you want, then scroll through the list to find the control you want, as opposed to being bound to the keyframe.
You are right though it is slightly cheaper, but not by much.
@@AecertGaming I usually create a backup microchip with all keyframed switches in it and once I need one I just copy it out of there.
On the other hand this might be even the same cost like the variable method. As the backup switches count just like variables as the third gadget.
Maybe I'm over complicating it too much and variables might be the better way to do it. It's definitely the more convenient way.
I just wish we could get the full list of gadget cost + hidden cost/wires ect. by Mm
@@Denjo92 nahh you aren't overcomplicating it, that method is perfectly valid
Great idea. I've been using Keyframes which TapGiles suggested to me once. Plug control into a Keyframe and Keyframe the power switch of a Not gate. Kinda the same thing i think? Question: do variable gadgets Have invisible wires that count towards the wire count like Keyframes?
Yup that's very similar! The only benefit of using variables is that you can just slap down a variable modifier and it will work. Oh and also it transmits a number, not just on or off. Yup variables also have invisible wires.
@@AecertGaming Oh that is much more convenient than cloning every time. Thx! Also I've noticed that keyframing does send a variable signal so it works with joystick signal as well.
@@AecertGaming or maybe i had to add additional logic for negative values. Can't remember at the moment. Variables seems better anyway..