[Review Only] Trajectory new types

[CrimRecya]

Split from #1582 . For review only. (The latest commit)

[secsome]

After reading the two specific VirtualTrajectory I'm doubting the VirtualTrajectories. The VirtualTrajectories doesn't seem to be trajectories but some specific systems which simply borrow the trajectory generic process routine? I can somewhat understand this line of thinking, but shouldn't such logic be separated into a class like spawners for handling? Not sure would thich one is more reasonable.

Also the other parts of this PR looks ok, but now I think the main problem is whether the VirtualTrajectories exists or not.

Don''t mind the other parts I mentioned below, just ignore them cause they are not the main issue now

[secsome]

Would it be better to read it here, and the child types call VirtualTrajectoryType::Read before they read their data?

[secsome]

Should the INI parsing stuffs be put together or separate like this one

[secsome]

Any idea about the constant 1.2 comes from?

[secsome]

Personally I do not think the tracing one should be a trajectory, it looks more like a spawner, which should become a independent system? putting it in trajectory seems not reasonable enough?

[secsome]

After reading the two specific VirtualTrajectory I'm doubting the VirtualTrajectories. The VirtualTrajectories doesn't seem to be trajectories but some specific systems which simply borrow the trajectory generic process routine? I can somewhat understand this line of thinking, but shouldn't such logic be separated into a class like spawners for handling? Not sure would thich one is more reasonable.

Also the other parts of this PR looks ok, but now I think the main problem is whether the VirtualTrajectories exists or not.

Don''t mind the other parts I mentioned below, just ignore them cause they are not the main issue now

btw The tracing trajectory looks just like advanced spawner? any reason to put it in trajectory instead of spawner?

[CrimRecya]

After reading the two specific VirtualTrajectory I'm doubting the VirtualTrajectories. The VirtualTrajectories doesn't seem to be trajectories but some specific systems which simply borrow the trajectory generic process routine? I can somewhat understand this line of thinking, but shouldn't such logic be separated into a class like spawners for handling? Not sure would thich one is more reasonable.
Also the other parts of this PR looks ok, but now I think the main problem is whether the VirtualTrajectories exists or not.
Don''t mind the other parts I mentioned below, just ignore them cause they are not the main issue now

btw The tracing trajectory looks just like advanced spawner? any reason to put it in trajectory instead of spawner?

The current state is indeed similar to another type of spawner. Both Engrave and Tracing were originally inspired by the Colossus in Starcraft 2, the former comes from formal design, while the latter comes from the initial design.
Previously, I incorporated the Disruptor's design (SC2) and designed a 'attach' position for it.
Later, someone mentioned the design of Acalanatha (DNF), and I think its idea is similar with this, just revolving around the target.
More later on, it became the current state, after continuous generalization and customization design, and now it looks more like a drone system, but I still retained the most basic usage, which is the last template in the doc (demo W).
For now, I still think Trajectory is a good carrier because it is simple enough and does not require too much redesign.

[secsome]

The tracing itself is a trajectory sounds reasonable, but the extended stuffs seems not reasonable enough for me.

The engrave one, however, seems have nothing to do with the trajectory (aka the trail of the bullet while flying)?

[CrimRecya]

The engrave one, however, seems have nothing to do with the trajectory (aka the trail of the bullet while flying)?

Engrave draws a "straight line" based on the target, which can rotate or move with the relative position, or just be a fixed straight line (Demo U).

[secsome]

I think its something kinda like burst but much more customizable, not thinking its a trajectory but a standalone bullet attribute for me

[Metadorius]

I think its something kinda like burst but much more customizable, not thinking its a trajectory but a standalone bullet attribute for me

I agree. Something like BurstTargetFLH, and add interpolation for FLH (we have the tools in #1304, interpolation mode there, also @Starkku pls fix/merge).

[CrimRecya]

I think its something kinda like burst but much more customizable, not thinking its a trajectory but a standalone bullet attribute for me

I agree. Something like BurstTargetFLH, and add interpolation for FLH (we have the tools in #1304, interpolation mode there, also @Starkku pls fix/merge).

This is obviously not the same thing.

Three questions:
How to make the bursts unaffected by target movement?
How to make the bursts continue attacking even after the target dies?
How to make the target only receives damage once in a round of these bursts?

[Metadorius]

How to make the bursts unaffected by target movement?
How to make the bursts continue attacking even after the target dies?

Record the location of the target for the bursts to fire at. Optionally (if we want following the target) update it from TarCom pointer from the firing TechnoClass. Also optionally record the relative location instead of absolute positions if we want the pattern to also move with firer.

How to make the target only receives damage once in a round of these bursts?

I am not sure what is this for, can you elaborate why would someone need this? Imagine if a laser beam sweeped and injured someone on the battlefield, and then swiped back and injured them again. You're proposing to give "immunity" from the second pass. I don't see why.

[secsome]

I'd paste some of my opinions here:

My thought is that
Maybe the fire location, the pattern it flies, what it done when explode should be separated
into three different parts at least
Instead of putting them into trajectory all together
These parts should all belonging to the bullet
controlling how it work
Bullet is what Westwood call them in codes
And Weapon, Warhead is a component of Bullet
aka Projectiles
Now trajectory is a part of bullet system, what Im thinking about  is making the Firing and the Exploding into parts of the bullet system too 
https://github.com/Phobos-developers/YRpp/blob/phobos-dev/BulletClass.h#L128-L155
As you can see most of the logic are components of the Bullet(Projectile) in original WW code too

[TaranDahl]

How to make the target only receives damage once in a round of these bursts?

I am not sure what is this for, can you elaborate why would someone need this? Imagine if a laser beam sweeped and injured someone on the battlefield, and then swiped back and injured them again. You're proposing to give "immunity" from the second pass. I don't see why.

Because Engrave's damage is actually achieved by multiple small-cellspread warheads detonating. If not restricted, then certain units (such as buildings) may receive multiple damages from a single shot.

[Metadorius]

Because Engrave's damage is actually achieved by multiple small-cellspread warheads detonating. If not restricted, then certain units (such as buildings) may receive multiple damages from a single shot.

Yes, and why is this a problem? This is exactly how I expect it to work and it's logical. Imagine a laser firing in 1 shot vs continuously for a period of time. It's a feature, not an issue.

[TaranDahl]

Because Engrave's damage is actually achieved by multiple small-cellspread warheads detonating. If not restricted, then certain units (such as buildings) may receive multiple damages from a single shot.

Yes, and why is this a problem? This is exactly how I expect it to work and it's logical. Imagine a laser firing in 1 shot vs continuously for a period of time. It's a feature, not an issue.

1. The Colossus in Starcraft 2, which was mentioned by CrimRecya, is not working like that.
2. Even if they are all targets of the FootClass, they may still receive variable damage due to random positions. I hope to make the damage of the weapon relatively constant.

[Metadorius]

1. The Colossus in Starcraft 2, which was mentioned by CrimRecya, is not working like that.
2. Even if they are all targets of the FootClass, they may still receive variable damage due to random positions. I hope to make the damage of the weapon relatively constant.

I mean not everything should be exactly like in StarCraft, should it? I find their implementation illogical and unintuitive to newcomers who must learn "StarCraft physics" instead of using common sense to understand how the weapon works.

Of course, if someone implements a way to prevent multiple damage (I would imagine you would keep a marker that the following bursts should not damage the same) it could probably be included, even though I am not a fan of introducing arbitrary "custom physics laws". Not sure what is the trouble here.

[Metadorius]

I just watched a video of Colossus firing it's thermal lance, and it does appear to me that this weapon effect is purely visual and it simply damages a line instantly. I don't think limiting the engraving lasers to only damage the target once is a correct approach. Instead I would make lasers do no damage and have something else damage the targets.

[mevitar]

I just watched a video of Colossus firing it's thermal lance, and it does appear to me that this weapon effect is purely visual and it simply damages a line instantly. I don't think limiting the engraving lasers to only damage the target once is a correct approach. Instead I would make lasers do no damage and have something else damage the targets.

No, it does not deal damage instantly. It deals damage over multiple periods with one fire of the weapon, and if i remember correctly, the beam is made to follow that path.
The game can also do checks like (but not limited to) making sure to not deal damage multiple times to same target.

The entire system of damage dealing in SC2 works completely different from YR, with no projectiles or warheads, so obviously it does not translate at all, but Engrave implementation is close enough to how it works in SC2.

Finally, if someone wants Engrave to deal damage multiple times to one target then they can use PassDetonate=yes. If not, then ProximityWarhead= can be used instead. I don't see a reason to reinvent this just for Engrave, when Engrave works just fine with what is already available.