Page 1 of 1
HeightMod FBI tag
Posted: 02 May 2007, 07:23
by KDR_11k
Since we just found out that Spring uses a cone for the range with a fixed multiplier for the height difference defining the range difference we'd at least like access to that modifier so we can shape the cone the way we want, not the way Spring wants. 0 should be a valid value.
Posted: 02 May 2007, 16:42
by rattle
That's a one liner...
WeaponDefHanlder.cpp, line 324:
Code: Select all
weaponDefs[id].heightmod = max(0.0f, atof(sunparser->SGetValueDef("0.2f", weaponname + "\\heightMod").c_str()));
if(weaponDefs[id].type == "Cannon")
weaponDefs[id].heightmod = 0.8f;
Posted: 02 May 2007, 17:03
by KDR_11k
That makes cannons override the heightmod.
Posted: 02 May 2007, 17:30
by rattle
Uh right...
WeaponDefHanlder.cpp, line 324:
Code: Select all
weaponDefs[id].heightmod = max(0.0f, atof(sunparser->SGetValueDef(weaponDefs[id].type == "Cannon"?"0.8f":"0.2f", weaponname + "\\heightMod").c_str()));
Now it would default to 0.8 for cannons or 0.2 for every other weapon unless the tag is set.
Posted: 04 May 2007, 04:37
by MadRat
So would a zero be a flat cone?
Posted: 04 May 2007, 06:06
by KDR_11k
A cylinder. Yes.
Posted: 04 May 2007, 07:12
by ILMTitan
I don't think I'm in favor of this. I think it would be better to rewrite the range check as a virtual function, so that different weapons could have different shapes. Height mod would likely still exist for missiles and such, but not for cannons (which would have a range change based on sqrt(a-by)). I think I'll try to do that this weekend.
Posted: 04 May 2007, 07:36
by Forboding Angel
Please do, for the love of god, please do. We've been bitching about this for a really long time.
You are me hero

Posted: 04 May 2007, 07:37
by Peet
Would separate functional and targeting ranges be feasible? Functional ranges would be the distance at which lasers fade, guided missiles do their stupid loopback thing, etc; targeting ranges would simply be the max distance a weapon could target.
Posted: 04 May 2007, 13:30
by KDR_11k
ILMTitan wrote:I don't think I'm in favor of this. I think it would be better to rewrite the range check as a virtual function, so that different weapons could have different shapes. Height mod would likely still exist for missiles and such, but not for cannons (which would have a range change based on sqrt(a-by)). I think I'll try to do that this weekend.
Can you make it somehow that we can implement our own range function for each mod? E.g. a COB or Lua call with the height as a parameter and the range modifier as a return value?
Posted: 05 May 2007, 00:07
by MadRat
ILM,
Are you suggesting separate shapes based on y-axis and z-axis?
Posted: 06 May 2007, 01:09
by ILMTitan
a. I haven't done much with COB or Lua, so I'm not quite sure how I would go about creating a COB callin.
b. Separate functional and targeting ranges already exist for some weapons, so yes.
I'm currently having difficulty deciding what to do with missiles.Currently the have a hard coded max flight time of range/projectileSpeed+25. This would give them a roughly spherical functional range. So, do I keep this, and create a targeting rage that is within it? Or do I keep a heightMod*yDiff+range targeting range, and change the functional range to be similar? Similar questions will undoubtedly be raised for other inherently spherically ranged weapons such as beamlasers, rifles, emgs, and others.
Posted: 06 May 2007, 01:35
by Zpock
While you're at it, make the missile continue homing in on the target even if the target leaves the range of the missile, until the missile flighttime (weapontimer) runs out. This way we can have missiles that continue pursuing targets if we want, and set flighttime suitable low if we don't.
What I'm saying is that functional missile range should be set naturally by flighttime * velocity.
Posted: 06 May 2007, 01:38
by Peet
And and and...instead of looping back, either explode or fall to the ground and explode :)
Posted: 06 May 2007, 01:51
by Zpock
Hmm, to clarify, there is a weapon TDF tag:
WeaponTimer = 10;
According to the wiki (my bold):
How long until the weapon will go into its second phase. For use with missile weapons. For VLaunch weapons, the weapon will turn to actually go towards its target after the specified number of seconds has expired. For non-VLaunch missiles with a TurnRate, the weapon will go randomly off-course after this period of time. Can be set to any numerical value.
Apparantly this isn't really used and instead overwritten with that hard coded formula:
Currently the have a hard coded max flight time of range/projectileSpeed+25.
So the fix is to simply set max flight time to the value of WeaponTimer. Then with weaponvelocity*WeaponTimer, you get the practical range of the missile, and can control this freely as a modder by changing either the weaponvelocity, or WeaponTimer.
Oh yeah and most mods have WeaponTimer set to 5 or thereabout so care should be taken that it's really is (approximatly) seconds and not number of frames or something. The best would be if it uses a unit so that we really do get the formula:
weaponvelocity*WeaponTimer=range
working withouth a constant thrown in but this might be hard to do i dont know.
Posted: 08 May 2007, 00:50
by MadRat
Perhaps this is a good time to ask for a slight addition to missiles, too. If you change missile range could you also set some kind of flag(s) for them to lose guidance if the shooter and/or target dies, too? I would be happy if there was some way for the missile to lose guidance if the shooter simply lost sight of the target, which would also should realistically make them lose guidance upon the shooter's death. Would be a good time to do something like that.
Looking for a way to simulate passive homing. This is valuable for any mod that is trying to simulate jet age missilery. I would understand if this would fall outside the work you're doing since what you seem to be fixing is the actual shooting logic.