Gavin, could you possibly create a new piece of code for collisions based on the percentage of trajectory traveled?

Lets say you want a missile/bomb to detonate after its traveled 60% of its current flight path.

<trajectorycollision>0.6</trajectorycollision>

this means when 60% of the mapped flight path is traveled, the missile/bomb will detonate realeasing its effects, spawn a new projectile etc.



Kanga

Hi Kangabunny :

When posts are specifically addressed to someone,
else, it makes me hesitant to offer a reply. However,
the answer to most questions concerning possibility are :

"Yes, given the resources, that should be possible."

What you seem to be requesting is that the program
calculated value (Flight_Time) be returned as a value
that can be used to modify the shot after it is fired.

Although I am not aware of a method (other than LUA) currently
available that will allow you to activate a weapon based on the
percentage of flight time consumed, there are methods available
that will allow you to detonate a weapon during it's flight.

The three options that come to mind are :

1. Apogee Detonation,
2. Delayed Detonation.
3. Combined (Apogee + Time_Delay) Detonation.

Not the solution you requested but it will allow you to release
weapons based on the time consumed after they reach apogee.

If Apogee = true
Begin Fire_Time

If Fire_Time = true
Fire_Weapon

Using LUA, you should be able to approximate the predicted
flight time by utilizing the users shooting information only.

Retrieve the firing angle and power of the desired shot.

The trajectory angle, gravity and the power factor will get
you close if that is all you require. To be more exact, you
would need to calculate the exact point of impact.

After determining the flight time, calculate and input the
desired percentage of the flight time as the Fire_Time.

Note : This method should most likely include a safe arming section
that prevents arming of the weapon in close proximity to the shooter.


Best wishes,

Rommel


P.S. - If I have stated something that requires editing, I request that a
copy of this post be sent to all concerned parties prior to it's modification.

Yes i have experimented extensively with timed/delayed/mirved/apexed detonations. LUA would be nice, if only i could understand it. (not well with math, though i understood compeletly what you suggested above).

abit more in detail______

The problem im running into: timed collisions dont scale with the power the shot was fired at. IF i fire a shot at 1000 power, it will detonate its effect at a different point on its trajctory then if i had fired it at 500 power using a timed collision node.

lets say i fire a clusterbomb at 1000 power 60 degrees (exhibit A) it will detonate abit above the target.(using apex + a timed collision)

now (exhibit B) i fire that same clusterbomb at 60 degress and 500 power.. my clusterbomb duds because it hit the ground before its timed collision.

(exhibit c) would be applied to both scenarios above, except it explodes on a percentage of the flight path instead of using a timing. It will work correctly every time regardless of power.


I believe this would be an amazing thing to add to the engine, since it already calculates theese things anyway, why not make that information tweakable via xml.
Thanks!
Kanga

If the game engine calculates the Flight_Time (not sure)
then a Proximity weapon seems very easy to implement.

NOTE : Many things seem easy when others do the work.

A weapon detonation type would be required
that utilizes the shot parameter, Proximity.

A calculation would be required to convert the impact
Flight_Time to the desired proximity for detonation.

Detonation_Time = Flight_Time / 100 * Proximity

Example :

Flight_Time (to impact) = 7.5 seconds
Proximity = 90 percent of Flight_Time

7.5 / 100 * 90 --> Detonation 6.75 seconds after firing.


Other than these two items, everything else should
already be coded and available to the game engine.


Good luck with it.

yay
you got what I meant! I was beggining to think I was very very bad at communicating my ideas to others. Sometimes it makes sense in my head, but not to others.

Now all we need to find out is if the game draws the trajectories fully, to a y value of 0 mapped on te grid, or if it only draws them for collisions (engine calculates a variable such as X based on the landscape collision bounds).


(Speed) * (Distance)=(Time)*(user percentage specified in xml tag)
so,
we could use that to create a function for time, then take a percentage of that flight time and utilize the game engine to cause the detonation at the specified moment we kicked out by taking it by desired a percentage.

any clue how to do this using LUA by chance?

Kanga

Your communication skills are fine.
The picture was nice but not required.

The problems with timed release and variable power
settings were understood before I made the initial post.

However, since you took the time to draw a picture, it
seemed that fleshing out the details a bit was warranted.

You might want to consider allowing proximity values that
are greater than 100 percent. A bouncing type weapon that
detonates after the initial impact bounce might be fun too.

Many things are possible.

About LUA ...

The calculations are not a problem but
implementation could prove challenging.

I haven't attempted to script the game
and haven't a clue about the difficultly.

Best wishes,

Rommel


Flight_Distance (to impact) will work too.

The problem is actualy that the game doesn't know when a shot is 60% of its duration. It doesn't know where the shot will end up (or how far it will go) until it actualy tries.

Hi Gavin :

If a proximity type weapon is desired, a two step
method of firing seems to provide all of the data
that the server would require.

Select weapon
If Weapon_Type = Proximity

Step 1 - Retrieve_Firing_Data
(Requires the user to use the fire button to input firing data)

Step 2 - Retrieve_Fire_Order
(Allow the user to fire the weapon or exit by selecting another)

When the user locks in a proximity shot, the firing data would be
used to calculate the Flight_Time on the client side. If fired, the
delay time to activation would be inserted into the firing information
transmitted to the server.

This type of weapon would mimic actual artillery fire very nicely.


Best Wishes,

Rommel

P.S. - The 60% per cent figure first mentioned by Kangabunny
would most likely be closer to 90% in my vision of the activation.
However, 70% or less might be desirable with some weapons.



The proximity would be controlled by the percentage noted in the
accessories file (weapon description) unless you added an additional
parameter to the firing sequence that requested the proximity.

This does not seem to be required.

Kanga you want a shell to blow just above his head?

1. Because it cant be predicted where and when the arc will end.

Instead it can be implemented something like this: <distance_from_ground>xxx</distance_from_ground>
when the projectile reach this minimal distance (and the vector of the movement is pointing downward) it will explode.

OR

2. in the past i have a similar idea like Bunny's clusterbombs.
In the real life, there is a style of artillery shooting called Ricochet firing (dont know the exact english term). When the shell hit the ground it will not explode, but jump/Ricochet and after some very short delay it explode just above his head (or into the mid air if u prefer).

I think this can be done with current modding syntax. Ricochets can be leapfrog, there is a timedelay too.

What about a flag <angle_of_falling> (the angle between projectile vector and ground tangent) that will trigger the Ricochet. it doesn't matter the firing angle it does matter the hitting angle.

Yes i Use that techneique in most of my grenades, just not air burst... though i think i just had an idea for a new weapon! Behold the bouncing bertha muwahahah

Kanga

Hi Naka :


I'm happy to see that you are interested in this too.
There are many things to consider and PM's between
Kangabunny and I aren't likely to cover everything.

Hopefully, we can get enough people working on this to
develop a solution that works and can be implemented.

Kangabunny presented a problem to me in a PM that
complicated his idea of firing and timing an invisible and
inactive test shot before firing the actual round.

Bounce shields could unknowingly cause a test missile to
travel quite some distance from the strike point required to
produce air bursts in the intended location.

Instead of a sending PM, I will reply to his problem here in
hopes that my logic errors will be discovered and a more
suitable solution can be developed.


You are correct, bounce shields could cause a problem.
This seems to be a valid point against using test shots.

An imaginary map intercept should eliminate this problem.

Instead, of firing a test shot and timing the Flight_Time to the
actual impact location, calculate the expected map intercept
using step 1 as previously described.

The imaginary intercept coordinates (X,Y and Z) provide the
data required to calculate the Flight_Time without collision.

The Flight_Time to map intercept can be used to produce the
Delay_Time required to obtain air bursts in the expected location.

If the user inputs shot data that causes a collision before
reaching the activation time (such as flat shooting into a
landscape object) the weapon could allow another action
type or no action at all if that is what is desired.


I hope that made sense.


Best wishes,

Rommel

Hi All :

Having not received feedback, it seems that I
may not have have explained myself very well.

Given That :

The game engine updates and records the map
surface coordinates (X,Y and Z) for each map
surface redraw.

The game engine updates and records the map
space coordinates (X,Y and Z) for each projectile
position redraw.

Then :

By plotting the path of an imaginary (No_Collision)
projectile and comparing the flight locations to the
map surface coordinates the projectile's map intersect
is revealed. This provides the information required to
calculate the expected Flight_Time required to produce
the type of air burst shot that Kangabunny requested.

Is this correct ?


Rommel


P.S. - Revision - Disregard the two step firing process
that was previously suggested. Implementation does not
require the user to alter their normal firing requirements.

As envisioned, the client would perform the imaginary
shot and calculate the values required to fire the
projectile. The delay time would be passed to the
weapon and the air burst round would be fired.

I see you had this fixed in the bugtracker Gavin. How did you do it? I read you used a height tag somehow? So after the firing primitive when a projectile reached a certain height it detonates?
Wont that conflict with landscape height? Or does it explode at that height above the projected impact area?

This Is gonna ROCK!

it explodes when the projectile is returning to the ground and reaches below a minimum set height above the ground. Not from the end position but from the current position.

Oooh nice That will be useful!