Rocket effectivness

[EtherealN]

I guess you could do that, but then people would complain about the following things:

- Target was behind a revetment and died anyway

- Target was behind a hill and died anyway

- Infantry was behind a tank and died anyway

- airburst and explosion on the ground have the same chance of hit by fragments (unlike in real life)

- still not really realistic

 

That being said, I think I would still favor that option over other ones, and over the current behaviour as well I guess.

 

But what would you prefer if you got to choose between doing it that way now (and letting it be like that for the foreseeable future), or waiting however long it might be (I have no clue) and then getting fragmentation done RIGHT where the listed issues would not occur.

 

It's the whole "do it right or not at all" things, I guess, and we might have different preferences there. I've never been bothered by this issue, so for myself I'd rather wait. YMMV. :)

[maturin]

I guess you could do that, but then people would complain about the following things:

- Target was behind a revetment and died anyway

- Target was behind a hill and died anyway

- Infantry was behind a tank and died anyway

- airburst and explosion on the ground have the same chance of hit by fragments (unlike in real life)

- still not really realistic

 

That being said, I think I would still favor that option over other ones, and over the current behaviour as well I guess.

You can make an LoS check as well.

 

Does DCS have any airburst weapons?

[Irregular programming]

So why not do it how I explained before and actually works in any situation.

 

 

With a statistical model that only renders the shrapnel that heads towards a target.

 

It would mean that cover would be effective, a minimum of extra calculation, the statistics could always be tweaked after the fact and there is nothing unrealistic about it.

 

Then again, I think people are grossly underestimating the damage currently done by rockets in game.

[maturin]

There's no point in modeling shrapnel at all unless you have a vehicle damage model with components that can be disabled like crew, engine, tires.

 

Otherwise it's just for killing infantry which are irrelevant to this game anyways.

[Galwran]

So why not do it how I explained before and actually works in any situation.

 

 

With a statistical model that only renders the shrapnel that heads towards a target.

 

That would be the RIGHT way to do it, but then you would have to consider penetration values, etc. Propability zones with LOS check would be the EASY and FUNCTIONAL way to do it. I honestly believe that this could be modded very easily, because all you have to consider is the binary state of a unit; destroyed or not.

[Aginor]

@maturin: I know how to do it, and I'm sure so do the ED guys, that's common knowledge and you ccan do it even at home. That's not the question though.

Computing LoS in a 3D system for that many objects is just not doable in real-time without considerable computing power AND a ground unit damage model that supports damage by that technique (and also adds even more load to CPU and GPU and developers that have to redo all objects).

 

I agree with EtherealEN here, I'd rather wait for this since I don't mind the system we have now. What I proposed is a possible half-way-right solution for those who don't want to wait.

 

@Galwran:

Another half-way-right solution is to do the LoS only for "boxes" around the target, yeah. But you still have to do the LoS for the fragments and you still have to check in which boxes there are vehicles, you still have to take the terrain into account (you might even have to interpolate) and so on. I can't say how much more FPS you would get by that simplification compared to the most correct way, I'd have to think about how you could construct this in the engine. But then you will still have a suboptimal way to do it that won't work in some cases (mostly depending on how big your boxes are).

If also wonder how you got the idea that this solution might be easy, what kind of experience do you have with such algorithms? I'd be interested in it since I didn't code something like that myself yet.

[maturin]

Computing LoS in a 3D system for that many objects is just not doable in real-time without considerable computing power AND a ground unit damage model that supports damage by that technique (and also adds even more load to CPU and GPU and developers that have to redo all objects).

Oh come now, how do you imagine any unit in this game shoots at any other unit? An LoS check.

 

One column of tanks firing on another column doesn't bring the server to its knees.

 

We are not talking about "so many units," we are talking about whatever half-dozen vehicles lie within a 100m circle around the explosion. You only need to check LoS to the origin of the explosion, not model the trajectory of every fragment. Compare this to a medium-sized battle, which requires dozens of ATGM-armed units tracking each other's firelanes over multiple kilometers of terrain.

 

You don't need a damage model for this either. You just use an LoS check to possibly cancel the radius-based splash damage that already exists.

 

I agree with EtherealEN here, I'd rather wait for this since I don't mind the system we have now. What I proposed is a possible half-way-right solution for those who don't want to wait.

10 years and we can still fly through trees. I think the patience argument is pretty bankrupt.

[Aginor]

Either you do the LoS (like units do, but as funny as it may sound: It works because you don't do them often, doing LoS for every explosion and many fragments is much more, by an order of magnitude)

If you want to do it correctly you have to do it for each fragment.

In the way you are proposing it you may even do no real LoS computing at all, because you don't need it. But you won't get pretty results then.

 

EDIT:

Also the server doesn't do that, that's your client.

 

As for your other points:

Well, it seems we just disagree on that. Can't add much to the discussion from that point on, I think everything was said already.

[maturin]

But there are no fragments. None. There are only targets that may or may not be assigned randomized damage.

 

Unless you drop a bomb on some enormous tangle of vehicles that are all inhabiting the same 100 square meters, you will get like 5 checks at a time.

 

Bombs come down every couple minutes, but a single tank can fire a shell every 5 seconds. One phenomenon isn't going to be dramatically more common than the other.

[EtherealN]

Bombs come down every couple minutes, but a single tank can fire a shell every 5 seconds. One phenomenon isn't going to be dramatically more common than the other.

 

...except when someone ripples cluster bombs. :P

 

I do see your argument, the problem is that is is a bit of a "hack"; that is, it works around a problem instead of solving the problem. This is something that developers are pretty allergic to since it tends to give a temporary solution to a problem but cause bigger issues further down the line. Sometimes the "hack" really is merited, but it's hard to say that without having both the actual code (and understanding it) as well as a clear picture of what is planned for the future.

 

As an additional note: any solution, "hack" or not, must be able to run in MP, on the server, without issues. Client-side randomization is for example not an option; you're liable both to cheats and to desync issues where a given unit is killed on your client but the server (and everyone else) considers it alive. (There are aways around this though through using pseudorandomization; that is, it appears random, but the randomizer uses a deterministic model whereby the effect will be the same every time, but it will appear random to the user.)

[sobek]

Small note: All computer generated randomization is deterministic, unless one of its parameters is a digitalization of a real random process (thermal noise in a resistor, e.g.). :)

 

The usual way a random number generator works is having a batch of numbers, the "seed", from which a deterministic process generates a pseudorandom number. This number is then used to modify the seed, asf.

In such a model, if you have the original seed, the process will always end up giving you the same numbers in sequence.

Edited October 17, 2013 by sobek

[maturin]

Far more detailed fragmentation simulations can run on servers. ACE mod in ArmA adds shrapnel to all anti-personnel weapons and it runs on server with almost 200 people. I need not point out that no one has ever praised ArmA's netcode.

 

I really don't see how it's a hack. Why is it a hack for explosives but not a hack for bullets? It's a simplistic tweak to a simplistic system that isn't going to be replaced by anything complex or complete, for reasons already stated in the thread.

 

Small note: All computer generated randomization is deterministic, unless one of its parameters is a digitalization of a real random process (thermal noise in a resistor, e.g.).

If computers can roll dice well enough to support a legion of roleplaying games, I assure you, they are more than random enough for our purposes.

[sobek]

If computers can roll dice well enough to support a legion of roleplaying games, I assure you, they are more than random enough for our purposes.

 

I didn't say they weren't for such purpose, the note was purely academic.

Edited October 17, 2013 by sobek

[Galwran]

But there are no fragments. None. There are only targets that may or may not be assigned randomized damage.

 

 

Exactly. And I would do the LOS check only for terrain; not for vehicles.

 

The problem that we would like to solve is that infantry and light skinned vehicles survive bombs that explode 50 feet away. Having no protection from a tank that is between the unit and the explosion is a lesser problem than surviving near hits.

[GGTharos]

Frag computations aren't as tedious for the processor as people imagine, if you want to ignore damage to terrain.

 

It's something like this:

 

Determine what's in range of the frag, and the timing with which it will be hit (you can skip the timing of course, or you can implement it by using an expanding invisible 3d sphere and detecting collisions).

 

For each object in range:

 

1) Determine LOS to the source of explosion at the time the shrapnel would reach the target. both direct and, if you want more advanced stuff, along a ballistic curve.

2) For each object that is hit, determine the target area.

3) Compute probability of being hit (you must know probability of # of hits per area at a given distance)

4) If there are hits, generate damage (you must know average damage per fragment, and some reasonable STD so that you can vary fragment size and thus damage randomly) and if necessary penetration

 

No need to spawn hundreds of frag objects, and computations for each target object may be staggered in time at least according to distance from the source - damage computations will thus not all happen in the same simulation frame, but it is very likely that the user won't notice that (note: simulation frames are much faster than the graphical FPS we normally talk about).

Edited October 17, 2013 by GGTharos

[Fishbreath]

This thread delivers.

 

There are three inescapable facts here:

 

1) The current bomb and rocket damage model is quite bad, because it's not even beginning to account for one of the two ways in which exploding things do damage.

 

2) A full-on fragmentation model is probably limited in feasibility, given the potential for really intense scenarios like rippled cluster bombs. A simplified one might work well enough in all cases, but either way, actually keeping track of fragments would be gobs of work, and I'd rather the various engineers work on other stuff.

 

3) A probabilistic model is, I hate to break it to the rivet-counters, just about as good. A LoS check and a chance for a target to experience fragmentation damage will look, to you, just like modeling fragments individually. You won't be able to tell the difference, it'll run better than the alternative, and it'll get done about ten times faster.

 

When it comes to simulation, 'good enough' is not an insult. None of the aircraft we have yet are perfectly modeled, and none of them ever will be. We're not modeling the individual air molecules interacting with the quantum-level surfaces of the wings, and we wouldn't gain anything if we did. Additional realism in the process only goes so far toward producing additional realism in the outcome. Saying that an approximated fragmentation model is worse than no fragmentation model at all is just silly—it's like saying that a simple flight model with scripted spins is worse than a simple flight model with no spins at all, because neither of them is an advanced flight model. I would much rather have some sort of fragmentation damage modeled in six months than wait five years for a whole new damage system and individual fragment modeling that'll probably run like crap anyway.

Edited October 17, 2013 by Fishbreath

[GGTharos]

^^^^

 

Actually 'good enough' simulation is also done in real quantum science ;)

[EtherealN]

Small note: All computer generated randomization is deterministic, unless one of its parameters is a digitalization of a real random process (thermal noise in a resistor, e.g.). :)

 

Yeah, but that removes the definition from useability.

 

Example of deterministic randomziation: XCOM gets a seed each turn, and during that turn all randomization is done from that seed. This means that you gain nothing from re-doing the same action from a savegame several times to try getting a different result. (You can however get a difference from loading from a previous turn and retrying the action after having replayed.)

 

In the context, you would essentially want to ensure that all clients (and server) are "randomizing" from the same seed at all times, rather than each doing it from a locally derived one. (For example, some randomization methods derive seeds from system clock and such things, which would not be reliable in an MP context where we want clients to calculate effects.)

Edited October 17, 2013 by EtherealN

[EtherealN]

If computers can roll dice well enough to support a legion of roleplaying games, I assure you, they are more than random enough for our purposes.

 

While I agree that they can definitely be made well enough for our purposes (at least in theory, practical stuff might happen but I don't have source code access nor understanding to analyze that), RPG's are a bit coarse in their randomization needs.

[EtherealN]

Saying that an approximated fragmentation model is worse than no fragmentation model at all is just silly

 

But that is not what at least I have said.

 

What I have questioned is whether a hack today is better than a proper implementation tomorrow. That is something none of us can answer to, except through taking hints from that the devs haven't yet implemented it. No matter what one might think, the devs actually do look at things like this and evaluate gains versus cost (both time and money, which really are the same thing). It is however very possible that the reason they haven't done it is something we haven't even considered - say, perhaps they already have a prototype engine/system/chocolate factory that does this and more already running at prototype stages, but it's not yet ready for deployment. (Hacking the feature into the current code would then obviously be a bad expenditure of resources. You don't repaint your house right before you rebuild the walls.)

 

I would much rather have some sort of fragmentation damage modeled in six months than wait five years for a whole new damage system and individual fragment modeling that'll probably run like crap anyway.

 

That's the thing though - no-one that has spoken in this thread has any way of knowing whether we are looking at 5 years, 10 years, or 1 year. Some of us would probably know if it was within a couple months to perhaps 6 months - those of us who are testers - but unfortunately we would not be able to say so.

 

It is important to remember that devs are not demons. They usually have reasons for what they do, and for what they do not do. I would appreciate it if, when we discuss things like this, we assume that the devs have good reason for why Feature X isn't present yet.

[Fishbreath]

But that is not what at least I have said.

 

What I have questioned is whether a hack today is better than a proper implementation tomorrow. That is something none of us can answer to, except through taking hints from that the devs haven't yet implemented it. No matter what one might think, the devs actually do look at things like this and evaluate gains versus cost (both time and money, which really are the same thing). It is however very possible that the reason they haven't done it is something we haven't even considered - say, perhaps they already have a prototype engine/system/chocolate factory that does this and more already running at prototype stages, but it's not yet ready for deployment. (Hacking the feature into the current code would then obviously be a bad expenditure of resources. You don't repaint your house right before you rebuild the walls.)

 

Calling a probabilistic system a 'hack' is mischaracterizing it. It's a perfectly suitable system for simulating fragmentation. What people call a 'proper system' is what I, as a software engineer, would call a hack—it's cool, but it's vastly overcomplicated and very likely underperformant compared to the alternatives. If it does turn out that they almost have a full mathematical simulation done, fine. It gets us to the same place, and that's all I really care about in the end. I still think it's sandblasting a soup cracker, and that the effort would have been better spent elsewhere.

 

It is important to remember that devs are not demons. They usually have reasons for what they do, and for what they do not do. I would appreciate it if, when we discuss things like this, we assume that the devs have good reason for why Feature X isn't present yet.

 

I'm not trying to demonize the devs. I'm definitely railing against a certain class of people on this forum who refuse to accept anything that isn't a completely perfect one-to-one simulation when that's never what we're actually going to end up with.

[EtherealN]

You misunderstand my point, sorry if I was imprecise:

 

What I mean is that what might be an easy implementation on one codebase might be a hack on another; it depends on what you are working with. (The whole thing with good coding practices, avoiding the literal definition of a "hack".) What I mean is that there might be code here that dates - at least in part - back to the LO days. This is code that is being continually phased out - sound engine is already replaced, graphics is on the way, so on and forth. As a possible example of what I mean (though note that I have no code access, this is speculation); right now a LOT of stuff is done with LUA, which in part is a problem since it forces single-thread operation on a lot of things that might benefit from multithread operation. It could feasibly be that there exists a codebase where this is already implemented (or planned to be implemented) that replaces the current LUA infrastructure (that currently handles a lot of stuff for weapons, AI etcetera). This means that even if it is a year or two away, it would still be a duplication of effort in both engineering, coding and testing to implement on the current codebase that would then just be lost.

 

I'm sure there are many other possible scenarios for stuff like this, but just to illustrate the point.

 

EDIT: there might be an additional issue here, but I want to make it really clear that I have no special knowledge on this - this is NOT an ED opinion, it's not even close to my field; the LUA stuff is awesome for a lot of things, since it for example allows military clients to code sensitive stuff themselves - for example performance of secret weapons and systems. (Otherwise imagine how realistic it would be for a Russian company to develop a DTS for USAF A-10C pilots...) Due to the crosstalk between those markets as far as the codebase goes... there might be all kinds of issues neither of us will understand without seeing the code itself. Basically: it's most likely complicated in ways neither of us understand.

Edited October 17, 2013 by EtherealN

[Fishbreath]

That last part is definitely true, and I don't claim to have any particular insight into the codebase, either. In general, I tend to come down on the conceptually simpler, 95% solution for just about any problem, so that's some of it.

[maturin]

While I agree that they can definitely be made well enough for our purposes (at least in theory, practical stuff might happen but I don't have source code access nor understanding to analyze that), RPG's are a bit coarse in their randomization needs.

What do you mean? The fair outcome of a 20-sided die is the very foundation of the game. If it doesn't work, nothing does. You can't play dice if the dice are loaded. Absolutely every game mechanic hinges on probability. The purest probability that can be required.

 

For our purposes, it doesn't really matter. Our probabilities aren't based in reality, they're just something we think up to allow for a variety of outcomes. As long as an infantryman has a roughly 25% chance to survive a hail of shrapnel, that's good enough for us. If something doesn't work right, and every third guy dies in a squad with great precision, no one notices and no one complains.

 

What I have questioned is whether a hack today is better than a proper implementation tomorrow.

Really, the only downside for a simple solution now is the baggage your characterization of it as a "hack" carries. We all know it would be just fine performance-wise. At least, it couldn't be any worse than the cluster bombs.

 

It seems like most features are 'hacked' into this engine.

Edited October 17, 2013 by maturin

[EtherealN]

But the probabilities in real life are not a D20. They are physics.