Random thoughts about scripting
Moderator: Moderators
-
Archangel of Death
- Posts: 854
- Joined: 28 Jan 2005, 18:15
I'm thinking that even with the slowness of lua, having the ammo carrier go through lua to call a function (or functions) in a target unit's cob to reload it's ammo will be faster than having the target doing anything of its own accord. A few ammo transporters using fancy script, or however many dozens/hundreds of other units all using fancy script?
In Total Annihilation:FLOZi wrote:Actually, it's HitByWeaponId(Z,X,id,damage)
HitByWeapon(var1,var2)
// first argument = z-position = x-angle
// second argument = x-position = z-angle
// In fact in HitByWeapon(var1,var2)
// var1 is the z-coordinate of the received shot, and so the amount of wanted rotation around the x-axis.
// var2 is the x-coordinate of the received shot, and so the amount of wanted rotation around the z-axis.
// Both coordinates exprimed in the local reference, centered and oriented by the unit, it's the axes seen in 3Do Builder, save maybe z whose sign might be inverted
// Arguments are normalised: get HYPOT(var1,var2) is always 400, or sometimes 399
// This mean you can get the direction to the impact,
// not the distance to the point of impact.
// And it's direction from unit center toward point of impact,
// not direction the shot was travelling.
The confusion is because tradionnally HitByWeapon is used only to make units rock when shot at, and when the unit is hit on the back-front axis, it must rock around the left-right axis, and vice-versa.
But that was in Total Annihilation, I have yet to investigate what are the HitByWeapon arguments in Spring.
Ok, I just tried: Camembert.ufo. The following units work very well in TA. And answer WhiteHawk question about directionnal damage on a torso that turns.
However, to my dismay, it doesn't work in Spring! The three numbers are, from top to down, first HitByWeapon argument, second HitByWeapon argument, and health. As you can see, in Spring, both HitByWeapon argument remain at zero. Both in 0.74b3 and 0.75.
Yet, you said they are normalised to 500 and not 400 in Spring, so apparently you managed to get them work. Before I go whine in development forum, can you tell me if you really had them work,and if so, what's wrong with my unit?
However, to my dismay, it doesn't work in Spring! The three numbers are, from top to down, first HitByWeapon argument, second HitByWeapon argument, and health. As you can see, in Spring, both HitByWeapon argument remain at zero. Both in 0.74b3 and 0.75.
Yet, you said they are normalised to 500 and not 400 in Spring, so apparently you managed to get them work. Before I go whine in development forum, can you tell me if you really had them work,and if so, what's wrong with my unit?
http://spring.unknown-files.net/file/28 ... rt_as_sd7/
http://spring.unknown-files.net/file/28 ... rt_in_zip/
Can you give me your working exemple?
As I said, when it is hit, HitByWeapon is called, but both argument are 0, no matter where's the point of impact. So of course I can't get the hit direction. Since my "camembert" works very fine in TA, I first assumed Spring was broken, until I recalled that what you said implied Spring supported HitByWeapon.
And what's with WhiteHawk quoting us verbatim both way in PM? Sorry for misplacing the not-capital letter btw.
http://spring.unknown-files.net/file/28 ... rt_in_zip/
Can you give me your working exemple?
As I said, when it is hit, HitByWeapon is called, but both argument are 0, no matter where's the point of impact. So of course I can't get the hit direction. Since my "camembert" works very fine in TA, I first assumed Spring was broken, until I recalled that what you said implied Spring supported HitByWeapon.
And what's with WhiteHawk quoting us verbatim both way in PM? Sorry for misplacing the not-capital letter btw.
It was s3o - but I suspect the problem lies with the weapon you are using, script looks fine. In Spring the values passed to HitByWeapon (or HitByWeaponId in 0.75, which is what i was testing, but I don't see any reason why HitByWeapon wouldn't) are based on impulse value of the weapon.
Here's the weapon I used for testing
Alot of that is probably unnessacery rubbish. First thing to try is giving your weapon some small value for impulsefactor i suppose
Here's the weapon I used for testing
Code: Select all
[m2105]
{
id=102;
name=m2a1 105mm;
rendertype=1;
//model=shell;
smoketrail=1;
color=255;
ballistic=1;
turret=1;
size=2.4;
collisionsize=1;//4;
range=2500;
reloadtime=2;
weaponvelocity=592;
areaofeffect=48;//105;
soundstart=105mm;
soundhit=Artillery1;
soundwater=exmine7;
accuracy=1;//1400;
edgeeffectiveness=0.0001;
minbarrelangle=-45;
holdtime=1;
shakemagnitude=4;
shakeduration=0.5;
energypershot=125;
targetmoveerror=0.02;
startsmoke=1;
impulsefactor=10;
impulseboost=0;
[DAMAGE]
{
default=1;
}
}Ok, after rattle told me:
<rattle> i think the idea behind is that only weapons with push a unit away can make it wobble
I just upped about every value possibly related in your weapon FBI, and now it works. Well, the HitByWeapons arguments are apparently not like in TA, because the wrong segment gets highlighted (it highlight the opposite to the one it should), but at least I have non null arguments.
It's a shame you can only read the direction of weapons that "push", but at least I know what caused my problem.
<rattle> i think the idea behind is that only weapons with push a unit away can make it wobble
I just upped about every value possibly related in your weapon FBI, and now it works. Well, the HitByWeapons arguments are apparently not like in TA, because the wrong segment gets highlighted (it highlight the opposite to the one it should), but at least I have non null arguments.
It's a shame you can only read the direction of weapons that "push", but at least I know what caused my problem.
It's possible that its just registering the hit on the opposite side, sometimes my weapon did this, too. I reduced it as much as possible but it still happened quite a bit, which is why partly why I gave directional damage a miss for now. I think perhaps beamlasers wouldn't suffer from this though, due to the special nature of their collision detection.zwzsg wrote:Well, the HitByWeapons arguments are apparently not like in TA, because the wrong segment gets highlighted (it highlight the opposite to the one it should), but at least I have non null arguments.
Uploaded the working demo:
http://spring.unknown-files.net/file/28 ... w_Working/
It's a little mod, drop it into you Spring/mods/ and run it like any mod.
Still annoys me that something that worked so quickly in TA took so many hours to make working in Spring. That the angles are map-absolute and not unit-relative seem like an bug from the devs, and I wish non-pushing weapons could have directionnal damage too (but not necessarly via the HitByWeapon way however).
By sure I meant that when the shot hits a screen away, there's no doubt whether it hits right or left. Huge AoE FTW!
http://spring.unknown-files.net/file/28 ... w_Working/
It's a little mod, drop it into you Spring/mods/ and run it like any mod.
Still annoys me that something that worked so quickly in TA took so many hours to make working in Spring. That the angles are map-absolute and not unit-relative seem like an bug from the devs, and I wish non-pushing weapons could have directionnal damage too (but not necessarly via the HitByWeapon way however).
By sure I meant that when the shot hits a screen away, there's no doubt whether it hits right or left. Huge AoE FTW!
Registering on the wrong side comes from the issue that projectiles only check collission on one point per frame which means if the first frame the projectile spends inside the unit is on the other side of the hitsphere the code tells you the impact was on the other side. This is a big issue for mods with small units, too. The CvC tank main gun would be much faster if it didn't have as much of a tendency to phase through small targets.
No. As I said twice already, I used such a big area of effect weapon that it affects the unit even when it hits 200 m away. When the point of impact is 200 m from the unit, there is zero doubt which side was hit.
Sometimes I feel like half I says is always ignored.
I was under the impression it registers from the wrong side because I supposed it worked like in TA, with the angle noted relatively to the unit. While in Spring, the angle I got from the ATAN of the HitByWeapon arguments comes noted as a map-absolute angle. Which imo is a bug and should be fixed. This is proved by how, now that I added the unit angle, my scripts works as it should: The quarter of direction of impact gets highlighted, no matter which way the unit is facing (and not matter how its turret turned)).
Anyway, just try it, it works.
However that was actually only the first step toward getting directionnal damage. Now we must:
- Find a way to read the weapon damage.
- Find a way to change the weapon damage after it has been dealt.
At first I thought about using 'get HEALTH' to know how much damage was dealt, and 'set HEALTH' to double or halve it. Problem is set/get HEALTH is in % of full health, integers only, so isn't precise enough for small shots on heavy units. But since FLOZi talks about 'HitByWeaponId(Z,X,id,damage)', I guess we can use that fourth argument to know the damage in hitpoint. We can't use the "set ARMORED to 0/1;" because, unless that was changed in Spring, haven't retested actually, HitByWeapon is called after damage is dealt, so too late to activate damagemodifier. Maybe there's some magic LUA commands to set hitpoints? It would be very convoluted, but theorically we could script-force-spawn small shots inside the unit to self-damage it? Any other ideas?
And despite having managed to get it work, I still need to get the dev:
- Correct the bug with HitByWeapon arguments using wrong coordinate system.
- Devise a way to get directionnal damage with non-pushing weapon.
Sometimes I feel like half I says is always ignored.
I was under the impression it registers from the wrong side because I supposed it worked like in TA, with the angle noted relatively to the unit. While in Spring, the angle I got from the ATAN of the HitByWeapon arguments comes noted as a map-absolute angle. Which imo is a bug and should be fixed. This is proved by how, now that I added the unit angle, my scripts works as it should: The quarter of direction of impact gets highlighted, no matter which way the unit is facing (and not matter how its turret turned)).
Anyway, just try it, it works.
However that was actually only the first step toward getting directionnal damage. Now we must:
- Find a way to read the weapon damage.
- Find a way to change the weapon damage after it has been dealt.
At first I thought about using 'get HEALTH' to know how much damage was dealt, and 'set HEALTH' to double or halve it. Problem is set/get HEALTH is in % of full health, integers only, so isn't precise enough for small shots on heavy units. But since FLOZi talks about 'HitByWeaponId(Z,X,id,damage)', I guess we can use that fourth argument to know the damage in hitpoint. We can't use the "set ARMORED to 0/1;" because, unless that was changed in Spring, haven't retested actually, HitByWeapon is called after damage is dealt, so too late to activate damagemodifier. Maybe there's some magic LUA commands to set hitpoints? It would be very convoluted, but theorically we could script-force-spawn small shots inside the unit to self-damage it? Any other ideas?
And despite having managed to get it work, I still need to get the dev:
- Correct the bug with HitByWeapon arguments using wrong coordinate system.
- Devise a way to get directionnal damage with non-pushing weapon.
*sigh*.
Perhaps you should listen to us, as well.
Yes, HitByWeaponID(x,z,id,damage) supplies the damage, and, of much greater importance, the value you return from that function sets the damage done as a %. i.e. return 100 just does normal damage, return 500 would do 5 times as much, etc.
I already have directional damage working as well as you can with ballistic wepaons.
I still don't understand how you can always be sure it is registering as hitting the right side, you probably haven't tested it with a fast enough weapon to make the problem as apparant as it really is. A huge AOE will just mean that the unit registers a (direct) hit on both sides.
My only issue is that my script is ugly:
Perhaps you should listen to us, as well.
Yes, HitByWeaponID(x,z,id,damage) supplies the damage, and, of much greater importance, the value you return from that function sets the damage done as a %. i.e. return 100 just does normal damage, return 500 would do 5 times as much, etc.
I already have directional damage working as well as you can with ballistic wepaons.
I still don't understand how you can always be sure it is registering as hitting the right side, you probably haven't tested it with a fast enough weapon to make the problem as apparant as it really is. A huge AOE will just mean that the unit registers a (direct) hit on both sides.
My only issue is that my script is ugly:
Code: Select all
#define SOUTH_CHECK(varName) varName >= (0 - FRONT_ARC) && varName <= FRONT_ARC
#define EAST_CHECK(varName) varName > FRONT_ARC && varName < (<180> - REAR_ARC)
#define WEST_CHECK(varName) varName > (0 - (<180> - REAR_ARC)) && varName < (0 - FRONT_ARC)
HitByWeaponId(z,x,id,damage)
{
var unitPacked, turrPacked, hullArmour, turrArmour, newDamage, unitAngle, hullAngle, turrAngle, tempDamage;
unitPacked = get PIECE_XZ(turret);
turrPacked = get PIECE_XZ(flare);
unitAngle = get ATAN(x,z);
hullAngle = get HEADING;
turrAngle = get XZ_ATAN(turrPacked - unitPacked);
if (SOUTH_CHECK(unitAngle)) { // South
if (SOUTH_CHECK(hullAngle)) {
hullArmour = FRONT_ARMOUR;
if (SOUTH_CHECK(turrAngle))
turrArmour = TURR_FRONT_ARMOUR;
}
// etc etc etc etc lots of nasty nested ifs
// some code to return a nice % if penetration >
// armour value
// where armour is some weighted average of
// turret and hull
}I'm sorry, I failed at finding any information on HitByWeaponID(x,z,id,damage) beside what you posted in that thread. I probably searched in the wrong places. Can you link or quote to where you said you had directionnal damage fully working, and, better, link me to a unit which has it? I would be very interested into looking at your code and testing it.
I'm not saying that my script will work with fast weapons hitting on center, I'm saying that, in order to test my script, I evacuated that issue by using a slow shot, fired far from target, and with large aoe shot. It doesn't mean the issue is solved for every weapons, just that it wasn't what caused my problem in that particular case.
But bottomline is, if the engine use the value returned by HitByWeap to change the damage dealt, that's very good, and make directionnal damage, and lots other kind of damage tweak, very easy.
I'm not saying that my script will work with fast weapons hitting on center, I'm saying that, in order to test my script, I evacuated that issue by using a slow shot, fired far from target, and with large aoe shot. It doesn't mean the issue is solved for every weapons, just that it wasn't what caused my problem in that particular case.
Err, what? I don't think the Z and X can have both values at once, so that can't be what you mean. Do you mean that HitByWeap gets called twice with large aoe weapons? My weap had quite a large aoe, yet only one side register a hit. But I guess lots of parameter could influence that. Was slow expanding explosion added to Spring for instance?A huge AOE will just mean that the unit registers a (direct) hit on both sides
But bottomline is, if the engine use the value returned by HitByWeap to change the damage dealt, that's very good, and make directionnal damage, and lots other kind of damage tweak, very easy.