Archive: 44 posts

---

Overview EDIT: Made new display (numerical). Range of 1-10000. Takes up half a segment of the thermo though. Added it to the level. This can easily be used as a customizable replacement of the classic LBP scoring system, or as your own cash system (my current use for it). Level Link: http://lbp.me/v/y4mesy This is, in my opinion, the most powerful health system available to LBP creators. Some properties are: 1-864000 health, damage, and healing Instantaneous change (0.033 seconds) for any value of damage or healing Fairly simplistic for what it is (around 50 logic pieces for the HP meter itself, 7 more for projectiles) 50 health bars only filled 2 segments of the thermometer Includes all logic you will likely require to make and use a health system You will need my model as a guide to construct this, since some of the settings for the logic pieces may be unlike what you expect. Using both guides to help you, it should take less than an hour to build. Without further ado, the tutorial... How Does it Work? This system uses fractions of X/864000 in order to achieve its range. What happens is: The Health timer outputs its value into the the logic system This value is then decreased by any damage it receives, or increased by any healing it receives The modified value then loops back to the Max Health Timer, which resets the value back to the max health if healing had made it go over This value can then be used to trigger events using a sequencer, or with comparisons to preset values (lets you use icons to represent health When health is at 0, a destroyed is triggered A timer display can work, but only works for units that have the highest possible health (eg: 100.0/100.0, or 86400.0/86400.0), otherwise the timer display only shows the fraction of health/max timer value, so a unit with 50.0 health using a timer max of 100.0 will only show 50% of the timer. In order to use, you need to simply place the base system (white microchip) onto a unit. Then you need to create emitters to create the projectiles which will damage the unit. You can also make some triggers that will cause damage or healing. Step One: Get Your Bearings This health system uses a different technique that you may not be aware of. Damage/healing is calculated using tag sensors Damage logic is mostly on projectiles, instead of the health system itself Be careful that there is enough thermo space for projectiles to be emit Impact sensor on projectile activates tag with damage value Tag sensor receives value and adjusts stored health value Same for healing Activated damage / healing is activated by a counter instead of an impact sensor Unlike the conventional impact only health system, any amount of damage/healing can be given. Since emitters don't take up much space when they have nothing emit, you can have as many different damages and heals that you need. Instead of being limited by the number of discrete damage triggers you can fit onto a single health system like in the solely impact based method, this allows you much more freedom when choosing damages and healths. Step Two: Get The Model In order to ensure your model of the damage system is correct, comparing it to my own is very helpful. If possible, read this guide while playing LBP2, and use this in conjunction with my model to make your own. The model will look like this: http://i2.lbp.me/img/ft/552d92aacf1e1cbae17a99188598c0d12eff1c3a.jpg Yep, it's that simple...oh, wait... http://i5.lbp.me/img/ft/ea5098ba4742fd878fc22baf2c3cd57ee7fea762.jpg ...hey, that's not too bad... http://i4.lbp.me/img/ft/2b4112f6f4e79dbd2e964918676473459786ddd8.jpg ...that's more like it.... Step Three: Build The Base System Your goal is this: http://i1.lbp.me/img/ft/6f1f8d75e430c66e5af6d671bbf11f97590c32de.jpg First we'll look at: http://ib.lbp.me/img/ft/b5b339263a241516b2fd38d8adfffed29a3dc05f.jpg The first part adds any healing done to to unit with: http://i2.lbp.me/img/ft/ac2078e4417b75af5c45b795c19c763ebf80bce4.jpg The second part subtracts any damage done to the unit with: http://i6.lbp.me/img/ft/5660c726a196a6809e5ecee8618b920d5008bc48.jpg The last part of all three sections removes any overflow that may have occurred (required for proper function). http://ic.lbp.me/img/ft/47c8f6a99dc380646b759938217edaaa3081f17d.jpg The empty wire input is where you may connect whichever trigger you'd like to use to reset the health back to max. The timer (white) is what limits the maximum health (current time). Whenever the max health is changed, you must reset the health value using the wire/counter (empty). http://i2.lbp.me/img/ft/bf2056ebc8715e2600562a4ca0689a15fcefaaf8.jpg These two systems then combine. The AND gate in the center loops back to the first NOT gate from the health and damage part. You can ignore the series of combiners and dividers if you do not plan on using a timer to display health. If you have only one value for health, use a timer. If you have several different amounts of health, you're going to have to use icons. http://ic.lbp.me/img/ft/5ecd3b9c990d44c9d0b9b0563c8cf5438f54cd3f.jpg The sequencer detects when health is at 0, and activates the destroyer. If you don't use a timer, put the final AND gate straight into the sequencer. Good job, you've made the base health system. Step Four: Projectiles In order for projectiles to attack or heal the correct targets, you will need to place tags that indicate what faction they are. http://i8.lbp.me/img/ft/b48cd81cf534faec201de2b7cb71b34523542799.jpg These two are simply team one and team two, but you may use more as long as you incorporate their sensors as well. http://i2.lbp.me/img/ft/4920472fa4c5e5166baaf642cdd02ba22916324d.jpg The projectile logic (left) and activated logic (right). Like explained before, the projectile logic detects when it comes into contact with an enemy or an ally and then trigger the damage for the tag. This also simultaneously activates a destroyer with a 1 tick delay from the sequencer (to allow the tag to output its damage to the tag sensor). Similar for the activated logic, only it activates a pulse and there is no destroyer. Step Five: Customize! I included a few timers preset to values of X/86400.0. http://ic.lbp.me/img/ft/5cc4b2c795d3ab7175d6d3a5e2a88ef273e9d7ad.jpg I'm not sure if you can copy them due to copyright restrictions (initially some friends complained they couldn't do anything with the timers, dunno if that still exists). If you can use these timers, you can easily adjust the health/damage/healing values on the base system and the projectiles. If not, you can always just use a smaller max timer value (like 1000.0 to give you a range of 10000). Next, you must adjust the radius of the tag sensors if you had not already done so. Make sure that they cover the entire unit. If the unit is very long, but very thin, you may notice that the sensor covers much more area than the unit due to its circular range. This is hardly an issue, but will cause units to receive damage from any projectiles that impact any enemies if the impact occurs within range of the sensor. Step Six: Celebrate Congratulations, you've just constructed a health system that can use any value from 1 to 864000 (as long as you use an X/86400.0 timer). I hope this helps! Note, most discussion is based on an older, much worse method. Current discussion starts around post 22.

2011-03-18 12:28:00 Author: SSTAGG1 Posts: 1136

---

With the timer-based health bar system you can actually have any amount of hit points on any enemy, except 2. And if you need to be able to deal 34-99% of damage in one hit, all you need is 0.066s or 0.1s of time instead of the usual minimum of 0.033s. All you need to do is adjust the damage inputs approriately. And if you want just 2hp on an enemy, you might just as well use a counter.

2011-03-18 14:57:00 Author: Linque Posts: 607

---

Let's say I want a unit to have 25000 HP, and then have a weapon that does 1 damage to it, and a weapon that does 10000 damage to it. Now say we want that same 1 damage weapon to kill another unit with 10 HP....... There's the problem, it's not very 'simple' to do. At least in my experience. It's very possible, it just takes up what I consider to be too much space. My design can do it quite simply though, but without the display. The whole point of this is to simplify the damaging method. I've found a way to make it very nice and compact.

2011-03-18 15:50:00 Author: SSTAGG1 Posts: 1136

---

The benefit if using this system is that you can easily scale damage, and deal any amount of damage to any unit. I don't quite understand the advantage of this system compared to the one discussed in this thread (https://lbpcentral.lbp-hub.com/index.php?t=52358-Analog-Memory-Cell), which circumvents the limitations of Timers by not using them at all, and for very simple cases, you can make an HP system with a single component, i.e. a Direction Combiner.

2011-03-18 16:10:00 Author: Aya042 Posts: 2870

---

Didn't realize that existed. I'll test it out. Took a while to get to the point, but looks pretty good. I'll have to reread all those posts explaining how it works though, since the organization was annoying. Also, see the link to my tutorial. It explains this better (I hope), although it's mainly for just recreating the system. EDIT: I prefer to use the timers instead of single component systems since it allows me to adjust the health of the unit by simply adding or subtracting the timer for health. For my level, health is adjusted by how much experience you have, so by being able to adjust the health the same way as damage, it's quite variable. It does look like that other method is quite a bit nicer to use though. EDIT 2: Read you post again, realized I missed the point. The reason why I am not using a simple Combiner is because I have MANY units on the screen at once. Upwards of 30, all with these damage systems and projectiles, etc. If I were to use a discrete component for each value (eg: a tag for 10 damage, another for 20, and so on, the game wouldn't work (I've already tried). This is the whole reason I'm making these very simple damage systems, just so I can pack more into the level and onto the screen at once.

2011-03-18 16:42:00 Author: SSTAGG1 Posts: 1136

---

Something else, for those who want to take this a step further, is that you can actively adjust the health of the unit as well, just like the damage. Since the health is now an independent timer, you can modify it using momentary additions or subtractions (using a Combiner). A better method would be by using a memory cell to instantly adjust the value of the health, but since I am still learning how to create them, I can't explain how to do it.

2011-03-18 17:30:00 Author: SSTAGG1 Posts: 1136

---

The reason why I am not using a simple Combiner is because I have MANY units on the screen at once. Upwards of 30, all with these damage systems and projectiles, etc. If I were to use a discrete component for each value (eg: a tag for 10 damage, another for 20, and so on, the game wouldn't work (I've already tried). I'm not sure if you're still missing the point, or I'm not understanding your system. A typical use-case for the system I was describing might be something like having a finite number of different projectile types, which deal a fixed amount of damage, and a finite number of unit types, which have a different number of hit points. In the system I was describing, you initially set up each unit to contain a combiner with a feedback loop containing the amount of HP it has, and set up each projectile with a tag containing how much damage it deals. When the projectile is deemed to have damaged a unit, it subtracts the damage specified on the projectile's tag from the value stored in the unit's feedback loop. Depending on the mechanism which determines when the damage is dealt, you can implement the entire system using just two components per unit (Direction Combiner and Impact Sensor), and one per projectile (Tag). I don't see how you could make a lower-thermo system than that.

2011-03-18 19:45:00 Author: Aya042 Posts: 2870

---

I'm not sure if you're still missing the point, or I'm not understanding your system. A typical use-case for the system I was describing might be something like having a finite number of different projectile types, which deal a fixed amount of damage, and a finite number of unit types, which have a different number of hit points. In the system I was describing, you initially set up each unit to contain a combiner with a feedback loop containing the amount of HP it has, and set up each projectile with a tag containing how much damage it deals. When the projectile is deemed to have damaged a unit, it subtracts the damage specified on the projectile's tag from the value stored in the unit's feedback loop. Depending on the mechanism which determines when the damage is dealt, you can implement the entire system using just two components per unit (Direction Combiner and Impact Sensor), and one per projectile (Tag). I don't see how you could make a lower-thermo system than that. Alright, yeah, I think we're both trying to prove different ideas. I'll just describe my method below, and see where we get. If you haven't looked at my tut post for this, I suggest doing so, since I described it a bit more. I'd like the discuss it in that thread, since this thread is just my announcement of my idea for the damage system (wasn't sure if I could get it to work, so wanted to give it the the community just in case it was useful). I admit, my method could probably be made simpler, I only created it last night. Also, I realize you only described the 'simplest' possible damage system, but in order to be useful for something as complex as an rpg or rts, I'd need something quite a bit more complex. The system you describe (2nd one), requires the tag sensor to detect the strength of the tag, which then modifies the stored value. In order to be able to react to multiple simultaneous hits, you'd need a few tag sensors with different number of required tags (because tag sensor that requires n tags detects the nth highest value). This is exactly what I've done in the adder part of my setup (minus an overflow for greater than 10000 damage which I forgot to include). From this you go to the comparing system, which compares the damage value with that of the health of the unit, when the damage is greater or equal to the health, it turns the NOT gate on, thus signaling the death of the unit. This comparison is useful since it allows the health of the unit to be easily adjusted, without interfering with the damage (since no one likes scaling and dividing by ridiculously small/large values). The projectiles would require an impact sensor to pulse the tag value. This replaces the impact sensor on the unit, and there is a good reason for this. If the impact sensor on the unit activated, and the detection radius was anything larger than the unit itself (which is going to happen), the tag sensor would pick up the values of all surrounding tags, not just those that had hit it. This would cause problems, since a single tag could be detected several times on it's movement towards the unit if there were several hits before its arrival and the projectile was within the range of the tag sensor. And that's about it. The only things that change are the timer on the projectile, the damage timer, and the health timer (only if you want to change how much health the unit has). I think it's quite simple for being able to do what it does. If you can show a way to produce a significantly simpler system with the same functionality, then I'll stop posting logic, since I'm obviously not the best person here at this. I'd like to think this is useful, since it works for me, and very well, but I suppose it really depends on exactly what you need the damage system to do. This method is only for people who really need a very wide range of possibilities, while keeping it fairly simple and easy on the thermo. For when all you need is a few damages and little variability in the health, the method commonly used, and the one comphermc described, would be better. Not sure if this was any help to whatever you may or may not have understood. Anyway, it was just an idea I had and thought it might be useful to someone who has the same problem with the normal timer health bar I had.

2011-03-18 22:18:00 Author: SSTAGG1 Posts: 1136

---

That is pretty clever. I'm a little confused on the health/damage timers though. Is your health timer (3000 and on the battery) there mostly to allow you to easily vary the health of different enemies? I'm a little confused how that all works. Would it also work to just output your health/damage timer (the one that takes input from the adders), through a NOT gate then into your sequencer for an enemy with 30000 health? sorry if those are dumb questions. I'm just trying to wrap my head around it.

2011-03-18 23:17:00 Author: tdarb Posts: 689

---

The health timer there is to provide the basis for the comparison. Instead of a normal speed scale timer, which only allows for values up to 1/3 of the bar, you use the health timer to allow for any value possible as a damage, to exist as a health. It is required, since the scale I use for damages is so small, that without it, this system would function just like the normal timer speed scale method, but would be unable to 1-hit-kill units, and would need additional scaling for units with different healths (see my example, 1 damage to one unit wouldn't be the same 1 damage to another unit without allot of scaling, and that's just annoying and thermo intensive). I guess I should say the only real difference is that instead of using the damage timer to measure health, I've added a health timer for comparison and downscaled all the values by a couple thousand. Other than that, the setup is exactly like my original impact/tag hybrid damage system. The variable health was actually an accident, I attached the adder to the health timer instead of the damage, and found that i could modify the health that way. Again, I only stumbled upon this last night, so there may still be better methods to achieve the same result. If you want a rough way to display health, you can attach multiple healths, each at a different value. Compare the damage to each health, and have each activate some visual indicator of damage. The highest health value would be the kill value. I'm not too sure how to include a sequencer to achieve the same goal, since you'd need one that is 30000 units long to display the health accurately. I suppose you could scale the values up and put them into the sequencer, but it gets more complex....and that's what I try to avoid. For your question about the NOT to the sequencer, that would get rid of the health comparison with the combiner. I don't know how it would be useful. You'd be limited to a health of 30000 that way, and it'd still be near impossible to display the health accurately. If you were just trying to make the death activation different. You could always just invert the combiner output, thus making it positive. As soon as the value is not >0, by using the same method just for the positive, it would activate whatever it is you wanted to activate upon unit death. Something I should have made clearer is that the batteries are there just to maintain the timer value. You could use toggle switches, Combiners, etc, anything that would prevent the timer from moving. You could then activate those logic devices if you wanted to adjust the health (or even the damage of the projectiles). Is your issue in recreating it, or just understanding how it works. I'm awful at explanations, so I'll try to make a better summary of how it functions.

2011-03-19 00:39:00 Author: SSTAGG1 Posts: 1136

---

hey thanks for showing me that and explaining. so, if I am seeing it correctly your damage formula on the damage/healing timer is: (Projectile Strength - Health Recovery) * (1/30) * (0.1/ Timer Duration) = Health Change which, with a .001 strength projectile, 0 health recovery, and a .1 duration timer, you get 1/30000. That was what had me confused. Now I see that your 3000 health timer just allows you to scale that into something easier to use by just adjusting that timer instead of tweaking the formula for each one. 3000 in .1 increments gives the same 30000 total positions. when taken as a percentage the two timers work together for quick and easy scaling. Very clever approach. I think I'm gonna steal that for my level

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

---

Oh, wow, thanks for calculating that. Also, your explanation seems much better than mine, so I hope you don't mind if I steal it as well. I edited the main post to use this explanation. EDIT: I also made it much more readable with spoilers (they should really make it a button in the messaging box, since it's rather annoying typing out the spoiler code). EDIT 2: I hate to double post, so here's another idea I have. I only made the damage system respond to a max value of 10000 damage and 30000 health, since I didn't feel like seeing how far the timer could go, but if I just continue scaling the values down, it should be possible to create much larger ranges of values. Does anyone know what the maximum time for a timer is. If I could reach 30000, I could increase the variability of this system 10x. Imagine being able to account for any damage from 1 to 100000, and any health from 1 to 300000. Based on the formula, it should be quite simple to manipulate the timers to account for different ranges. I'm going to hypothesize that by doubling the health and projectile timers, to 6000 and 2000, I could double the effective range of values for health and damage. I should be able to test this soon, once my bro gets off the TV.

2011-03-19 04:14:00 Author: SSTAGG1 Posts: 1136

---

Well, shoot me, I'm double posting, but this is important. It turns out that scaling by such small values, while accurate when smaller, get increasingly inaccurate when you get larger healths. I just made a 100 health unit, and shot them with 5 damage projectiles. It took 22 hits to destroy it. This is not correct. For some reason though, the 10000 damage hit deals exactly 10000 damage. This is likely an issue in how the game treats the values, since only certain damages and healths are inaccurate. This system is still useful though, since you can't detect how much damage is dealt anyway, so what does it matter that the values are a bit off? I'm imagining there is no fix for this, so unless you can deal with slightly less than perfect values, and don't need a display, you should probably look elsewhere for a damage system. I tested the 10000 damage by giving one unit 10000 health, and another 10001. The 10000 health unit took one hit to kill, the 10001 took two.

2011-03-19 06:40:00 Author: SSTAGG1 Posts: 1136

---

I built my analog multiplier expressly to address the issue of being unable to display the damage done... but I never got around to actually wiring that in. If I do figure it out I'll come back and share, but for now - The multiplier should let you use a timer to display health like they're usually used. To use the multiplier, you need a separate timer for display, and each time you deal damage to the enemy, you deal that amount of damage to the display timer scaled by some ratio I forget which involves the enemy's max health (max health isn't variable, now, without more work). This method also needs two pulses to the display timer, I think. I forget - 's been a while. Soemthing like - Pulse 1 - send full incoming damage to display timer Pulse 2 - send (maxhealth timer * incoming damage) to display timer

2011-03-19 10:59:00 Author: Loius Posts: 342

---

(fairly long explanation) Okay. Maybe I wasn't being clear. Most of your system would be similar for any HP implementation, depending on the complexity required - things such as... how much variance is there in unit HP values, and damage amounts? does it need to be able to detect multiple hits per frame? how should HP and/or damage dealt be displayed to the user, if at all? The only part I was questioning was the mechanism used to store the current HP value. I don't see how using the difference between two Timers offers an advantange over the feedback technique. But I think I understand now, i.e. that given an arbitrary starting HP value in the feedback loop, in order to restore a unit to full health, you'd have to explicitly reset it to that value, whereas in your system, you need only reset the damage timer to zero, which actually does offer an advantage in that when you try to heal a unit by more HP than it would need to restore it to max, you don't need to worry about detecting the overflow, and limiting it, since a Timer can never go lower than zero. Probably not a big deal to do with a feedback system - you need only run the initial HP value and the value calculated from (current HP + heal HP) through an AND gate to limit it. The advantage of that system over the two Timers would be instead of... - Units can have any health from 1 to 30000 - Any damage can be given from 1-10000 ...it'd be... - Units can have any health from 1 to 30000 - Any damage can be given from 1-30000 ...assuming everything else in your system stays the same, since you're not limited by the three-frame Timer problem.

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

---

The only reason I use the timers at the values I stated is because I got it to work that way. I haven't been able to test anything further, so you may be perfectly correct in there being 1-30000 possibilities for damage. Right now, the smallest damage value I could make with the correct ratio is 0.1/1000 (1 damage), which converts to 0.1/3000 health (1 health). Since I use a scale of 1000 for the damage to deal the correct value for the health, I am limited to 1000/1000, which is only 10000 damage, versus the highest value for the health, which is 3000/3000, 30000 health. Not entirely sure what you meant by advantage over the two timers. Are you saying to replace them, or keep them and add what you described. Forgive me for being bad at this, since I just hack at things until they work, so my knowledge of how logic actually works is rather limited. Also, note that I ran into an issue with dealing specific amounts of damage. 5 damage deals 5 damage to a 5 health unit, so it can 1-hit-kill, but to a 100 health unit it takes 22 hits........ This is not a case where the values get more inaccurate the higher they are, since 10000 damage deals exactly 10000 damage (tested by comparing 10000 health with 10001 health, only the 10001 took 2 hits). EDIT: I've discussed some of this in the tutorial, but I'd rather not copy/paste is here since that's kinda pointless. Maybe a good line would be: I guess I should say the only real difference is that instead of using the damage timer to measure health, I've added a health timer for comparison and downscaled all the values by a couple thousand. Also, perhaps we should close this thread and continue it in the tutorial I made, since I update that to reflect vital changes (also, it looks nicer). EDIT: This got merged, no longer needed

2011-03-19 20:34:00 Author: SSTAGG1 Posts: 1136

---

@Loius Yeah, the issue with that is it would mean every unit would need it's only multiplier, and since I'm using this system to be able to have several dozen units on screen at once, it wouldn't work. Is the inability to display the damage THAT big of an issue. Other than using different health comparisons for each damage effect, I dunno how to display it. EDIT: Whoa now, that double post was not my fault, I didn't realize these two discussions merged.

2011-03-19 20:51:00 Author: SSTAGG1 Posts: 1136

---

The only reason I use the timers at the values I stated is because I got it to work that way. I haven't been able to test anything further, so you may be perfectly correct in there being 1-30000 possibilities for damage. Well, if you're prepared to use very small floating point values, you can actually squeeze about 224 (~16.7 million) discrete values from an analog system. Not entirely sure what you meant by advantage over the two timers. Are you saying to replace them, or keep them and add what you described. Well, one Timer is only used as a fixed analog value to determine the max HP, so you'd still need something to do that if you need healing logic, but the Timer which actually varies depending on the damage taken could be replaced with a feedback loop, then you're no longer limited by the rate at which a Timer can change. Also, note that I ran into an issue with dealing specific amounts of damage. 5 damage deals 5 damage to a 5 health unit, so it can 1-hit-kill, but to a 100 health unit it takes 22 hits........ Using Timers to represent analog signals can cause additional inaccuracies due to what are arguably bugs in LBP2. See this page (http://wiki.lbpcentral.com/Talk:Timer) on the wiki. Also, perhaps we should close this thread and continue it in the tutorial I made, since I update that to reflect vital changes (also, it looks nicer). Done. Also moved some of the earlier posts too.

2011-03-19 21:06:00 Author: Aya042 Posts: 2870

---

BTW biggest time in timer is 86400.0s (took while) I am not sure did Aya mean this but if you use AND gate loop to save current health value you don't need to convert damage between damage and health. You can also plug the max health to other input of AND gate allowing to add max amount of healing to heal to max health (max health is always larger than your current health)

2011-03-19 21:18:00 Author: waD_Delma Posts: 282

---

Hmm, that would explain why this system is not working perfectly. Oh well. I'm going to try out increasingly the range of possible values, since that would be fairly awesome. Still ignoring the inaccuracy, since you can't even display it anyway, it should make this system much more advantageous. EDIT: Yeah, I'm still at a loss how to create what you all are describing. I work by visuals, which is probably why my written tutorials suck (also why it took me forever to find out how to use binary). Could someone post a pic of how this would work? EDIT 2: I'm probably missing something very important, since it seems like what you describe has worked before, but wouldn't the current health be able to go beyond the max health. The output would remain the max health, but if you wanted to damage the unit, this change would to the current health, which could be more than the max health. Wouldn't this mean the unit could take forever to deal any 'Real' damage since the current value for the health could be way beyond the max health. Eg: unit with 1 health, you heal it by 100, it now has health of 101, but output is still max of 1. It would then take 101 damage to get the health back down to 0.....??????????????? EDIT 3: Lol, nevermind, it's a feedback loop, so the AND loops back to itself only after being modified by the damage and healing...........I guess just typing it out made my realize. I will need to adjust the tutorial to reflect this change, since it would make this system much better. I'll have to make another pic and test it some to make sure the projectiles still work. EDIT: WOOT, I understand exactly how this works now! Awesome! Thanks everyone! (lol, ironic that the guy who wrote the tutorial is being taught how to do it....)

2011-03-19 21:22:00 Author: SSTAGG1 Posts: 1136

---

For those that are keeping track of how this works, here's an update (I hope this is right) Set Health timer to X/Z ('Current/Max' on timer). X is your desired value for health (0.1 to Z), Z is your desired maximum value for health and damage. Set Projectile timer to Y/Z. Y is your desired damage (0.1 to Z), Z is the max value from before. Use a feedback loop to an AND gate which takes the health timer and it's indirect feedback. To get the feedback loop, you need to first put it through the adder, which will add/subtract values to/from it to adjust the health. Since the AND gate with max health limiter can never go above the max health, you've now have a working health system for any value from 0.1 to Z. To convert this into a readable number, just multiply by 10, ignoring the decimal, so 245.6/Z becomes 2456 damage or health. 9999.9/Z becomes 99999 health or damage. Since it's possible to either scale these values, or do what waD_Delma did and make one up to 86400.0 seconds (thanks), you can effectively have 16,700,000 values with the floating point system, or 864,000 values with just a timer. Epic? I think so.

2011-03-19 22:12:00 Author: SSTAGG1 Posts: 1136

---

So, uhm, just ignore the triple post for now, since I just updated the original post, and I think it's worthy enough to allow me to do this. MAJOR UPDATE! Made the new system. works great. Still unable to display how much health........but meh, you can have 864000 health and damage (yeah, I decided to go all out and go all the way up instead of sticking to 100000). I'll take that any day. I'll have a level with it as a prize soon. EDIT: There is NO way I'm quadruple posting, so here: I need to know if the system works like it should. I used a small variety of projectiles testing just the basic functionality, but I'm worried I missed something important. Did anyone find any problems? EDIT: I knew it. I forgot to put an overflow for the damage and healing. This would likely cause NO problems, unless you decided to 'really' overkill a unit with the max amount of health, or you try to heal by more health than is possible. I'll update the logic to reflect this fix in a couple hours. EDIT 3(?): Updated the OP to use the modified system (in the note below the pic).

2011-03-20 07:17:00 Author: SSTAGG1 Posts: 1136

---

Seeing as it looks like you're getting pretty carried away here, I'm curious to know how the complexity of your health system is affecting your thermo. I'm working on something similar to an RTS and have a pretty streamlined health system going as well, complete with display, so I'm just wondering whether all of this extra complexity for scalability comes with a hefty price tag. I know logic components are cheap, but you might want to see how many units you can instance with a simplified system vs. complex system to determine whether it's really worth using. I know I've started to reach my limit on the number of units I can place in a single level, but haven't really tested to see if that's due to object complexity or logic. Since adding in my AI chips and health bars, the cost of my units seems to have jumped. At any rate, I'd be curious to see your work in progress, and you're welcome to come by and take a peek at mine.

2011-03-21 18:45:00 Author: Thegide Posts: 1465

---

The real advantage comes from being able to customize how much damage you want whenever you like. It's as simple as adjusting the timer on the projectile. Unlike many other methods where you need a unique tag for each damage (which can really add up when you use too many damages) I used to use the normal health timer, but since that was limited to 3rds of the bar, and I needed a much larger range, I decided to try to create a system with as much variability as possible. I think that once I find out how to work a memory cell, I should be able to display the value in a timer (or at least something better than the multiple health comparisons). That would allow me to instantly set the value of a timer to X/Y (from what I understood). Since LBP2 doesn't really account for unemitted items, the projectile logic, which is much more complex than the average system, doesn't actually add much to the thermo. The initial logic is arguably less complex than some of the more extensive damage systems I've seen and made, but only if you really need the range of values would I suggest using this system. The timer health bar is both simpler and easier to display. I haven't implemented this damage system into all my logic yet, but from my 'logic' level, where I just house all my new creations, it appears that the system takes up 1 degree of the thermo (you can only just notice an increase). If you wanted to see a nice looking RPG by viewing my level, think again. It's almost entirely logic right now, and mainly empty of any visuals. I've hardly been on LBP since I posted my thread for my level, other than to produce this tutorial, so it's not really anywhere close to being finished. I'd welcome anyone coming to see my level, and I'm interested in seeing how you made yours.

2011-03-21 23:51:00 Author: SSTAGG1 Posts: 1136

---

Since LBP2 doesn't really account for unemitted items, the projectile logic, which is much more complex than the average system, doesn't actually add much to the thermo. True, but bear in mind the thermo changes dynamically at runtime, so if the logic on the projectile is too complex, the engine will just stop emitting them after a sufficient number are active. The decision on whether to put the complexity in the units or the projectiles should be based on which you expect there to be more of (simultaneously) at runtime.

2011-03-22 15:14:00 Author: Aya042 Posts: 2870

---

True, but bear in mind the thermo changes dynamically at runtime, so if the logic on the projectile is too complex, the engine will just stop emitting them after a sufficient number are active. The decision on whether to put the complexity in the units or the projectiles should be based on which you expect there to be more of (simultaneously) at runtime. I wouldn't imagine enough would be emit to stop it from working. It really isn't too much logic, especially since I use many more complex logic systems, like my unit AI, and that doesn't seem to cause an issue. It would likely begin to malfunction if your have several emitters at 0.0 emit time. My testing system emit 5 different projectiles all at 0.0 time and it didn't cause an issue. Mind, that was in a level with half the thermo full, but it didn't seem to impact the thermo at all. As long as you are careful making sure it all works before hand, it shouldn't be an issue.

2011-03-22 15:26:00 Author: SSTAGG1 Posts: 1136

---

Hey man, I see you made the tutorial you told me about before, congratulations hehe ! I might try out this new stuff you are covering here when I have some spare time.

2011-03-25 00:57:00 Author: AlvaroShiokawa Posts: 126

---

Well, I think I'm on the verge of producing a way to convert this system into a timer display without any of the limitations of the timer. I've got a Help! thread going with the details. I don't even know if it would work, but it's worth a shot. Also, I'm going to add in some max health logic so you can adjust max health just as easily as you can deal damage. It's pretty much just copying the feedback loop over onto the health timer section, and using different tags to change health. EDIT: The display did not work, using comparisons is the only way to display health.

2011-03-25 06:49:00 Author: SSTAGG1 Posts: 1136

---

Well, I had another stab at making a display for this system. Success. It's very simple (only 6 logic pieces! I wasn't kidding), just an add-on to the initial system comparing the timer value with the stored value and adjusting up or down accordingly. The timer does slow down quite a bit as it approaches the stored value, but that's impossible to remove without making a much more complex system. I will also add a trigger for when the unit dies, so it cannot be healed back from death. The timer would when quickly decrease until it hits 0, destroying the unit. I had only a few minutes to make this while at a friend's. but I'll try to put up some pics or something when I have a chance. I may also make a vid or a step by step picture guide to making this, but that'll be for much later. Here's an awesome text description (because they are just that useful.......) Attach a tag sensor (strength, not proximity) to: System A) The positive input of a directional combiner. System B) The negative input of a different direction combiner. For each system, attach the combiner output into a divider (one for each system) Now take the positive output of the divider from system A and put it into the positive input of the final dir. combiner. Attach the positive output of the divider from system B to the negative input of the final dir. combiner. Put the final dir. combiner output into a timer, and have this timer output into the negative input of the first combiner from system A, and the positive input of the first combiner from system B. I hope this works. If it doesn't, my explanation is wrong somewhere. What should happen is that the timer will adjust up or down based on the value being input from the stored value. When they are equal, both system A and B should have equal values, and thus the timer value wouldn't change. Now, as the stored value changes, it will output the changing value to the this system, thus producing a display based on the amount of health remaining.

2011-05-30 22:52:00 Author: SSTAGG1 Posts: 1136

---

Since we all hate text descriptions, here's a pic of the updated system with a timer display: http://i6.lbp.me/img/ft/fb6781514cc7629dc5fc801226c1abe92d45f514.jpg

2011-06-01 18:39:00 Author: SSTAGG1 Posts: 1136

---

Hi, You said to come here if we had problems with making it work. My question is: how does it work, lol. You keep saying stored value and X/86000, but what I just need to know is how I put it on my unit and make it work. I had to make the entire thing again since it didn't let me change anything. I was trying to copy the timers but for some reason I couldnt move them. Can you change it so I can move them? Maybe I made a mistake making it. Please make that step guide tutorial, I'd really like to use this health meter.

2011-06-02 00:36:00 Author: Unknown User

---

To answer your question, can I ask my own. Can you wait a few hours for me to put up my better version of the guide (will actually be a tutorial, not just some description of it). Hopefully the updated version will help you out.

2011-06-02 13:29:00 Author: SSTAGG1 Posts: 1136

---

The picture tutorial is up! I also did some more testing with the display. Unfortunately, it only works with timers that are full (so health is 86400.0/86400.0, or X/X, etc), if you only use a single major unit, this works perfectly, but if you use more than 1, you'll need to use icons to represent health. I'll have how to make the icons up soon, probably tomorrow. If you're very proficient with logic, here's some things you may want to try out (I didn't include because they are far too complex for something I wanted to be usable by all. - You can duplicate the feedback loop for current health to modify the max health in real time as well - You can use this to create your own cash system (I'm currently using 8 cash systems for the 8 factions in my level) There are more, but I'm having trouble recalling them right now, lol. Also, if anyone knows how to calculate divisions of 6 digit numbers in real time... well, first of all, you're the master of LBP logic, and second of all, please tell (I need it to make the timers work for all health values).

2011-06-02 22:37:00 Author: SSTAGG1 Posts: 1136

---

Also, if anyone knows how to calculate divisions of 6 digit numbers in real time... well, first of all, you're the master of LBP logic, and second of all, please tell (I need it to make the timers work for all health values). How are the numbers encoded? Since there are timers involved I'm assuming you're using analog signals, so division would essentially be reducing the gain of the signal using the LBP equivalent of an attenuator.

2011-06-04 11:43:00 Author: Ayneh Posts: 2454

---

That picture earilier just confused me like all logic. Good tutorial though.

2011-06-04 15:42:00 Author: craigmond Posts: 2426

---

How are the numbers encoded? Since there are timers involved I'm assuming you're using analog signals, so division would essentially be reducing the gain of the signal using the LBP equivalent of an attenuator. I need to divide the variable current health value by the static (possible variable, depends on thermo restrictions of the level being used) max health value. Current health is an analog signal stored within the feedback loop and max health is the value shown on the timer. That means dividing a possibly 6 digit value by an equal or greater value. This would go into the timer system that would adjust to the value (display timer is speed scale at max time of 0.1 seconds, appears to work effectively instantly for any change, even going from 864000 to 0). I was certain that dividing was only possible by using sampling, which is severely limiting. I'm not quite sure how adjusting the gain would enable the signal to be interpreted as a percentage, but given my history of completely missing how certain logic works (binary, feedback, etc) until after several explanations, you could very well be right.

2011-06-04 17:08:00 Author: SSTAGG1 Posts: 1136

---

I need to divide the variable current health value by the static (possible variable, depends on thermo restrictions of the level being used) max health value. Most of the time the sum won't be an integer value if you're doing things like 5000/864000 or 500000/864000. :o Current health is an analog signal stored within the feedback loop and max health is the value shown on the timer. That means dividing a possibly 6 digit value by an equal or greater value. This would go into the timer system that would adjust to the value (display timer is speed scale at max time of 0.1 seconds, appears to work effectively instantly for any change, even going from 864000 to 0). I was certain that dividing was only possible by using sampling, which is severely limiting. I'm not quite sure how adjusting the gain would enable the signal to be interpreted as a percentage, but given my history of completely missing how certain logic works (binary, feedback, etc) until after several explanations, you could very well be right. I'm not really interested in analog logic so I wouldn't know, but if you wanted to divide by 2 for instance wouldn't you simply halve the signal?

2011-06-04 17:31:00 Author: Ayneh Posts: 2454

---

Current health is an analog signal... Best current practise (as far as I'm aware) is as per rtm223's blog entry (http://www.lbpcentral.com/forums/entry.php?2409-Analogue-Logic-5-Division-amp-Multiplication) on the subject.

2011-06-04 17:40:00 Author: Aya042 Posts: 2870

---

i have no idea what you are saying but that is really cool!

2011-06-04 17:41:00 Author: deschuttes2 Posts: 157

---

And therein lies the problem. I need a LBP tool that doesn't exist. Hopefully if they ever release a 3rd LBP, they will include operations like division and multiplication, since I'd imagine these wouldn't be that hard to integrate. Sampling just wouldn't be viable for the values I want to use. I might be able to get it close to becoming a percentage to be shown on the timer, but that would require an unreasonable amount of logic.

2011-06-04 17:45:00 Author: SSTAGG1 Posts: 1136

---

This is something I'm particularly interested in. Has anyone succeeded: 2.6. Division Most mathematical functions come with an inverse: addition and subtraction, min and max, upscaling and downscaling. For 2-input multiplication, the inverse is, of course, division. Dividing one analogue number by another is (sort of) possible using pretty much the same technique as multiplication. It should be clear that division can be characterised by: o = i1/i2 o = i1 x 1/i2If we can find a way to create 1/i, then we can indeed use the multiplication technique to provide this functionality. I'd propose that to achieve this, the most sensible approach would be to directly create a digital representation of 1/i . It's an awkward thing to pull off - the shape of the reciprocal curve doesn't really lend itself to being encoded in this way and due to the extremely steep gradient in the first 10% You're going to need to be careful about exactly how you encode this data. I've not actually done this yet, so I can't really go into details, but it is theoretically possible to achieve a reasonably accurate division function. The key would be to force high resolution along the horizontal axis for low values (think multiple sequencers and up-scale the signal to improve resolution for that region), with lower resolution for the higher values of the input - where the line goes almost horizontal.

2011-06-04 17:54:00 Author: SSTAGG1 Posts: 1136

---

This is something I'm particularly interested in. Has anyone succeeded: Yeah, there have been a few posts about converting analog to digital/binary. This blog post seems the most pertinent: http://www.lbpcentral.com/forums/entry.php?3296

2011-06-04 18:04:00 Author: Ayneh Posts: 2454

---

Alright, so I just made the number display, and I must say it's quite epic. It has a range of 10000, and has perfect accuracy (I used another prebuilt ADC display to build mine, and it incorporated a 'fudge' factor to make the values accurate). Who needs a timer when we have an exact representation of it. Woot! I tested the accuracy by sequencing a series of value changes, big and small (highest was 9999 (999.9), lowest was 1 (0.1) ). End result was correct, so I'm happy. Also, the changes were instant (well, as close to instant as I need). This was a test of the cash systems for my level (can't use scores, since I want to AI to have the same restrictions as players, so I made each faction in my level its own 'score' system), and it worked flawlessly. It's slightly more thermo intensive than my usual projects (takes up about half a segment), so I don't think I'll use it for the units in my level. I'll take a pic soon to show it. For some reason when I tried this before (as in, 3 months ago, lol), it didn't work at all, must have missed something. Anyhow, I'll have the ADC display on the prize level soon.

2011-06-04 19:51:00 Author: SSTAGG1 Posts: 1136

---

The adc display is in the level now. You can use it for anything from your own scoring/cash system, to a health meter and analog signal display. It's quite simple, just some basic hologram numbers (non-pics), but it shows what's capable fairly well.

2011-06-05 17:21:00 Author: SSTAGG1 Posts: 1136

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.