[E2]Damage Functions Mk2: Complete Rehash

[Drunkie]

Can it detect damage done to all and any entity on the entire server simultaneously?

Valid point, but I'm not convinced as to what exactly detecting damage from all entities simultaneously is useful for.

[Divran]

Valid point, but I'm not convinced as to what exactly detecting damage from all entities simultaneously is useful for.

Say you want to have a battle with regular Wire or GMod turrets, and not PewPew or GCombat, and you want to use metal props and not wooden ones. Naturally, you'd want the driver to die if the tank he's sitting in gets shot. With the damage detector entity you'd have to spawn dozens of them, linked to each prop in the tank and then wire the "deal damage" input of the adv pod controller to an add chip adding them all together. Or you use E2 to automatically find all constrained props and check if any of them get hit.

Just one example.

[Jimlad]

Can it detect damage done to all and any entity on the entire server simultaneously?

And can it detect the force inflicted as a directional vector and the position that the damage was inflicted?

Yes, yes and yes. Go try it out you guys, you don't seem to know what the damage detector does and already you're jumping on making a redundant E2 extension to replicate it. Especially Divran, as a wire dev you should know what's actually in wiremod, or at least check before posting about it.

[Drunkie]

[Flieboy]

Since when has that been there? I have used the damage detector a lot and I never saw those parts, has it been updated recently? Even then, I would not consider this a redundant extension, did people consider the ranger functions redundant as well? Of course, we can just use a ranger entity, the ranger functions must be useless. I really don't understand why people want to constrain things to entities, I am yet to hear a reason that is more than "to keep wire as wire", E2 is an aspect of gmod in its own right and it may indeed be a god object but wiring can be irritating when functions allow for much more control, both are valid mediums but some may just want to do it this way. Also, it's not like I am telling people to use it, I made them for myself and I thought some people may also want them.

[Jimlad]

Since when has that been there? I have used the damage detector a lot and I never saw those parts, has it been updated recently?

It was last updated a month or two ago I think?

Even then, I would not consider this a redundant extension, did people consider the ranger functions redundant as well? Of course, we can just use a ranger entity, the ranger functions must be useless.

You can't compare the two at all. Ranger functions had additional merit in that you could make traces anywhere and use them multiple times per execution, things that were impossible with the regular wired ranger and are important in a lot of applications. In the case of a damage extension, what additional uses are there?

I really don't understand why people want to constrain things to entities, I am yet to hear a reason that is more than "to keep wire as wire", E2 is an aspect of gmod in its own right and it may indeed be a god object but wiring can be irritating when functions allow for much more control, both are valid mediums but some may just want to do it this way. Also, it's not like I am telling people to use it, I made them for myself and I thought some people may also want them.

This isn't about "keeping wire as wire", it's about adding redundant features to an already feature-bloated mod. If the functionality didn't already exist I'd say go for it. I don't really get your point about wiring being irritating... just use wirelink.

[Flieboy]

You can't compare the two at all. Ranger functions had additional merit in that you could make traces anywhere and use them multiple times per execution, things that were impossible with the regular wired ranger and are important in a lot of applications. In the case of a damage extension, what additional uses are there?

These damage functions allow you to gather damage data from any entity, as far as I know this is not possible with the damage detector, though I of course did not know about the update to it and I may be wrong. Also, it allows for persistent storage of all of the damage data, something I do with ranger data frequently, also, you cannot execute an e2 using damage, which is something I also find useful for certain things, though this could be done with inputClk or something.

This isn't about "keeping wire as wire", it's about adding redundant features to an already feature-bloated mod. If the functionality didn't already exist I'd say go for it. I don't really get your point about wiring being irritating... just use wirelink.

I agree with your point here, it was rather arrogant of me to say that, I personally get the wirelink datatype from the entity datatype and use that, it is preferable to me, but I am sure that that is frowned upon. It just seems slightly like it is kept as a separate entity for the sake of keeping it as an entity, and if e2 is bloated, I would say the same about the amount of entities I see in regular wire, some with ambiguous names.

[Jimlad]

These damage functions allow you to gather damage data from any entity, as far as I know this is not possible with the damage detector, though I of course did not know about the update to it and I may be wrong.

Yeah, you could also do that with the previous version of the damage detector. Just send whatever entity/entities you want into the inputs, that's what they're there for.

Also, it allows for persistent storage of all of the damage data, something I do with ranger data frequently

There's nothing stopping you from recording every bit of damage that's detected as tables, if that's what you want to do. It'll sure use up a lot of memory over time though, especially if you're doing it on lots of ents at once.

also, you cannot execute an e2 using damage, which is something I also find useful for certain things, though this could be done with inputClk or something.

Just wire the "Damage" output to the E2, and have the E2 trigger from it. Very simple stuff.

[Flieboy]

I see your point, but damage data specifically is already formatted as a table and can be stored a lot more easily as such. I don't think you understood my first comment, ANY damage to anything is registered, and you can receive the data as such, you don't need to specify anything!

[Jimlad]

Just one example.

I thought I'd go back to this just because it's worth mentioning that this is specifically what the damage detector was made for. It's been able to do this since it was introduced forever ago, and I've used it to make exactly what you're describing.

I see your point, but damage data specifically is already formatted as a table and can be stored a lot more easily as such.

Sure, but I don't think that's necessarily such a great benefit. It's rare that you'll want to store every piece of damage info, as opposed to just the raw damage numbers. You have to access that data individually to make use of it anyhow, and it's no easier to access a table than to use wirelink.

I don't think you understood my first comment, ANY damage to anything is registered, and you can receive the data as such, you don't need to specify anything!

Is that such a great benefit? When would you ever want to access all damage on a server? Almost always, you'll want to detect damage on a per-prop or per-contraption basis, and the damage detector does this automatically using the "include constrained props" setting.

Not only that, it's much more efficient to use the damage detector than to use these functions, because it only triggers once per tick and automatically presents damage information as a table, and only triggers when the specified props are damaged. With these functions you have to manually write an algorithm just to check whether you want the damage to register on a particular set of entities. It actually ends up being significantly more work on the part of the user, not less. The other problem is that since you have to rely on the E2 to do all the processing, you end up with tick quota problems on more prop-heavy contraptions, particularly when dealing with explosive type damage.