Archive: 57 posts

---

HOW TO CONVERT A TIMER INTO A HEALTH BAR USABLE TIMER-BASED HEALTH BAR AVAILABLE AS A PRIZE AT: LBP.me - Sir_Linque - COLLECTABLE Advanced health bar (http://lbp.me/v/yqdcez) http://i5.lbp.me/img/bl/595058ef4c9e5864561e692a9d3bb23c60fa2037.png http://linque.pp.fi/LBP/LBP2/healthbar.jpg Using a timer as a health bar for your creations gives two massive advantages compared to a counter: 1) You can adjust damage +- 0,3 - 33% within ONE PULSE 2) You can both HEAL and DAMAGE any unit by these amounts You need: - 1 x TIMER - N x PULSERS - N x COUNTERS - N x AND gates - 1 x DIR COMBINER - 2 x OR gates - That's it! What you want to do is pair each PULSER with a different COUNTER, using one AND gate each. Each pair works as a single healing or damaging amount. If you want for example to have the possibility to heal or damage by increments of 10% or 20%, you need a total of 4 x PULSER & COUNTER pairs. The timer that does the calculating has to be set INVERTED and have a MAX DURATION OF 0.1s and the adjustment function to SPEED SCALE. Connect the DIR COMBINER output into the TIMER input. Connect one OR gate output into the MINUS input of the dir combiner. THE MINUS INPUT WILL MEAN HEALING! Connect the other OR gate output into the PLUS input of the directional combiner. This will be the damage input route. After this setup is done, you need to wire the AND gate outputs into the OR gate inputs. Now you're done with the wiring! All that is left is assigning the damage amounts. This is done with the counters - the more filled the counter is, the more damage / healing is done. Maximum healing/damage per one pulse is 1/3 which is given if you have a completely filled counter. If you want to deal more damage than that, you're going to have to trigger at least two pulses. So, that's all there is to it! Finally, here are some counter values turned into damage percentages for your convenience: 1% == 3/100 5% == 3/20 10% == 3/10 25% == 3/4 33.34% == 1/1 NOTE: With a 0.1s timer the MAX hitpoints is 300hp. If you want more than 300hp at your disposal, you can increase the timer duration. A 0.2s timer is max 600hp, 1s timer is 3000hp and so on. At least theoretically, that is. I haven't tested if these larger amounts work, I only tested the 0.1 timer with 1% increments.

2011-01-20 23:48:00 Author: Linque Posts: 607

---

can this also be used as a currency for rts levels

2011-01-21 04:18:00 Author: Unknown User

---

Yes, you can use it as a currency. You can't get a number out of the system though, so you can't display how many units of a resource the player has - you'll have to use a bar display.

2011-01-21 09:02:00 Author: Linque Posts: 607

---

In the above, if you get hit by 20pts damage and 40pts damage at the same time, then you will lose 40pts damage. The OR gate has the flaw that it will always mask out the weaker signal(s) if multiple hits are taken at once. If you swap out the OR gates for adder circuits then you can have a more robust system that will not allow signals to mask each other out. This is particularly useful if you want damage / healing over time effects, rather than instantaneous effects, but also useful anyway (in the event of simultaneous hits). Another important aspect is that the inverted timer allows for instant replenishment of health by signaling reset of the timer. I assume this is why you've inverted the timer?

2011-01-21 10:02:00 Author: rtm223 Posts: 6497

---

Correct, my OP is the simplest possible way to have a damage/heal timer health bar. Including adders makes the system a lot more complicated for the layman, but it's true that it would be a lot more robust that way. For my purposes the current system is enough, because I will have a brief invulnerability period between taking hits. Resetting to cause full heal is useful, but the original reason I inverted the timer is that an inverted timer switches its state when its bar is completely empty, so it can be used as a visible health meter. When the bar is empty you can trigger a death sequence simply by running the output of the timer through a NOT gate. A normal timer switches its state when the timer is filled up, which is not that useful for a health bar.

2011-01-21 13:25:00 Author: Linque Posts: 607

---

An inverted timer switches its state when its bar is completely empty ... A normal timer switches its state when the timer is filled up Both switch state at both full and empty. In fact, the inversion of output does exactly that - inverts the value of the output. The Normal timer would still switch to TRUE when completely TRUE @ 0% and switch to TRUE @100%, as does the inverted timer. The only functional difference between them is the reset, and the fact that you introduce a double negative in the sense of using the positive input of the combiner to take away health and the negative input to give health. Unless there has been some drastic change in the way timers work since the beta that I've somehow missed...

2011-01-21 14:16:00 Author: rtm223 Posts: 6497

---

/Thread needs picture of logic. What's a pulser?

2011-01-21 14:19:00 Author: Syroc Posts: 3193

---

What's a pulser? The image doesn't actually relate to this tutorial, it just has a pulse generator in the bottom left corner. Obtaining this single clock tick frame can be achieved by using a "pulse generator". The pulse generator literally generates a pulse that is the length of a system clock tick. The best way to achieve this is a counter, set to target count of 1 with the output wired into it's own reset. When you increment the counter, it's value increases by 1. 1 is the maximum value, so this actives the output. The output is wired to the reset and so the device resets itself. Conveniently, the system inserts a delay of exactly one clock tick on feedback loops, meaning that the time between when the counter activates and when it de-activates, is exactly 1 system clock tick, so the output is held high for exactly that long, hence our Pulse Generator. So, we can activate our sampling window for exactly 0.033s, using our pulse generator, as shown: http://i600.photobucket.com/albums/tt82/rtm223/APhoto_4-3.jpg (http://i600.photobucket.com/albums/tt82/rtm223/APhoto_4-3.jpg) fig 2.3.1. high Speed Sampler tl:dr: A counter set to maximum count=1, loop the output back to the reset, when triggered, it will generate a pulse on the output.

2011-01-21 14:29:00 Author: rtm223 Posts: 6497

---

Great tutorial, but im a bit lost as to what the inputs of the AND gates are?

2011-01-23 21:02:00 Author: Unknown User

---

Sorry but, whats a Pulser?

2011-01-23 21:30:00 Author: Twilightoutcast Posts: 80

---

Very nice. I couldn't make heads or tales of it at first. I followed along, and it was pretty easy to get working following the directions, but I'm still not quite sure how it works. It will be pretty useful for what I am doing Could you go into a little more detail about the speed/scale? I've watched the tutorial and it isn't mentioned in the timers section. EDIT-i think i have it now. If I am correct, the formula would then be Percentage Off = ((Counter Position/Counter Total) * (.1/3))/Timer size

2011-01-24 07:31:00 Author: tdarb Posts: 689

---

Great tutorial, but im a bit lost as to what the inputs of the AND gates are? Input= something you do to activate the output (example: attaching a button to a lightbulb, the button is the input, and the result of the light lighting up would be the output) and an AND gate: an AND gate requires two inputs to both be activated to give an output (for example, a pair of 2 way switches, both would need to be activated to give the output) where as an OR gate requires either one of the inputs to give an output. And don't worry, i'm still a little lost in terms of understanding the logic tools in LBP2 as well (:

2011-01-24 08:22:00 Author: Matimoo Posts: 1027

---

It wasn't very clear, but the counter/pulser (counter set to one that resets itself), input into the AND gates.

2011-01-24 08:27:00 Author: tdarb Posts: 689

---

your right, could anyone who gets this please post up a photo of the logic for this? EDIT: sorted now, ill add a screenshot once i figure out how to take one in create mode... Edit: http://i54.tinypic.com/21kwjfl.jpg Is this right?

2011-01-24 18:02:00 Author: Unknown User

---

Yes, that looks like it's correct, but you of course need to connect something to the pulser inputs to actually take damage or heal. Here's an image of my system with the damaging & healing levels 1%, 5%, 10%, 25% and 33%: http://linque.pp.fi/LBP/LBP2/healthbar.jpg The top left part is the damage part. The tags are all attached to pulsers. The timer that works as the health bar is outside the microchip. Don't pay attention to the NOT gate or the tag in the microchip.

2011-01-25 01:23:00 Author: Linque Posts: 607

---

I think you have it o0shda0o5, except your counters don't need to loop back into the resets. and, as was said, you need an input to activate your pulser in impact.

2011-01-25 02:08:00 Author: tdarb Posts: 689

---

Just what I was looking for. Although is there a reason to use a counter instead of a battery for setting health amounts? A battery is pretty striaghtforward, giving 1/3rd the amount of health as percentage of the battery - certainly simpler than your mix of counter ratios!

2011-01-25 15:10:00 Author: Shifty Geezer Posts: 131

---

I like to use counters more than batteries. I like the fact that I can visually see how big of a signal it sends. But I don't think there is anything preventing from using batteries instead, since both have the same operating range (0-100) for this application.

2011-01-25 17:53:00 Author: Linque Posts: 607

---

Think you could put this into a level? It would be a huge help for all of us "logic impaired" people

2011-01-29 05:16:00 Author: dragonember Posts: 607

---

I'll consider making a level with a health chip as a collectable, sure.

2011-02-02 16:05:00 Author: Linque Posts: 607

---

Make it shareable!

2011-02-04 17:38:00 Author: EleoMod Posts: 122

---

I'm surprised you didn't end the OP with "Heres one I made earlier" ...Still, nice tutorial. I'm sure it'll help alot of people

2011-02-04 18:12:00 Author: Nurolight Posts: 918

---

this is a fantastic system. I'm going to use this in a top down shooter i'm making. would there be any way to trigger input on different holo's depending on different key states of health? (70%, 50% 25% 10%) I want the ship to glow different colours depending on its state of health, so as it looses or gains health, at certain thresh-holds a different holo is triggered. I know this can be triggered via a selector set to trigger +/- input, I'm having trouble theorising how i could synk that up with the state of the health bar. I'm pretty certain the analogue output of the timer will be a good place to get the accurate read from but i don't know what process can trigger a +/- input to the selector at key DC output states of the timer, that problem with 1 part being digital and the other being analogue :/ help would be great

2011-02-05 06:51:00 Author: Epicurean Dreamer Posts: 224

---

Maximum healing/damage per one pulse is 1/3 which is given if you have a completely filled counter. If you want to deal more damage than that, you're going to have to trigger at least two pulses. How would I go about doing this? I got a sollution but that needs one OR and one pulser for each Pulse. Main Input in the first pulser, output of the first pulser into the first OR, output of that OR into a second pulser, output of that second pulser into the first OR (and into a second or if you want to continue with more pulsers). Results in a stair like structure. I tried something with a counter and a pulser too, but that did not work. Also, I dont want to use a 0.1 Timer in it, since this delay is already to long for my purposes. Regards 1st of The5

2011-02-07 20:25:00 Author: The5 Posts: 51

---

Amazing tutorial, thank you very much for it, though I got a bit confused, maybe because I am don't know much of LBP2 logic yet, thus feeling a bit overwhelmed ha ha. Would it too much to ask you to place more pictures, like a step-by-step method explaining why use this and that, in the first thread, or maybe even a YouTube video if you think it would be easier, or possible, about this tutorial? It would help a lot . I noticed you showed us how to make percentual damage / healing values. Is it also possible to make fixed damage / healing values? For instance an enemy attack which always cause a fixed damage of 500, no matter your current maximum HP, using this timer system? Would it be hard to adapt the health bars to "super" meters (Think on fighting games with the usual "3 or more levels" special bar where you input sequences to perform super special attacks. Or think on Final Fantasy's overdrive and limit break system)?

2011-02-14 06:52:00 Author: AlvaroShiokawa Posts: 126

---

this is a fantastic system. I'm going to use this in a top down shooter i'm making. would there be any way to trigger input on different holo's depending on different key states of health? (70%, 50% 25% 10%) I want the ship to glow different colours depending on its state of health, so as it looses or gains health, at certain thresh-holds a different holo is triggered. I know this can be triggered via a selector set to trigger +/- input, I'm having trouble theorising how i could synk that up with the state of the health bar. I'm pretty certain the analogue output of the timer will be a good place to get the accurate read from but i don't know what process can trigger a +/- input to the selector at key DC output states of the timer, that problem with 1 part being digital and the other being analogue :/ help would be great If you are using a timer as a health bar, you can probably output that to a sequencer with your logic on it to control the ship color. You can set the sequencer to positional. I've seen it done with the analog stick as an input, it should work with the timer as well.

2011-02-14 13:32:00 Author: tdarb Posts: 689

---

If you are using a timer as a health bar, you can probably output that to a sequencer with your logic on it to control the ship color. You can set the sequencer to positional. I've seen it done with the analog stick as an input, it should work with the timer as well. Thats actually exactly how it should be done!!! That makes pefect sense and i can completely see how that would work logic wise. How on earth ididn't think of that is random. Thanks so much!!

2011-02-15 01:48:00 Author: Epicurean Dreamer Posts: 224

---

what are pulsars!?!!?!?!?

2011-02-18 22:05:00 Author: Unknown User

---

/Thread needs picture of logic. What's a pulser? Sorry but, whats a Pulser? what are pulsars!?!!?!?!? Seriously guys. This was answered IN THIS THREAD after the first time it was asked. Is this really necessary? A counter set to maximum count=1, loop the output back to the reset, when triggered, it will generate a pulse on the output.

2011-02-18 23:48:00 Author: jdteather314 Posts: 74

---

Could the Counters not be replaced with Timers? As these can be tuned much more Precisely. Instead of 1/100 (0.033%) as the Minimum, giving 300Hp on the 0.1s Health bar, Timers could be tuned to 0.1/100 (0.0033%) meaning the 0.1s Health bar would give 3000Hp, unless the Speed Scale setting isn't that precise. If it worked the 0.1s Health bar could have 1000's of Hp (I got bored at 50,000s), this would make the 0.1s Health bar very versatile. I tested with a 0.2s Health bar and the Maximum damage from a single Pulse (with a 1/1 Counter) becomes 16.67%, so as Health Increases the Maximum damage from a Single Pulse Decreases. Using Timers and the 0.1s Health bar could get around this if I am correct? This would be an alternative to using Multiple Pulses to deal large damage at High Health (The Max damage on a 1s health bar would be 3.3% and would take 10 pulses to deal 33.3% damage). It would remove this problem and also be a lot simpler than having multiple pulses. Anyway great system, simple and effective EDIT: Did some basic testing and it works apart from an irritating glitch with the Timer. At Higher target times it seems to give a lower percentage (at 0.1/10.0 it works exactly the same as a 1/100 counter, but at 1.0/100.0 it takes more hits to activate it). To test I made 2 Damaging Units and plugged them both into different Health bars, I then plugged a single repeating pulser into the 2 of them, and a switch into that. I put the 2 health bars next to each other and then triggered the switch and watched them decrease, seeing which one finished first. As I mentioned at low 'Target Time' it worked perfectly, but as this increased the results became skewed. I also tested a 0.5s/100.0s with a 0.1s health bar compared with a 1/100 with 0.2s health bar, but again the timer one gave strange results. The 'Speed Scale setting must not be precise enough for the tiny percentages the timers can produce, and therefore rounds them down

2011-02-19 00:53:00 Author: Unknown User

---

In the above In the previous post, a timer should have 300 health at 0.1 seconds, and take 300 x 1% pulses to reach its max. I didn't actually count exactly 300, but from watching my NOT pulser increment it, it seemed very close. Thus, 1% power = 1/300 of a timer set to 0.1 seconds. Every additional 0.1 second would increase the max health by 300. So a 0.2 timer = 600 health (or should). Also, since the timer is set to speed scale, the duration of the pulse directly impacts how far the timer is incremented. A Timer pulser works at ~10Hz, and a NOT pulser works at ~15Hz (IIRC). This means that each pulse for a timer would be slightly longer than a pulse using a NOT gate, thus incrementing it differently (unless I'm mistaken, which is not all that unlikely). From your test, you used counters and timers. Since the timers likely have some error due to the speed scale input, I can understand why there was some variation.

2011-02-23 05:49:00 Author: SSTAGG1 Posts: 1136

---

300 seems to be pretty correct, I made a Digital Value Display (for a level I'm working on) to link with this and 3/100 on a counter seems seems to be almost exactly 1%. I had a sequencer with 10 batteries on it and it took 10 hits to decrease to the next battery (ie down to the next lot of 10's) and therefore 100 hits to totally deplete it (using 3/100 counters). The Digital Display only works for: 99 Max Health, 33 Maximum Damage and 1 Minimum Damage but works for all Damages in between, and can go Backwards and Forwards. It could be modified for different Values but would require a lot of work. But works perfectly how it is. It a just lets you see an exact health amount so it could be useful for someone. If anybody wants it I can publish it in a level, or put up a tute (It wasn't the simplest thing to do).

2011-02-23 07:02:00 Author: Unknown User

---

I will put up a picture of my latest version of the health bar and put it up as a shareable object realyl soon. I'll inform in this thread once it's up. this is a fantastic system. I'm going to use this in a top down shooter i'm making. would there be any way to trigger input on different holo's depending on different key states of health? (70%, 50% 25% 10%) I want the ship to glow different colours depending on its state of health, so as it looses or gains health, at certain thresh-holds a different holo is triggered. I know this can be triggered via a selector set to trigger +/- input, I'm having trouble theorising how i could synk that up with the state of the health bar. I'm pretty certain the analogue output of the timer will be a good place to get the accurate read from but i don't know what process can trigger a +/- input to the selector at key DC output states of the timer, that problem with 1 part being digital and the other being analogue :/ help would be great EDIT: I noticed someone else answered this question already. Well I'll leave it here so it'll be easier to find if someone has the same issue. This can be done easily with the help of a sequencer. Wire the timer output into a sequencer that has it's mode set to "positional". Now just put in tags to whichever health areas you want to have a specific effect on.

2011-02-23 08:43:00 Author: Linque Posts: 607

---

Edit: I no longer need the help, but thanks to anyone who may have thought about answering my question.

2011-02-23 15:49:00 Author: Firemac Posts: 13

---

Could the Counters not be replaced with Timers?Yes and no. A counter has a fixed increment decrement, unless you want to pulse which has issues. Importantly though a counter returns ON if it has any value greater than zero, whereas a timer switches to OFF when it is empty and then remains off even when partially filled until it is filled ot the top, where its state toggles again. Thus for my tanks game, I use a timer for health where I destroy the tank when it hits zero, and I use counters for boost and weapons to have a recharge-over-time mechanic and conditional firing/bootsing only if there's some energy in the meter.

2011-02-24 08:57:00 Author: Shifty Geezer Posts: 131

---

has anyone tried using an adder circuit with this yet? I've just put one together and i'm getting weird output values when certain inputs are combined. Specifically 10 and 25, when triggered at the same time they output a value of 31 instead of 35. I really can't understand why. It might have something to do with the order in which values are subtracted from eachother in the adder circuit, but i'm just not good enough with numbers to try work out whats going on here. I'm pretty certain the circuit is wired up correctly: http://i0.lbp.me/img/ft/1503ba5e0544cf0c2cab9c06251680b460f80ad6.jpg Theres the 10 and 25 inputs giving a 31 output... i really don't get it. All of the other inputs combined in pretty much any combination gives an accurate output except this one. Might it be a glitch?

2011-02-28 17:01:00 Author: Epicurean Dreamer Posts: 224

---

If you pulse them separately do you get the proper result? here's my best guess I'm estimating, but it looks like you have roughly 30% and 75% in your timers. 100-30=70 70-75=-5 that gets converted to an absolute value next add. when you NOT it out at the end (100-5), that becomes 95....Since your pulse is .033 second, or 1/30 of 1, it is then 1/3 of .1 95 * (1/3)= 31.66666 Given the imprecise nature of timers, and my estimation skills, this seems about right.

2011-03-01 09:13:00 Author: tdarb Posts: 689

---

tdarb is correct. Or to just put it simply, you can't reach values over 33, so after you reach 33 the game starts counting backwards, so 35 is actually 33-2 = 31. You need the system to fire two pulses if you want to have values between 34 and 66, and three pulses for 67-99.

2011-03-02 14:37:00 Author: Linque Posts: 607

---

yes pulsing them seperately gets the proper result. To be honest your explanation makes perfect sense, it'll take me a little while to properly get my head round why it makes sense, but i do mostly get it. So that basically means any damage stacking via inputs that amounts to a sum total above 33 will give an inacurate result right? for example being hit by 4 projectiles at the same time, each doing 10 damage will instead of taking 40 off, only take 26 off. doesn't that mean simply using an adder circuit to stack damage is a pretty flawed way of doing it? How would one go about making sure any stacked damage above 33 would generate multiple pulses rather than fail in attempting to stack over 33? I can't really think of a way to get that to work intelligently besides using multiple pulses which is a pretty hearty smack in the fce with a fail hammer as it makes the whole idea of instantaneous stacking completely redundant. Or am i still missing another rather large point, i probably am. hurm... bit of a pickle really.

2011-03-02 19:08:00 Author: Epicurean Dreamer Posts: 224

---

that's about the long and the short of it. using timers (or counters), you can only do a maximum of 33% damage on a .1 second life bar. To do more, you have to do multiple pulses, or longer duration pulses. It's just a limitation of using timers. This is largely why I am exploring using binary vs timers for life storage. The only real problem I am having is that it is harder to display the output than it is with a timer, and more thermo use. Everything else is vastly superior. When you are using timers in your pulses, keep in mind that you are working with percentage values. The formula is: (pulsePercentage * pulseDuration)/timerDuration=impactOnLifebar or, in this case ((pulseValue/100) * (1/30))/.1 = impactOnLifebar It's not the 33 that is being rolled over, but adders work on subtraction, so you are actually saying 100-whateveradded, and then at the end subtract it from 100 again. When the values being added exceed 100, you run into issues. So, going back to what you had originally, this is what is happening. NOT with 0 input = 100 - 0 = 100 100 subtract 30 = 70 70 subtract 75 = -5 When put into a NOT gate or combiner these are actually treated as absolute values, so you now have 5 NOT with 5 input = 100-5 = 95 ((95/100) * (1/30))/.1 = .316666 So after one hit your lifebar with a .1 duration will register just under 1/3 full. The rollover occurred in the addition portion. It's not as simple as subtracting the difference from 33.

2011-03-02 20:14:00 Author: tdarb Posts: 689

---

Why not detect the overflow (http://www.lbpcentral.com/forums/entry.php?2107-Analogue-Logic-2-Sorting-amp-Addition)? Takes more thermo but works.

2011-03-03 06:20:00 Author: waD_Delma Posts: 282

---

binary damage system ftw! Like tdarb said though, it gets difficult to display binary nicely. Problem is that you'd need a complete division of timer system to just translate your binary into a timer, and this gets very annoying for very high values. What I am using now is just some colour/effects based on how much damage is done.

2011-03-03 08:13:00 Author: SSTAGG1 Posts: 1136

---

Why not detect the overflow (http://www.lbpcentral.com/forums/entry.php?2107-Analogue-Logic-2-Sorting-amp-Addition)? Takes more thermo but works. you could detect overflow, but that means you have at least one extra frame of processing for a single hit. That just won't work when you have several projectiles, and the possibility of simultaneous hits.

2011-03-03 08:37:00 Author: tdarb Posts: 689

---

you could detect overflow, but that means you have at least one extra frame of processing for a single hit. That just won't work when you have several projectiles, and the possibility of simultaneous hits. Out of curiousity, how exactly does your binary system handle simultaneous hits on successive frames with multiple projectiles? I saw some descriptions the other day that I didn't read in depth, but there appeared to be some significant oversights in the implementation. Not to mention that tuning is just a bit of a joke. Also, you can handle overflow without incurring any extra significant latency in evaluation. There are a few ways to do so and takes a little bit of work but it's doable. Essentially you have a number of working registers and combine them into a single value, which can be tested using a comparator. All of that is doable with 0 latency until the comparator (which is only for death anyway). You'll still die at the right time as close as a player can tell. Afterwards you can either loop damage back round into the main system in the next frame, which would actually remove the need for the extra timers, or you can distribute your damage over several registers (which will make healing more difficult but is easily achievable. Also, you only ever have to handle it for systems where your sum goes over 100% in a single clock frame and realistically, the isuues with latency for an extra frame is only if you're taking this much damage on successive frames. Which is ridiculous and with that much damage coming in every second, accuracy is completely moot, no one's ever gonna notice. Especially when you consider you can simple downscale your values. Use 0.1% as your base input, rather than 1% - there's no reason to not do that (bar the trickiness of accurately storing a 0.1% signal, but yeah, we're comparing this with building an entire binary arithmetic processing unit from scratch, so I don't think that "difficulty" is worth worrying about ) and then you can take 1000 hit points per frame. What system are you using where you need to take over 3000 hit points per second AND you need the granularity on data to be that fine?? Especially in the case that multiple hits are coming in at once - in these scenarios, it's the DoT that is all the player can take in and that's fine if it takes 1 extra frame to update a display or similar - all they will ever notice is the approximate rate of damage taken - they certainly won't be taking note of every single impact and doing the maths in their heads to validate in these scenarios, nor would they be able to (except in a very few extreme cases ). I'd probably segregate the hit sources into groups and then keep track of the damage incurred on each group, whereby each group can never receive enough damage in a single frame to incur overflow, then combine the values from each group a single damage value. As stated above, this requires an extra frame to detect death. Which really isn't such a big deal. It causes a minor issue with healing, as if you want a fixed value healing system, then you would need to spread your heals between the groups. Which can be done by simple priority (fill group 1 first, then anything left over goes to group 2, etc.) This evaluation can be done in a single frame too, though the values you get for "filling" each group will be from the frame before (i.e. you won't heal damage received on the same frame as the heal is received, or from the previous frame - though the previous frame thing is actually fixable if you wan't to be that fussy about it ).

2011-03-03 08:42:00 Author: rtm223 Posts: 6497

---

Out of curiousity, how exactly does your binary system handle simultaneous hits on successive frames with multiple projectiles? I saw some descriptions the other day that I didn't read in depth, but there appeared to be some significant oversights in the implementation. Not to mention that tuning is just a bit of a joke. Basically I'm using a bit adder as my storage, the value output is looped back onto itself. i2 and ci remain for adding. My damage is transmitted via activated tags. So i have one tag sensor set to add to the main value, but I also am adding the value in a tag sensor set to detect two tags. so if 4 hits (0100), and 3 (0011), they are added together to make 7 (0111) before they ever hit the stored value for damage. it's instant. Whether I want 7 damage or 700, it works the same way. Of course, I may start running into buffering issues as I add damage types, and variable projectiles, but that is something to deal with regardless of choice. Also, you can handle overflow without incurring any extra significant latency in evaluation. There are a few ways to do so and takes a little bit of work but it's doable. Essentially you have a number of working registers and combine them into a single value, which can be tested using a comparator. All of that is doable with 0 latency until the comparator (which is only for death anyway). You'll still die at the right time as close as a player can tell. Afterwards you can either loop damage back round into the main system in the next frame, which would actually remove the need for the extra timers, or you can distribute your damage over several registers (which will make healing more difficult but is easily achievable. I would love to see a way to handle overflow with 0 latency that allows the number to go over 100. I tried for weeks with an analog system and could not do it. That's not to say it can't be done, but I just don't know how. EDIT-I am dealing with a tower defense level where i can potentially have dozens of projectiles live at any given point in time.

2011-03-03 11:59:00 Author: tdarb Posts: 689

---

Out of curiousity, how exactly does your binary system handle simultaneous hits on successive frames with multiple projectiles? More importantly, perhaps, how do you actually get an Impact Sensor to even register hits on successive frames? If it does register a hit on every frame, it's just gonna output a constant signal, so any edge-triggered logic is gonna fail anyway. Given that limitation, what's the point in building a HP bar which can update at 30Hz if you can only detect hits at 15Hz? Especially when you consider you can simple downscale your values. Use 0.1% as your base input, rather than 1% - there's no reason to not do that (bar the trickiness of accurately storing a 0.1% signal, but yeah, we're comparing this with building an entire binary arithmetic processing unit from scratch, so I don't think that "difficulty" is worth worrying about ) and then you can take 1000 hit points per frame. I guess it depends on the application. If you want to display the user's HP as an actual number, and perhaps additionally show numbers when values are added or subtracted to it, then the problem with an analog system is not latency, but accuracy. With 0.1% as a base input, I think rounding issues may cause problems with ADCs whereby sometimes the system will show that, say, 5 damage has been dealt, but you HP counter only goes down by 4, or somesuch. If you only ever display HP as a bar, then analog is good enough - I doubt anyone could tell if the bar is a tenth of a pixel higher than it should be, although in cases of known HP values, it might seem a bit odd if, given a weapon you know should do 100HP damage per hit, and an enemy you know has 1000HP, then you would expect said enemy to die with exactly 10 hits, which may not be the case with the inaccuracies of floating point math.

2011-03-03 19:24:00 Author: Aya042 Posts: 2870

---

You can detect multiple simultaneous hits by replacing an impact sensor with tag sensors. But things start to get pretty **** complicated at that point with regards to actually detecting the hits accurately. Another way to detect multiple simultaneous hits is to have the projectiles to have different tags on them and use a queue system to stack any oncoming hits. That can be done with an on/off counters and a microchips. To me however having hits register every 15Hz is more than enough, since I have an invulnerability period of 0.5s after taking a hit anyway.

2011-03-05 14:31:00 Author: Linque Posts: 607

---

More importantly, perhaps, how do you actually get an Impact Sensor to even register hits on successive frames? If it does register a hit on every frame, it's just gonna output a constant signal, so any edge-triggered logic is gonna fail anyway. By making the projectiles themselves destroy with perfect timing rather than using a pulse generator. Which is actually really simple and leaves you in a situation where as long as the rest of your processing doesn't require edge-triggers, you're fine. Neither analogue or digital systems under discussion require edge triggers. I had something running earlier with 96 hit points and 95 projectiles (actually healing points pulled in with followers - think glowy orb things from god of war, but whatever), able to process up to 4 hits per frame AND on successive frames AND it was bang on. The only time it failed to activate correctly was when a) one of my projectiles drifted off into the distance or b) when I actually received 5 simultaneous hits (I added debug logic to detect this scenario), which is an explicit limitation of the system set by me. For most of the tests there was at least 1 impact on every frame (almost all impacts within 3 seconds). This was all using sackbots and hologram, with tag sensors over impact sensors, but the theory on 30Hz detection is fine - Penguin Turf War uses impact sensors to trigger 1 frame pulses without edge-triggered logic for the recipient of the hit as well. I think rounding issues may cause problems with ADCs whereby sometimes the system will show that, say, 5 damage has been dealt, but you HP counter only goes down by 4, or somesuch Or you could work it so that the ADC has a time delayed variant that represents the value displayed in the previous frame (a trivial thing to set up) and when a change is detected, you display the difference between the two, having done the calculation in digital, the display would tally up, even if it slightly lied to you I guess it depends on the application. This I agree with.... So the next section of my post will be based around applications, rather than some detatched sense of being technically accurate. In particular why the example given, in my opinion, is a very poor example for use of a digital digital system. If you want to display the user's HP as an actual number, and perhaps additionally show numbers when values are added or subtracted to it, With "dozens of projectiles", potentially all coming in several at once or on successive frames as in a tower defence scenario, this is a tricky thing to actual make sense of, because of the potentially high rate of impact. Also, a tower defense scenario would actually have many units all taking damage at the same time as well. Exactly who is going to be playing this tower defense that can process that much visual information, let alone be able to tell if it's accurate or not? Furthermore, I'm actually struggling to think of scenarios where exact damage is dealt with every hit and displayed in an especially accurate manner in any games... Most of the ones I can think of that have huge health values, or show damage as numeric figure [WoW, FF, etc.] add randomness or variance in one way or another (see below) anyway. Many others have large amounts of damage shown as percentages, but even they add variance behind the scenes [worms, Doom]. Weapons that cause "exactly 100 damage per hit" are quite a rarity. If you have several thousand hit points this implies one of three scenarios: a) that you can lose a couple hundred in a single hit OR also take 1 damage in a single hit, b) that you can take 100s of damage in a single hit with some slight variance on it, or c) a combination of a and b. In terms of actually displaying the health as it gets peeled off, I'd like to just point out that in Worms, it works reasonably well because it's turn based (though if damage is dealt in many places it can be tough to actually take that in. In WoW, it becomes a mess as soon as things get heated. If we're talking of scenario a), then the fact that you have these low low values implies they are coming in bloody fast, else they are essentially pointless, something akin to accounting for an occasional paper-cut against your level 67 Paladin. And if we have extremely high rate of fire then that goes back to my earlier point about being able to process that information and I can't stress enough how the issue of processing information is compounded by both the rate of damage and the numerous sources of information, in the Tower Defense scenario. And again, onto the point about processing of information, there is a good reason why many games don't display health as numeric values. Because it takes longer to process for minimal benefit. It's easier to see that you have a given amount of health using a health bar, numbers make it harder to take in info like that. This is also the reason why many games choose to lengthen the health bar when you level up, rather than merely showing it as a ratio of max health in the same size bar - because it's easier to process that information if you have more health than if you lose less health proportionally. In fairness though, I can think of probably as many that don't do the extending bars as do, so make of that what you will Either way though, explicit proportionality is easier to process than a numeric value or fraction - all of our senses naturally work best on comparison and relative values, we don't deal with absolutes well. Also, the high rate of fire necessitates the ability to detect simultaneous hits. And this means duplicates. If digital is there for the accuracy, then we have to make sure not a single impact is dropped, else what's the point in having the accuracy? In a high impact rate scenario (like my 95 orbs in 3 seconds) you can justify dropping a hit here and there, or you can justify hits being a tiny fraction off, as is the case with analogue. If I wanted to avoid dropping the 5th orb to come in simultaneously it would cost me a tag sensor and a combiner, and I can up my #simultaneous hits by 1. The additional requirement for a digital system would be massive. Hence why a digital system is a poor choice. The benefit of accuracy is completely undermined by the complexity required to be accurate at the required frequency. Finally, on the subject of complexity, remember the application? Numerous units in a tower defense remember? All extra complexity costs you N times over. So, having covered the application in question and why the accuracy of digital systems isn't really warranted or probably even achievable, I'm starting to think of the places where it is warranted and on the basis of the paper-cut theory, I really can't think of one. It needs to be a moderately slow, methodical affair, probably highly tactical if the levels of ganularity are that fine and that exact (when exactly is the correct tactical time to put away the shotgun and reach for my Notepad of Slicey-Edged Doom?)... Most examples of games that are in that realms of slow, methodical, tactical affairs actually have quite low numbers of hitpoints. Here I'm thinking Warhammer and Chess (extreme examples I'll admit and arguably due to them being board games the low hit point count is as much to reduce the number of things to manually keep track of, than anything else). But honestly, I'm struggling to come up with computer games where it makes sense. Anything where you might care about precision in a genuine, game-play driven sense, is liable to have ~100 hit points maximum IMO, and analogue can handle that level of accuracy and save you a crapload of complexity. And be more tunable and a whole host of other benefits, which leads me on to: Reasons why to not use digital: Cost of resource. It's very complex to create such a system Time for development, similar to above. Personally the lag while connecting up 34 wires between a large number of 17 bit binary adders would annoy me enough to not want to do it. Tuning. Tuning in a basic analogue system can be done by tweaking battery values, so you can test various balancing parameters quickly and easily. You can even use globally located debug tags with the values so you can modify everything wirelessly in a resource-efficient manner, and never have to open a single microchip, let alone **** around with a gazillion wires to check an idea you had about balancing. Conveying information. Much of the time a health bar is better. Accuracy. Yes, it's a downside. Analogue lends itself to all manner of variance, so let's think about some of these things that the digital system makes difficult (or at least distinctly more complex), and add nice touches of layered subtlety to your game: Damage related to distance from blast center Damage related to speed of projectile Damage related to the impact speed of the projectile (subtley, yet importantly different from above). Generating impulse forces to respond to impacts (i.e. vectors pulled from the above). Damage related to age of projectile In general, the projectile simply telling you how much it hurts (i.e. You don't even have to differentiate between different types of projectile if they just tell you "take 7 damage"). Damage / healing related to your current health (heal 50% of all damage lost - OK so 50% seems like a bit of a poor choice in terms of digital systems, but not really. Even if you use the idea of 0 being max health, you still have to pull out the raw value, use a (n-1)-bit wide relay and then another n-bit wide adder to do it. It's a lot of logic, even for something that lends itself to digital). Simple random variance. Heh, you get it for free with analogue, right? You can also add it to a signal using a lightweight timer-driven set-up. Adding more power to a second hit, depending on how soon it follows the last. Bumping up the damage dealt for combos. Some of the above are prohibitively difficult to pull off well in-game if you use a digital system. Others can be done but require far higher levels of complexity a simple context switch requires a multiplexer or adder that is as wide as the specific data in the switch. Sure there are some optimisations that can be done. You could add up your lower value sources (paper cuts, bad breath, colourful language, etc.) in smaller width adders before throwing them in the mix with the bigger values. You can swap out full adders for half adders for the bits you want to be zero at each stage of addition. Whatever you do it's still massively over-complex and the only benefit, this notion of accuracy with incredibly high granularity, is so far removed from the reality of gameplay implementation that the complexity is not warranted for pretty much every example I can think of.... Also, optimisations make tuning even more complex. You pick your values and then if those values don't produce a system that plays well, you reap what you sow. I'm sure there are examples where it is worthwhile, but I really think they are going to be rare. I'm sure you or someone else will come up with some good ones now, and I'll certainly never question that the digital implementation is more accurate, I merely think that that accuracy is in no way substitute for the efficiency and subtlety of an analogue system and how that relates to a Health system. Edit: As we were talking about it before and I sort of forgot: An afterthought on latency. Digital has the issue of improved (normally 0) latency. I don't really feel this to be a significant problem, I can't think of a timer where it would need to be be greater than 0.0666s and throughput is identical. If you die a frame or 2 later then you've got a slight race condition, in the sense of whether or not you can get off a final attack in that time... But let us not forget that realtime games are one big race condition anyway and, afterall, the timing of your impacts are determined by floating point physics anyway and I'm sure Aya, or anyone else whose keen on the digital variants, will be pleased to fill you in on the inaccuracies inherent in using floats

2011-03-07 00:15:00 Author: rtm223 Posts: 6497

---

rtm, you've pretty much annihilated any thoughts I had of using digital over analogue, lol. I already switched back over to my impact/tag strength system, so no harm done. Some of your points were lost on me, but from what I got, it makes perfect sense. That GoW health system sounds cool as well. I'm planning on writing up a tutorial (perhaps with pictures or video) to explain how to create the health bar using multiple tag sensors detecting tag strength. From what I gather, this is a fairly complicated task for most people. I just remade my version of it using impacts to activate the tags, and it is 'very' easy on the thermometer. Cool to see how my quest to find a different method of detecting damage actually works.

2011-03-07 05:37:00 Author: SSTAGG1 Posts: 1136

---

Some of your points were lost on me, but from what I got, it makes perfect sense. Yeah, I'm not surprised, it's a fumbly mixture of opinion, pop psychology, technical analysis, guesswork and ranting... All written pretty late at night. Overall though, the point was to hammer home my opinion on how this accuracy of digital integer systems is not enough to justify their complexity, WRT health systems. I can't help but feel that the highly academic desire to fully understand the inaccuracies of analogue systems in a very in-depth manner (which is fine in itself) is twisting the far more useful and practical discussion of "what is most suitable for a given situation given all factors". Of course, if the digital is best for a given scenario when all factors are taken into account, then great, but that's not the analysis I've been seeing. That GoW health system sounds cool as well. Actually, it's slightly more influenced by Soul Reaver (though there's not much in it and I'm likely to blur between the lines there) I just thought GoW would be a better reference point for most people reading As a side note on that, another one of my overly paranoid failure mode ideas occurred to me earlier. If using tag sensors, then it's probably possible for one sensor to detect one frame earlier than the other, which would result in either a double hit or no hit (depending on which one detected first). However, it's incredibly unlikely. The object would have to be exactly on the boundary (unlikely due to stepped simulation) and then there were some rounding errors in the calculations of distance. This shouldn't happen between impact sensors as I'd expect impacts to be determined as pairs. Similar optimisations could be done between pairs of microchips, but IDK... It feels like that would get very complicated, very quickly, once you start considering order of operations etc. Either way it's gonna be almost so rare that you shouldn't be too bothered. I'd stick to impact sensors for anything low frequency / high damage for this reason though. Remembering that, as others have said, it's possible to vary tags to detect simultaneous impacts if you really need.

2011-03-07 11:05:00 Author: rtm223 Posts: 6497

---

By making the projectiles themselves destroy with perfect timing rather than using a pulse generator. Cunning. I never thought of that, and you're probably right that it's not all that difficult to implement, but... ...with tag sensors over impact sensors... ...means your hitboxes have to be circular, which may not be appropriate in all cases. In particular why the example given, in my opinion, is a very poor example for use of a digital digital system. In this case, I was speaking in general, rather than the specific application for this particular thread. Furthermore, I'm actually struggling to think of scenarios where exact damage is dealt with every hit and displayed in an especially accurate manner in any games... I was thinking of the Baldur's Gate series on PS2, where every time you strike an enemy, the amount of damage dealt is displayed, which is a useful feedback thing so the player knows, for example, that their non-magical sword is doing little or no damage against enemies which are immune to non-magical weapons. Weapons that cause "exactly 100 damage per hit" are quite a rarity. With the Baldur's Gate example, most weapons have a variance, but some always do the same damage per hit. However, it's very unlikely that the player would know exactly how many HP the enemy has, so I guess it doesn't matter in this case. Your "Worms" example is quite a good one. Each worm's HP is always displayed above them, and when damage is dealt, you can see both that, and their HP score drop at the same time, so it's probably important that they tally. It's probably also important that, for those weapons which always do the same damage, that they actually do. And if we have extremely high rate of fire then that goes back to my earlier point about being able to process that information and I can't stress enough how the issue of processing information is compounded by both the rate of damage and the numerous sources of information, in the Tower Defense scenario. Well, it's not impossible to do with a digital system - my observation on the switching limitation of Impact Sensors applies to analog systems too, but if you only need to keep track of one HP value, then the thermo-cost of digital may not be an issue, if you really need the accuracy. When you're in the situation where you need to keep track of HP for hundreds of enemies, then digital isn't gonna be practical, although you could opt for a hybrid where the player is digital, but the enemies are analog. And again, onto the point about processing of information, there is a good reason why many games don't display health as numeric values. But there's an equally good reason why many do - for example, those which are more strategy-based, the player might need to "crunch the numbers" in their head to figure out if a particular strategy is gonna work or not. Either way though, explicit proportionality is easier to process than a numeric value or fraction - all of our senses naturally work best on comparison and relative values, we don't deal with absolutes well. Something of a sweeping generalization there. Again, it depends on the level of accuracy required, and if I need to know exactly what the time is, I still find it quicker to read a digital clock than an analog one, but YMMV. ~100 hit points maximum IMO, and analogue can handle that level of accuracy and save you a crapload of complexity. Perhaps. I'm particularly distrustful of floating-point arithmetic generally, which is perhaps why I'm similarly distrustful of analog logic, but I haven't really done sufficient research to justify that distrust. I'm assuming that repeated roundoff error, combined with the inaccuracies of Timers, may cause problems over a sufficient length of time, but I could be wrong. I'm sure there are examples where it is worthwhile, but I really think they are going to be rare. You might be right, but bear in mind, though, that there are other applications beyond HP counters. A 'Tycoon'-like game where you're dealing with spending and making money (and assuming you don't want to use the player's score to represent their money), you might opt for a digital system, and there's still the potential for new game genres beyond those which you could reasonably imagine, but I guess the vast majority of people are just unimaginatively recreating their favorite shooty-type game, so "rare" probably isn't all that far from the truth. If you die a frame or 2 later then you've got a slight race condition, in the sense of whether or not you can get off a final attack in that time... I actually had a latency-related issue in Spacewar, but not because of the logic (which was all analog anyway). It was due to the destruction of a ship needing to remain 'alive' for a couple of frames so it could trigger a Score Giver. The net result was that you could shoot another ship, but if they were heading quickly towards you, they might survive long enough to kill you by collision. And, like you, rather than fixing it, I rationalized it, in this instance as "well, y'know the blast radius, or debris from the explosion might realisticially account for this". It's still a hack, but in most cases, a hack is good enough - which also neatly summarizes my opinion of analog logic.

2011-03-07 16:45:00 Author: Aya042 Posts: 2870

---

I realize you two are way beyond my realm of understanding, but wouldn't a solution to the projectiles issues be just to put an impact sensor on the projectile, set that sensor to activate a tag (with an AND and timer+0%battery to vary strength), and use a delay to delay the impact signal to a destroyer, so the tag pulses it's strength on impact with the target, and disappears a moment later. This would mean that the target retains its impact outline (rather than the circle of the tag sensor), and requires no pulse to limit the signal. It's the system I currently use, and it works pretty well, you just need enough tag sensors to detect X amount of simultaneous impacts. It is considerably more complex than other projectiles, due to the additional logic, but the difference is not that noticeable. My only issue is in actually producing the delay from impact to destroyer, since the only thing I've used so far is a sequencer, though that seems like something that would fill up the thermometer faster than some other method (I assume sequencers cause more load on thermo).

2011-03-07 18:14:00 Author: SSTAGG1 Posts: 1136

---

...wouldn't a solution to the projectiles issues be just to put an impact sensor on the projectile, set that sensor to activate a tag (with an AND and timer+0%battery to vary strength), and use a delay to delay the impact signal to a destroyer, so the tag pulses it's strength on impact with the target, and disappears a moment later. Again, depends on the application, but if you're dealing with shooting at multiple enemy units, you'd need some mechanism to determine which enemy was struck. My only issue is in actually producing the delay from impact to destroyer, since the only thing I've used so far is a sequencer, though that seems like something that would fill up the thermometer faster than some other method (I assume sequencers cause more load on thermo). I'd assume a quick timer would work, but the thermo-saving may well be marginal. It's possible that emitting a tag might work on the same frame as triggering the destroyer, since I'm fairly certain that the race condition is only on tag enable, given that my old one-shot logic (https://lbpcentral.lbp-hub.com/index.php?t=23400-Zero-Latency-Set-Reset-and-Toggle-Switch) demos I made in LBP1 still work fine in LBP2.

2011-03-07 18:46:00 Author: Aya042 Posts: 2870

---

I always imagine it as splash damage or collateral, but you are right that it isn't as 'contained' as the other methods.

2011-03-07 21:44:00 Author: SSTAGG1 Posts: 1136

---

I finally made a level that lets you get a timer-based health bar as a prize and see how it works inside the level. I also included an example enemy and a custom hologram health bar in addition to the health system itself. All three are available as prizes. LBP.me - Sir_Linque - COLLECTABLE Advanced health bar (http://lbp.me/v/yqdcez) http://i5.lbp.me/img/bl/595058ef4c9e5864561e692a9d3bb23c60fa2037.png

2011-03-08 22:09:00 Author: Linque Posts: 607

---

Would this work for say a zombie level? Zombie "hits" the player and it decreases aslong as it has impact?

2011-03-12 02:14:00 Author: PatriotEyez27 Posts: 34

---

I had something running earlier with 96 hit points and 95 projectiles (actually healing points pulled in with followers - think glowy orb things from god of war, but whatever), able to process up to 4 hits per frame AND on successive frames AND it was bang on. The only time it failed to activate correctly was when a) one of my projectiles drifted off into the distance or b) when I actually received 5 simultaneous hits (I added debug logic to detect this scenario), which is an explicit limitation of the system set by me. For most of the tests there was at least 1 impact on every frame (almost all impacts within 3 seconds). This was all using sackbots and hologram, with tag sensors over impact sensors, but the theory on 30Hz detection is fine - Penguin Turf War uses impact sensors to trigger 1 frame pulses without edge-triggered logic for the recipient of the hit as well. rtm - Is there any chance you might share this logic you were mentioning, either as a pic or just sharing the chip in game? I'd like to wrap my head around all this, and getting my hands on your example would go a long way to help me get there. It doesn't need any sort of demo polish. Hopefully all the explanation in this thread would yield enough insight to make sense of it, but without playing with the concrete example it's hard for me to follow some of the discussion. (I'm looking into Linque's as well, but my impression is that you've made some enhancements.)

2011-04-06 00:29:00 Author: LittleBigDave Posts: 324

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.