PDA

View Full Version : Battery without battery, looping signal



Shadowriver
03-21-2011, 04:31 AM
Well I bet i'm not only one who figured this since people already played with feed backing but interesting trick that i discovered mistakely while doing logic for King of the Hill.

You can close signal in infinite loop creating a battery... without batter, it quite simple

1. Place 2 microchips whatever you want

2. Place one battery on one of them and take wire out of it and place node on 2nd microship

http://if.lbp.me/img/ft/b9f56ed8d95f6fd9aef6275f75de879be4a9a345.jpg

3.Now take output of node and plug it to input of the microchip output and here you go you looped the trap the signal in infinite loop

http://i9.lbp.me/img/ft/3a96795368d9bd58ed29db79378b475d3b4f202e.jpg

4. Now you can remove the node and plug output to input of microship with node and you will have loop in one microchip. you can also loop nodes with signal and take it outside of microchip. there many way to do so. Now you can simply branch off the output of microship and plag tuoo something. Remember to not brake loop and not disable the microhip or else signal will be lost.

http://i7.lbp.me/img/ft/d0739c189bb4c6a5aa86bec72f6e3b7b1e89569e.jpg

You can ofcorse trap specific analog signal value too

Potentially it may not cost thermo or much less then battery, but im not specialist on this one

thor
03-21-2011, 02:04 PM
Very good!

Now this means we can recreate all (digital) LBP logic using microchips alone! Seeing as a microchip acts as a transistor, and then all you need is a 100% battery as a power source, but you don't even need that.

There seems to be no point in it all though :P :P

SSTAGG1
03-21-2011, 02:28 PM
It may be useful if you have several thousand logic components and need to cut back some thermo use perhaps, but since this system is very unstable (if it was deactivated, it would stop working), I don't know if I'll be able to use it.

rtm223
03-21-2011, 03:00 PM
Potentially it may not cost thermo or much less then battery

That would be the only benefit (if any) it would normally give. Other than that it gives a less stable signal, which removes ease of understanding and adds to your wire routing lag and screws up your circuit when trying to move components using box select :eek:


The only time I'd consider doing this is to trap a very specific analogue value that doesn't fit into the 1% granularity of batteries.

Aya042
03-21-2011, 06:53 PM
Well I bet i'm not only one who figured this since people already played with feed backing but interesting trick that i discovered mistakely while doing logic for King of the Hill.

Yeah. Noticed this during the beta - the two microchips are unnecessary. Just create a node, feed the signal in, and then connect the node's output to its own input.

You can then capture the node, and it'll retain that signal when placed from popit. Note that it retains all aspects of the signal, analog, digital, and player info, so you could exploit that to generate player info logic in cases where you don't have access to the signal from another source.

The only thing you can't capture with this method is a neutral-state directional signal - that can only come directly from a 3-way Switch, Controlinator, or Direction Combiner.

rtm223
03-21-2011, 06:56 PM
Isn't player data lost when you reload the level?? Not entirely sure, but I was sure I had gotten that impression from somewhere?

Aya042
03-21-2011, 07:03 PM
Isn't player data lost when you reload the level?? Not entirely sure, but I was sure I had gotten that impression from somewhere?

Never tried it, so I'm not sure. I assumed the signal was stored in a struct akin to...


struct signal_t {
int digital; // -1, 0, or +1
float analog; // any floating point value
int player_num; // 1, 2, 3, or 4
};

...in which case, there wouldn't be a dependency on the player necessarily existing in the level, BICBW.

Shadowriver
03-21-2011, 07:04 PM
Yea i know it's not something big, but interesting think to know.


It may be useful if you have several thousand logic components and need to cut back some thermo use perhaps, but since this system is very unstable (if it was deactivated, it would stop working), I don't know if I'll be able to use it.

Well i captured the loop in microchip and signal stayed, i didn't check if reload of level makes signal lose, but probably no.


Never tried it, so I'm not sure. I assumed the signal was stored in a struct akin to...


struct signal_t {
int digital; // -1, 0, or +1
float analog; // any floating point value
int player_num; // 1, 2, 3, or 4
};

...in which case, there wouldn't be a dependency on the player necessarily existing in the level, BICBW.

I think that signal polarization might be separate value and might be described as direction, but it's not much a diffrence. Player_num aslso should have 0 for none

Aya042
03-21-2011, 07:34 PM
I think that signal polarization might be separate value and might be described as direction, but it's not much a diffrence. Player_num aslso should have 0 for none

Well, who knows for sure? ;)

But the point I was trying to make was that making the player info a simple int, rather than a pointer to some sort of player structure, would make the object much easier to serialize - something that would need to be done upon capturing. Pointers in serialized data = fail.

rtm223
03-21-2011, 07:42 PM
Isn't player data lost when you reload the level?? Not entirely sure, but I was sure I had gotten that impression from somewhere?

Hologram. Hologram loses it's player colour when you reload the level.... Maybe. IDK.



Well i captured the loop in microchip and signal stayed, i didn't check if reload of level makes signal lose, but probably no.
It won't, but you can't have it as a bias signal in a microchip that may be switched on and off. All wires are set to value 0,0,0 (conceptually), when the chip is turned off (this is what was meant by deactivated in this context).

Aya042
03-21-2011, 08:11 PM
Hologram. Hologram loses it's player colour when you reload the level.... Maybe. IDK.

Confirmed. The signal is retained in the node, but you have to detach and reattach to the hologram to get it to come back on.


All wires are set to value 0,0,0 (conceptually), when the chip is turned off (this is what was meant by deactivated in this context).

Yeah. You'd have to ensure your nodes were never disabled.

Looks like you can store player info in a more persistent manner, by storing it in a stateful component like a Toggle Switch - then it's retained even when disabled in a microchip. Best place to store analog values persistently is probably a Timer.

OmegaSlayer
03-21-2011, 08:43 PM
Oh crap...
Aya, rtm and shadowriver in a same thread = an headache, a warranty to not understand anything of something useful and an early night :p

SSTAGG1
03-21-2011, 11:04 PM
I never knew about capturing the player data with the toggle. I can use that. Is this kept even if the level is reloaded?

Tygers
03-22-2011, 07:45 AM
This may not be much, if any, of a thermo changer. Nodes aren't free (I did some experiments measuring the impact of a large number of nodes on thermo, though I forget exactly what the impact was). I haven't measured nodes vs batteries, but my gut feeling is that a looping wire may impact the thermo more than a node on it's own.

Aya042
03-22-2011, 02:47 PM
I never knew about capturing the player data with the toggle. I can use that. Is this kept even if the level is reloaded?

Upon further experimentation, it seems not. The player info is stored in the toggle, and remains if you place a captured copy, but it's lost when the level is reloaded.



I haven't measured nodes vs batteries, but my gut feeling is that a looping wire may impact the thermo more than a node on it's own.

Nodes are probably more expensive than batteries, but, obviously, batteries can't be set to output arbitrary floating point values.

SSTAGG1
03-22-2011, 03:32 PM
Hmm, so if I replace my toggle->Timer with a single node, I could potentially save some thermo. I'd emit these nodes with the stored value (for my damage system projectiles).

Too bad they don't retain player after reload, it'd be nice to make some preset player signals for things like score and cameras.