This is an old bug but it's about time that it got fixed.

Beamlasers are not attached to the piece that is firing it, they are attached to the target, meaning that if the beam is firing and the unit moves it's turret, the beam is all of a sudden coming out at all sorts of odd angles.

Sweepfire does not fix this, so do not even mention it. Please, fix it in the code so that the beam is attached to the piece firing it, Not the target.

Beamlasers will never really be useful until this is fixed.

+1 This has bugged me for as long as i have been playing spring.

Is this however limited to only beam lasers? I seem to remember also normal lasers with a longer beam time doing this, like the HLT in zk? And also other types of weapons like the lighting gun of the zeus is affected by this.

try tolerance=0

jk, is that in reply to him or me?

If a beamlaser has a beamtime of lets say 5, and that beam fires, once the target is dead, the turret will move and the beam will still hit the same spot while the turret turns around. You can even end up with 360 degree turret movement (beam still hitting the same spot) depending upon turret and unit movement.

you could alter the unit script so that the function called when the weapon fires sets a flag which disables turning of the turret and then unsets if after <beamtime> ms. Although it would still fail miserably if the unit decided to turn its whole body.

if the beam would always shoot straight from the turret, even small angle differences between the actual heading,pitch and the target's heading,pitch would result in a miss.

weapons seem to re-check aim twice per second or so.

That is an ugly hack. The beamlasers need to be fixed engineside.

Are you talking about emitsfx or normal firing?

I'll assume you want beamlasers to always emit straight out of whichever piece they are firing from. I strongly oppose this because if a unit turns while firing a beamlaser the beam should stay on target. This change would make beamlasers unusable for mobile units.

Add a delay script side. It is simple to do.

I think what I'm assuming you want can be done with emitsfx within blockshot and return true from block shot.

@varikonniemi that weapon is a beam laser.

Yes, I think it is currently "not possible" to make a unitscript that keeps the beam emiting piece pointed *excactly* at the target because AimWeapon (heading,pitch) is not called every frame.
Maybe one could try to interpolate or something.
Or make it so that AimWeapon is called more often for beamlasers, but both seems a bit stupid.

No, if the unit turns, ideally the turret would turn with it, maintaining firing solution, or stop firing until it has a firing solution again.

As cool as beams coming out of the side of turrets is, I'll pass. Btw, this is why I won't give you the awesome beam that you like so much in evo, because it looked frigging retarded the moment the tank did anything, which is a goddamn shame.

The beam should fire straight ahead where the turret is pointing at all times, and the turret should always be aiming at what it is firing at. It's a straight line... How is it possibly hard to understand why the current behavior is balls?

Edit: That last is a real question. I honestly don't understand how it is hard for anyone to see how the current implementation is quite flawed.

The problem arises from aiming being done on every slow update, thus you can't adjust turret heading towards target more often than that. While move orders to units can be given at any game frame, thus unit can begin turning right after it locked onto a target in the same game frame. So the next 15/16 game frames, unit's turret is static, while the unit turns/moves, as does it's target, which leads to odd firing angles.

All weapons, including beam lasers, always fire from the querry piece into the direction set by last aim call (I'm refering to fire vectors, not turret heading, as we try to adjust turret to be aligned to those vectors, not vice versa)

The only solution I see to this is make Aim calls done every game frame, and not every slow update, but that would increase load to aiming engine 15/16-fold, and that is not acceptable. Maybe every other game frame would be enough, but it's still an 8-fold load increase.

I can think of one "easy"* fix that would make them look better but make lasers less effective.

*(easy to describe, I have no idea how easy it would be to implement)

If you simply keep the laser firing the direction it was firing the last time it was able to target it would look better but there would be a good chance the target would have moved out of range.

Figure 1: Target Moved

Similarly, the beam would stay fixed when a unit turned which SHOULD logically result in targeting lock being lost for a few milliseconds.

Figure 2: Attacker Moved

Gut feeling tells me this would have to be an option because it would dramatically reduce the effectiveness of beam-lasers. Maybe a "fixed mount" option or something like that.

Do you have any idea how the engine would do this and what the game-dev interface would look like? Sure it's possible but your beam laser fix request has suddenly turned into what amounts to skeletal animation.


I think I have a reasonable feature request which will let script writers fix this problem reasonably easily.

There should be some way to get the world coordinates that a weapon is shooting at. Maybe this could be a parameter of BlockShot because each BlockShot call seems to correlate to beamLaser fire or projectile creation for other weapon types.

Once we have the world coordinates the rest can be done script side. A loop can be run to keep the piece pointing at those world coordinates. No the engine will not do this for you because your turret will probably aim using more rotations of two or more different pieces.

Forb it is a bit annoying that you say beamlasers are completely broken and unusable. They're not, many games have used them for a while. BeamLasers simply have some poor graphics which is mostly due to script writer lazyness (see ZK HLT) and exacerbated by some lacking engine support (eg world coords in block shot).

The "make beamlaser less effective" approach is really really bad. As in they would become completely unusable for mobile units.

Appreciated, however in this case "Completely broken and unusable" (I never said that!) in this instance is essentially me saying, I cannot use them currently.

Dirty little secret is that originally I wanted to have all the amphib units in Evo using beamlasers. Where hovers use a conglomeration of ballistic weapons, All terrain uses regular laser bolts. I wanted to make amphibs use beamlasers.

But basically, I can't really use them because of what sinbad has pointed out. They would look awful.

It's obvious enough that I care a lot about graphics and looks. Beamlasers look fan frigging tastic, but the firepoint being locked just ruins it :-/

I did a little more research on this and JK was on to something. With Tolerance 0 I hadn't noticed because in my experiments i had kept beamtimes super short.

However, if you set tolerance 0 and beamtime of like 1 or more you will see. The beam sticks to the angle of the turret (more or less). The only point of contention now is that aiming only seems to be called once every second or couple of seconds.

Can we speed up how often aimprimary is called on a per unit basis? If so, that would fix the issue instantly.

make how often the weapons re-check their aim and call the aiming script configurable
- mod-wide (modrules?)
- per-unit/per-weapon (unitdefs)

I have solved this problem to my satisfaction.

It appears that it is now possible to have beamtimes longer than reloadtimes (and it actually works).

The idea is, you have a laser with a reloadtime of 0.1 and a beamtime of roughly 0.2, you end up with more or less a continuous beam visually.

It's the best solution I've come up with so far.

As far as I can tell, longer beamtime is not resetting reloadtime, but if someone could back that up I would be grateful.

You can see an example of this in evo:test:346