Ok, I've had time to test this feature, after getting some help from Rattle, and here's the scoop:
Big problem 1:
The weapons fire straight up! I dunno if that's because I set up the weapon with a restricted aim vector, to prevent bad animation behaviors, or not, yet.
Big problem 2:
The weapons don't seem to obey angle changes from the point that I'm firing from. Instead, they seem to be getting their angle from the point used in the COB to aim the weapon, only with 90 degrees added.
I'll do further tests when I get home... maybe I did something wrong. I didn't have long to test this today before Work.
Bug- Firing Weapons via COB
Moderator: Moderators
Nope, there is definitely something wrong. Tried replacing the points with a single triangle, declaring dir=dir in the weapon, and other stuff... didn't work. Very strange... it works perfectly for ExplosionGenerators, but not for weapons- it's always 90 degrees off, exactly, from the actual vector, no matter which way I turn the points. Maybe a square... hmm... nope.
Very disappointing. I can get the weapon to fire exactly the wrong way, lol... but not the right one.
Very disappointing. I can get the weapon to fire exactly the wrong way, lol... but not the right one.
After several more experiments, I'm giving up for now. I can get emit-sfx 2048 to shoot shots on +Y of the aiming Piece, but it will not spawn the weapons on +Z, like it should, and I can't seem to get it to ever "understand" that it is being fired from a Piece that has been moved. It's gotta be something veeeeeery simple, but I just don't have time to bughunt this one any more, guys.
I'll try again when it's been looked into- I'm out of time.
I'll try again when it's been looked into- I'm out of time.
I will test this again tonight, and see if any of the bugfixes have changed this situation.
Devs, I hate to have to beg, but this should really get to the point where it functions correctly. Firing weapons through script is, now that I've had more time to think about it, a major feature improvement to the game engine.
Why?
If we can fire from script, and have the weapon obey the Projectile code once firing, we can finally escape from the tyranny of OTA-style aiming and target validations. This is a very big deal.
Currently, weapons fire something like this (with a couple of major exceptions, like dropped stuff):
1. AimWeaponX() Returns TRUE when the Piece named in AimFromWeaponX is within the Tolerance angle value (this is respected by Spring- I have tested this pretty thoroughly- I should note that values under 512 don't seem to ever return TRUE however) and the script conditions (wait-for-turn), etc. have all been met.
If the Tolerance value satisfies, but the script does not return TRUE, Spring seems to have a timer that forces the weapon to fire anyhow (I have not tested this for awhile, but the last time I checked, this was still true). This was probably to compensate for poorly-coded stuff in XTA's scripts, and should almost certainly be removed from the COBHandler, but as I cannot cite the code where it is occuring at this time, I will shut up for now
2. When AimFromWeaponX returns TRUE, FireWeaponX gets called.
This is completely unnecessary. Yup... you don't need this code at all. It may have been needed in OTA for some reason, but in Spring, there's no need to execute another loop of code (let alone another loop that has a few annoying exceptional cases hard-coded... again, to deal with issues that were specific to XTA and early builds of SWS).
If we can fire weapons and have them obey vector controls and the Projectile settings correctly (this is, obviously, a little more complicated than simply creating the Projectile at the point- in the case of Guided weapons, it needs to have the target passed to it by the Unit that is firing the weapon), then we can just keep this cycle within one code loop. Ok, we'd still need an outside loop for switching barrels, but that's minor and occasionally useful.
What can we do with this, if it actually works right?
Here are a few examples:
1. A weapon that, as it fires over time, decreases/increases in accuracy. This could be done either with random Y/X angle changes at the firepoint that grew formulaically, or by calling multiple weapons depending on how many previous shots had been fired.
2. A weapon that has a true ammo state, for ground vehicles, and can only be restored after a long waiting period. This can be done somewhat successfully now, but it occasionally locks up- I have yet to see a solution for this that is 100% reliable. It's very hard to get, for example, a Katyuska type of weapon, which has, say, 24 shots, and can either blow them all at once, in series, in combinations, or whatever, but is then "out of ammo" and cannot fire again.
3. Weapons that have totally different properties could all be launched in a common salvo. For example, you could have "missiles" that are actually just ballistic weapons, but each one released could have different properties, giving them different ranges or accuracy or damage or... whatever.
4. It'd make sweeping beams ala Supcom even easier to make.
Mainly, I would really like to be able to free my weapons from the assumptions inherent in Spring's current code. Ideally, the game engine would look for a possible target for WeaponX... then let me control everything that happens next. The way it works right now isn't terrible, but it could certainly be more flexible and useful with this change in place
Devs, I hate to have to beg, but this should really get to the point where it functions correctly. Firing weapons through script is, now that I've had more time to think about it, a major feature improvement to the game engine.
Why?
If we can fire from script, and have the weapon obey the Projectile code once firing, we can finally escape from the tyranny of OTA-style aiming and target validations. This is a very big deal.
Currently, weapons fire something like this (with a couple of major exceptions, like dropped stuff):
1. AimWeaponX() Returns TRUE when the Piece named in AimFromWeaponX is within the Tolerance angle value (this is respected by Spring- I have tested this pretty thoroughly- I should note that values under 512 don't seem to ever return TRUE however) and the script conditions (wait-for-turn), etc. have all been met.
If the Tolerance value satisfies, but the script does not return TRUE, Spring seems to have a timer that forces the weapon to fire anyhow (I have not tested this for awhile, but the last time I checked, this was still true). This was probably to compensate for poorly-coded stuff in XTA's scripts, and should almost certainly be removed from the COBHandler, but as I cannot cite the code where it is occuring at this time, I will shut up for now
2. When AimFromWeaponX returns TRUE, FireWeaponX gets called.
This is completely unnecessary. Yup... you don't need this code at all. It may have been needed in OTA for some reason, but in Spring, there's no need to execute another loop of code (let alone another loop that has a few annoying exceptional cases hard-coded... again, to deal with issues that were specific to XTA and early builds of SWS).
If we can fire weapons and have them obey vector controls and the Projectile settings correctly (this is, obviously, a little more complicated than simply creating the Projectile at the point- in the case of Guided weapons, it needs to have the target passed to it by the Unit that is firing the weapon), then we can just keep this cycle within one code loop. Ok, we'd still need an outside loop for switching barrels, but that's minor and occasionally useful.
What can we do with this, if it actually works right?
Here are a few examples:
1. A weapon that, as it fires over time, decreases/increases in accuracy. This could be done either with random Y/X angle changes at the firepoint that grew formulaically, or by calling multiple weapons depending on how many previous shots had been fired.
2. A weapon that has a true ammo state, for ground vehicles, and can only be restored after a long waiting period. This can be done somewhat successfully now, but it occasionally locks up- I have yet to see a solution for this that is 100% reliable. It's very hard to get, for example, a Katyuska type of weapon, which has, say, 24 shots, and can either blow them all at once, in series, in combinations, or whatever, but is then "out of ammo" and cannot fire again.
3. Weapons that have totally different properties could all be launched in a common salvo. For example, you could have "missiles" that are actually just ballistic weapons, but each one released could have different properties, giving them different ranges or accuracy or damage or... whatever.
4. It'd make sweeping beams ala Supcom even easier to make.
Mainly, I would really like to be able to free my weapons from the assumptions inherent in Spring's current code. Ideally, the game engine would look for a possible target for WeaponX... then let me control everything that happens next. The way it works right now isn't terrible, but it could certainly be more flexible and useful with this change in place
-
PauloMorfeo
- Posts: 2004
- Joined: 15 Dec 2004, 20:53
That means that they are already possible to some extent? There is mucho interest in here to know how.Argh wrote:...
4. It'd make sweeping beams ala Supcom even easier to make.
...
My version of the TLL commander has one of those lasers and it is working marvelously beautifully except for the fact that the laser changes direction sudenly, never smoothly... Hmmmmmm .. i am going to try and remove the "wait for turn" in the script. Maybe like that he won't stop firing.
Weapons don't necessarily fire the moment the script allows them to, if e.g. the target has moved into a position where the weapon can't reach it, the attack order was cancelled, the weapon requires ressources that aren't available, the weapon isn't done reloading, etc.Argh wrote:2. When AimFromWeaponX returns TRUE, FireWeaponX gets called.
This is completely unnecessary. Yup... you don't need this code at all.
Seemed to work fine for me in GINTA though my reload script didn't just wait for a while, it refilled ammo when an ammo depot was detected nearby.2. A weapon that has a true ammo state, for ground vehicles, and can only be restored after a long waiting period. This can be done somewhat successfully now, but it occasionally locks up- I have yet to see a solution for this that is 100% reliable. It's very hard to get, for example, a Katyuska type of weapon, which has, say, 24 shots, and can either blow them all at once, in series, in combinations, or whatever, but is then "out of ammo" and cannot fire again.
Not that they're difficult to make currently...4. It'd make sweeping beams ala Supcom even easier to make.