G
Guest
Guest
Archived from groups: alt.games.vgaplanets4 (More info?)
FIRE AND HIT DYNAMICS
First the screening only should be possible via a larger number of the types which should do the screening job and the stats
itself. When wings&PD fire at wings the targeted type should be randomly.
A system which is based on the documented stats in a manner that the documents have a meaning would be fine. I.e. then printed
value for fighter missile range and LW range should be of the same unit.
I would like to see that the ability to form over kill wings is tuned down, i.e. a max number of fighters in a wing, for example
1000 like it is for homeguards.
Maybe there is no need to resovle any single fighter shot. Some time for other calculations can be saved if one calculates the
all over effect of a salvo of a type in a wing at ones:
drain/damage= FighterDrain/DamageMod * f( Min[Battery/Energy for one shot;FighterCount] , FighterHitOdds, RND) where f is chosen
as suited enough to provide
Min [battery/Energy for one shot;FighterCount] * FighterDrain/DamageMod * FighterHitOdds as mean (RND is the usual random number)
and simulates the inverse of the cumulative binominal distribution
which would otherwise be needed exactly. HitOdds depends on fighter stats, ships evasive mods range, etc. in the usual manner.
Both sets of equations for the motion of ships and fighters should be of the same form and filled with different parameters. Give
fighters a small mass. If the underlying motion follows some modified form of Newton's law F=m*a with several helping equations
then moving behavior should be not problem. Maybe you introduced some latent friction to avoid everything moving arround madly
fast. Friction could be made dependent of mass, actual velocity and max combat velocity.
Maybe to time resolution sometimes is to large when object tend to "overshooting" in their motion (often unwanted and mad effects
occur when numerical solved differential equations are treated not carefully enough) and sometimes is to small when anything is
moving very slow although only a few objects are present.
Maybe you introduce further ticks between the combat tick and introduce a dynamic time resolution due to the currently fastest
objects in the vcr.
Assume a object O has chosen it's target T. Assume O is offensive and wants to stay at point blank (that means wants to be close
to T). Then the equation of motion could be
q * IIF[Distance(T,O)>FireRangeO;LocationT - LocationO;0] + p * (VelocityT - VelocityO) - r * Max( VelocityO-Vmax;0) = MassO *
AccelerationO
q, p, r are some parameters which have to be fitted to supply good motion behavior.
This equation gives low mass ships a higher aceeleration. Also the acceleration grows with increasing distance to target or vice
versa the closer the distance to the target the smaller the "wish" become faster.
In addtion there is an "escorting" term which tries to bring up the speed of O to the speed of T. Finally there is a damping term
which let the velocities not grow into the sky and should avoid annoying "swinging" and overshooting of O due to T.
So this equation serves the motion if a object has a target and wants to coming close to it.
Now one has to introduce for each mode of behavior which objects can have an set of equations of motion.
If a mode contains the condition that a target must exist then the equation should contain the target as an attracting source of
force for the object.
For example if an offensive strike through wing is in recharging mode then the outer perimeter could be made as attractor by
writing down the equations in polar coordinates and uses some suited equation for the radius coordinate of the object.
As I once suggested it would make sense if the underlying code or at least the underlying equations of motions can be discussed
by poeple who are willing and able to do this. One then could write a little VBA platform to examine the different motions before
implementing them into host. I bet there are enough outside here which could do a good job and N eyes see more than two assumed
N>2.
GFM GToeroe
FIRE AND HIT DYNAMICS
First the screening only should be possible via a larger number of the types which should do the screening job and the stats
itself. When wings&PD fire at wings the targeted type should be randomly.
A system which is based on the documented stats in a manner that the documents have a meaning would be fine. I.e. then printed
value for fighter missile range and LW range should be of the same unit.
I would like to see that the ability to form over kill wings is tuned down, i.e. a max number of fighters in a wing, for example
1000 like it is for homeguards.
Maybe there is no need to resovle any single fighter shot. Some time for other calculations can be saved if one calculates the
all over effect of a salvo of a type in a wing at ones:
drain/damage= FighterDrain/DamageMod * f( Min[Battery/Energy for one shot;FighterCount] , FighterHitOdds, RND) where f is chosen
as suited enough to provide
Min [battery/Energy for one shot;FighterCount] * FighterDrain/DamageMod * FighterHitOdds as mean (RND is the usual random number)
and simulates the inverse of the cumulative binominal distribution
which would otherwise be needed exactly. HitOdds depends on fighter stats, ships evasive mods range, etc. in the usual manner.
Both sets of equations for the motion of ships and fighters should be of the same form and filled with different parameters. Give
fighters a small mass. If the underlying motion follows some modified form of Newton's law F=m*a with several helping equations
then moving behavior should be not problem. Maybe you introduced some latent friction to avoid everything moving arround madly
fast. Friction could be made dependent of mass, actual velocity and max combat velocity.
Maybe to time resolution sometimes is to large when object tend to "overshooting" in their motion (often unwanted and mad effects
occur when numerical solved differential equations are treated not carefully enough) and sometimes is to small when anything is
moving very slow although only a few objects are present.
Maybe you introduce further ticks between the combat tick and introduce a dynamic time resolution due to the currently fastest
objects in the vcr.
Assume a object O has chosen it's target T. Assume O is offensive and wants to stay at point blank (that means wants to be close
to T). Then the equation of motion could be
q * IIF[Distance(T,O)>FireRangeO;LocationT - LocationO;0] + p * (VelocityT - VelocityO) - r * Max( VelocityO-Vmax;0) = MassO *
AccelerationO
q, p, r are some parameters which have to be fitted to supply good motion behavior.
This equation gives low mass ships a higher aceeleration. Also the acceleration grows with increasing distance to target or vice
versa the closer the distance to the target the smaller the "wish" become faster.
In addtion there is an "escorting" term which tries to bring up the speed of O to the speed of T. Finally there is a damping term
which let the velocities not grow into the sky and should avoid annoying "swinging" and overshooting of O due to T.
So this equation serves the motion if a object has a target and wants to coming close to it.
Now one has to introduce for each mode of behavior which objects can have an set of equations of motion.
If a mode contains the condition that a target must exist then the equation should contain the target as an attracting source of
force for the object.
For example if an offensive strike through wing is in recharging mode then the outer perimeter could be made as attractor by
writing down the equations in polar coordinates and uses some suited equation for the radius coordinate of the object.
As I once suggested it would make sense if the underlying code or at least the underlying equations of motions can be discussed
by poeple who are willing and able to do this. One then could write a little VBA platform to examine the different motions before
implementing them into host. I bet there are enough outside here which could do a good job and N eyes see more than two assumed
N>2.
GFM GToeroe