possible alternates to beam weapons

[Sam L.R. Griffiths]

When the AI fires a beam it all works fine as its a single hit of the trigger. Its only a problem when the trigger is held so only becomes an issue when you fire them manually.

That is bizaar, because I have found the beams obey the energy demand principles (even under Player control - and from quite extensive testing). It would be interesting to know the stats of the weapons and ships that you have tested it with.

EDIT: Also you may want to try using my ATCS script in order to monitor available energy on the fly (if you have not already got something like that).

In the absence of details of the test cases paul has run... I think I have an idea why paul might be perceiving what he is with CMOD Beams... and it comes down to the fact that the CMOD beams have bullet life that is roughly 40% of the refire interval setting (60% in the case of the IonC/PALC).

What this may mean in effect is that the actual energy demand over time could well be about half what paul is expecting when in player hands, conversely the damage applied per second of beam contact is probably also around half the equivilent applied when under AI control.

Simple answer make the bullet life and refire intervals the same and the balance should be the same in both cases. Downside being that the beam weapons will not zap fire in AI hands but rather continuously attack without taking a breath (as long as energy is available) - which is the way Egosoft have implemented them to be.

[HotSake]

In the absence of details of the test cases paul has run... I think I have an idea why paul might be perceiving what he is with CMOD Beams... and it comes down to the fact that the CMOD beams have bullet life that is roughly 40% of the refire interval setting (60% in the case of the IonC/PALC).

What this may mean in effect is that the actual energy demand over time could well be about half what paul is expecting when in player hands, conversely the damage applied per second of beam contact is probably also around half the equivilent applied when under AI control.

Just want to be sure I understand: you're saying that the beam is only actually firing for about half the time there is a visible beam on-screen. During the remaining interval, while the player is holding down the mouse button, the beam is neither draining energy nor doing damage, and the visible graphic is purely cosmetic. Energy recharges during this interval, and the beam fires again before the beam effect fades from view, creating the illusion that it never stopped firing.

Is that right?

edit: Sorry, this is getting into the ES implementation topic. Let me know if I should delete this and x-post it there.

[Sam L.R. Griffiths]

...

Just want to be sure I understand: you're saying that the beam is only actually firing for about half the time there is a visible beam on-screen. During the remaining interval, while the player is holding down the mouse button, the beam is neither draining energy nor doing damage, and the visible graphic is purely cosmetic. Energy recharges during this interval, and the beam fires again before the beam effect fades from view, creating the illusion that it never stopped firing.

Is that right?

edit: Sorry, this is getting into the ES implementation topic. Let me know if I should delete this and x-post it there.

I think I explained it in my mechanics thread, but several people have raised the issue here so we may as well address it here.

Let us say the bullet damage is 1000 with a bullet life of 0.5s and a refire interval of 1.0s. In the AI hands, the beam will pulse for 0.5s and rest for 0.5s applying damage at a rate of 2000 per second for the duration of the pulse (overall damage per second is 1000 per second though). The player on the other hand will do a continuous 1000 damage per second over the duration of the beam firing.

Due to the fact that hardcoded beams are "damage/drain per second type weapond" if the energy cost for the bullet is say 100 the energy demand is not the full 100 but 100/s (continuous energy drain over time). With the bullet life at 0.5s, the beam will persist and continue to do damage for 0.5s after ship energy has been exhausted for that 0.5s. In this case the actual required energy demand for apparent continuous firing is slightly less than 100/s but in practical terms a single beam will still need 100/s but due to the 0.5s after bullet life it is possible to appear to be able to fire two beams continously for less than the combined draw of 200/s (150/s would be needed in that case if I am not mistaken).

This is where my original comment about matching bullet life to refire interval comes from, if they are the same then the performance between AI and Player should be the same. If the bullet life is shorter than the refire rate then the damage will be dealt quicker to a target by the AI than it is by the player. If the bullet life is longer than the refire interval then the maths gets more complicated, but essentially when the AI fires multiple beams can appear to exist from the same weapon on potentially different vectors at the same time.

For example, let us take the 1000 per bullet with a 2s life and a 1s refire interval. The AI will deal 500/s to any given target but due to upto 2 bullets persisting at any given time the mean effective rate of damage is still 1000/s. However, in Player hands the beam will deal 1000/s regardless of the bullet life and will have a post firing persistance equal to the bullet life. So in this case the post firing persistance is 2s meaning that the ship can be short of the beam's energy demand for 2s but providing there is sufficient energy for the beam to pulse again in the 2s period it will give the appearance of continuous fire (theoretical energy mean energy demand of 50/s for one beam).

If the bullet life is kept short, and the refire rate reciprically high (e.g. 0.1s bullet life and 600rpm refire rate) then the after bullet persistance will be less prenounced and the beam will visually stop firing when energy demand is not met. If the bullet life is longer and the refire rate reciprically lower (e.g. 5s bullet life and 20rpm refire rate) then the bullet persistance will be more pronounced and actual energy demand in low energy cases will be lower than expected for the player. With the bullet life and refire rate matched appropriately, the AI turrets will perform the same as the player overall.

The main differences in beam balance being that:-

1. the AI turret logic is restricted by the refire rate with respect to the number of targets that can be engaged where as the player is not.
2. longer bullet lifes will mean that the player can use the post-firing persistance to their advantage to increase overall damage per second by rapid pressing of the fire key/button (not too different from charging of projectile weapons)

[builder680]

Not really any technical expertise on this stuff from me, but an observation that may have some use.

Beams in general cause me huge FPS problems, probably due to some of the reasons you guys are talking about. But for some reason, I have much less FPS hit with TBC's, at least the ones from CMOD. Not sure if they have much difference from vanilla, but the other beams are frame chugging monsters. Kyons, FBC's, PBC's, etc... are the ones that cause me the most grief. Maybe if they more represented the way the TBC works (except in their total damage of course) they'd cause less hitches?

Just my observation from my own games on my own system, perhaps it isn't the same for everyone else. For all I know TBC calculates and renders the same as all the other beams... although I do seem to notice it doesn't have as much 'glow.'

[Sam L.R. Griffiths]

Not really any technical expertise on this stuff from me, but an observation that may have some use.

Beams in general cause me huge FPS problems, probably due to some of the reasons you guys are talking about. But for some reason, I have much less FPS hit with TBC's, at least the ones from CMOD. Not sure if they have much difference from vanilla, but the other beams are frame chugging monsters. Kyons, FBC's, PBC's, etc... are the ones that cause me the most grief. Maybe if they more represented the way the TBC works (except in their total damage of course) they'd cause less hitches?

Just my observation from my own games on my own system, perhaps it isn't the same for everyone else. For all I know TBC calculates and renders the same as all the other beams... although I do seem to notice it doesn't have as much 'glow.'

WRT Kyons, they are using older bullet models in CMOD/Vanilla which could be a factor with them (in AWRM I have given them a new model but in the CMOD patch for AWRM I defer to Paul's model choice for weapons that overlap).

WRT TBC v. FBC/PBC... TBCs have a fifth to a quarter of the bullet life which could be a factor. Maybe the CPU cost of maintaining a beam increases the longer the bullet life is (or perhaps it is the range - 4.6km v. >6km). CMOD G-KE have 9km range v. 4.8km in vanilla but have the same sub-TBC bullet life.

I presume the "glow" you are refering to is the post-trigger release persistence rather than a visual effect?

[builder680]

Nah, I mean glow on the beam itself along its model. TBC's seem to be a bit more flat, or matte... looking than the other beams. Similar to the difference you might see in a HEPT if you turned off post process filtering. Glow is the only word I can think of.

[Sam L.R. Griffiths]

Nah, I mean glow on the beam itself along its model. TBC's seem to be a bit more flat, or matte... looking than the other beams. Similar to the difference you might see in a HEPT if you turned off post process filtering. Glow is the only word I can think of.

Ok, kewl I thought that might of been the case

I believe the Glow affect is related to the materials used on the given bullets. If this has a significant effect on performance I would be slightly surprised, but it would be easy to test if it was to blame - just edit the model field for all beams to match the TBC entry

[builder680]

Just to add/clarify what I mean:

Here's a close up video of a single TBC in action.

Lots of 'color flashing' if you look at em up close... never noticed that before.

Anyway, you can see it's a bit less 'glowy' than other lasers, though it does have some glow. I have some short vids of 2 of the other beams (and a couple other weapons) linked over in the CMOD thread. The one showing Ion Cannons also has TBC's in the same video right alongside the IC's. Though those videos aren't as close-up as this video.

I wonder if those lasers do all this 'color flashing' within each beam as well. Not sure why they can't just be a solid color, even if it looks uglier, it would seem less of a strain, especially when you have a ship that shoots 20-40 of them at once.

[Sam L.R. Griffiths]

Lots of 'color flashing' if you look at em up close... never noticed that before.

The colour flashing is just the result of the applied material. CMOD TBC/PAL have similar models to Vanilla PBC (but with different colour textures), I do something similar in AWRM. Not sure that it affects performance though.

[TrixX]

That's just texture. The glow is dependent on the brightness of the texture and the alpha channel of it. Hence Ion Cannon's look very very glowy as they have a bright texture, the TBC has a darker texture.

[paulwheeler]

There are two very different models used for beams.

In CMOD - TBC, PALC and, I think, the Kyons use one type (The simpler of the two).

PBC, FBC and IC use the other type.

Maybe one gives better FPS performance than the other. Perhaps a moddling expert could take a look at them and see if there is a problem with the models used.

[Sam L.R. Griffiths]

There are two very different models used for beams.

In CMOD - TBC, PALC and, I think, the Kyons use one type (The simpler of the two).

PBC, FBC and IC use the other type.

Maybe one gives better FPS performance than the other. Perhaps a moddling expert could take a look at them and see if there is a problem with the models used.

Kyons in Vanilla use legacy X2 style models (and in CMOD last time I checked). TBC and PALC in CMOD use the Vanilla X3:TC PBC/PALC/FBC/TBC style model. In CMOD PBC, FBC, and IC appear to use a model from some other source.

[builder680]

I wasn't necessarily suggesting the glows themselves are causing the FPS to drop. Just saying those seem to be the ones that hurt the most. It may be they use some arcane damage calculation that causes the stuttering, whereas TBC uses different ones and doesn't cause stuttering. I don't know how they work, it may be completely unrelated to their glow, it just seems the worst offenders have that in common. Though IonD's also hit me pretty hard FPS wise (as do Kyons), and they don't have any glow I can see.

I feel like the stupid guy talking at a scienctists' convention or something. Just throwing my experiences out there to be made of what they can.

[paulwheeler]

Well I could try giving the Kyons the same model as the TBC/PALC etc. and see if it improves FPS.



EDIT - so far, so good. I've converted the Alpha, Beta and Gamma Kyons (in fact, I've managed to make them look much better!)

Looking at the CMOD IC/FBC/PBC model - this was also taken from X2 (By Ulfus I guess). I wonder if its these old X2 models that is the problem... Maybe I'll replace these as well.



EDIT2 - Well I've gone ahead and changed them all to use the X3 model. I don't know if its going to help fps yet, but it certainly looks better. This will all be included in the next CMOD release.