Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Obsidian Actual]

(Moved as separate topic as per Alex's request)

So I'm mucking around with a built-in beam weapon that works like your typical TacLaser; it's a sustained beam with only chargeup & chargedown values, but null for burst size & burst delay (meaning that it fires without stuttering as long as LMB is held down).

A ship system (based off Tartiflette's DiableAvionics Versant transformation) is supposed to, when toggled on, lock out the beam weapon from firing. The original code made use of setRemainingCooldownTo(1) every frame to constantly keep the weapon on cooldown, which I assumed relates to a weapon's chargedown value... but apparently that only applies to projectile weapons, not beam weapons.

I'd rather not have to use disable() and repair(), as those methods work like weapon malfunctions (and thus render horrible smoke particles & sparks).

Any ideas?

[Alex]

Possible approach, not sure if it'll work: have the weapon use ammo (with a very large capacity, above 10k or whatever), and have the system temporarily set the ammo to 0?

[Obsidian Actual]

I've tried different values in the [ammo] column of the csv (ranging from 10 to 99,999), but when the sustained beam is fired, no ammunition is expended (the count does not go down?). Is it even possible to create a sustained beam weapon that consumes charges at a per-tick rate to begin with?

Also, tried playing with setAmmo(0) and resetAmmo() methods. They change the ammo count as expected when I toggle the ship system, but the sustained beam weapon can still fire regardless of ammo level. (Yeah, it's still chugging away even when its status is faded out and reading "0" in the ammo count).

Maybe I don't have the base weapon set up correctly (.csv or .wpn)? Again, I only have chargeup & chargedown values in the csv, but no burst size or burst delay.

[Alex]

Ah, it probably doesn't do anything with sustained beams; that's the part I was not sure about off the top of my head. Hmm... if I think of something else, I'll chime in; nothing comes to mind right now.

[Obsidian Actual]

All good, I appreciate the suggestions you've given so far (including the WeaponGroupAPI approach).

[Wyvern]

Hm... Not sure if this would work (or generate the visual effect you want even if it does), but if you put charge-up and charge-down to zero, you should be able to make a "burst" beam that fires continuously with no delay between "bursts".  At which point the ammo solution should do the job.

[Obsidian Actual]

Hm... Not sure if this would work (or generate the visual effect you want even if it does), but if you put charge-up and charge-down to zero, you should be able to make a "burst" beam that fires continuously with no delay between "bursts".  At which point the ammo solution should do the job.

Zeroed out the chargeup/chargedown as you suggested, but ammo was still not being consumed... until I added back in non-zero values to burst size & burst delay. Seems like you really must have those two in order to define a "burst" that consumes one unit of ammo.

A pity, since my goal was to create a sustained beam in the first place. Even lowering the burst delay value to something like 0.01 causes stuttering, which not only messes with the visual & audio effect (minor issue at best), but also disrupts some other everyWeaponFrameEffect code I had in place for the beam's secondary damage effects.

Maybe ammo isn't the way to go after all 

[Wyvern]

Aww.  I mean, you'd definitely need a non-zero burst size, but I'd have expected a burst delay of zero to be functional.  Oh well, worth a try.

[Thaago]

This is a bit off the wall, but could you remove the weapon from the weapon groups when the system is active? That way there is not way to fire it for the player or the AI.

[Obsidian Actual]

This is a bit off the wall, but could you remove the weapon from the weapon groups when the system is active? That way there is not way to fire it for the player or the AI.

Cheers Thaago. Yeah, it was one of Alex's first suggestions as well. Still WIP on account of me being a bit slow.

The good news is that ShipAPI has the removeWeaponFromGroups(WeaponAPI weapon) method, which is simple enough to call without even having to loop through a search for the weapon group.

Only remaining challenge is to somehow get the script to "remember" which group the removed weapon belonged to; might have to use getWeaponGroupFor(WeaponAPI weapon). I'll also have to check if WeaponGroupAPI's addWeaponAPI(WeaponAPI weapon) will restore things properly upon toggling off the ship system (...and when combat ends? It'd probably be a pain for the player to have to reassign their weapon groups if the CombatEngine exits when the system is still on...)

Welp, I'll report back my findings after a bit more testing.

[Obsidian Actual]

Halfway done! Just got to figure out what's causing the java.lang.NullPointerException CTD...

Code

package data.scripts.weapons;

import com.fs.starfarer.api.Global;
import com.fs.starfarer.api.combat.CombatEngineAPI;
import com.fs.starfarer.api.combat.EveryFrameWeaponEffectPlugin;
import com.fs.starfarer.api.combat.ShipAPI;
import com.fs.starfarer.api.combat.ShipEngineControllerAPI;
import com.fs.starfarer.api.combat.ShipSystemAPI;
import com.fs.starfarer.api.combat.WeaponAPI;
import com.fs.starfarer.api.combat.WeaponGroupAPI;

public class Diableavionics_HarvestEveryFrameEffect implements EveryFrameWeaponEffectPlugin {
	
	private ShipAPI ship;   
	private ShipSystemAPI system;
	private ShipEngineControllerAPI engines;
	private WeaponGroupAPI weaponGroup;
	
	private boolean runOnce=false;
	private boolean weaponRestored=true;
	
	@Override
	public void advance(float amount, CombatEngineAPI engine, WeaponAPI weapon) {
		
		if (Global.getCombatEngine().isPaused()) {
			return;
		}
		
		//initialise the variables
		if (!runOnce || ship == null || system == null){
			ship = weapon.getShip();
			system = ship.getSystem();
			engines = ship.getEngineController();
			weaponGroup = ship.getWeaponGroupFor(weapon);
					  
			runOnce = true;
			
			//return to avoid a null error on the ship
			return;
		}
		
		if (ship.getSystem().isActive()) {
			ship.removeWeaponFromGroups(weapon);
			weaponRestored=false;
		} else {
			if (!weaponRestored) {
				weaponGroup.addWeaponAPI(weapon);
				weaponRestored=true;
			}
		}

		if (ship.isHulk() && !weapon.isDisabled()) {
			weapon.disable();
		}
		
	}
	
}

To elaborate, the removeWeaponFromGroups(WeaponAPI weapon) method worked flawlessly. Once the ship system activated, my beam weapon vanished from the weapon group widget (i.e. no more beam firing).

The java.lang.NullPointerException CTD occurs the moment I call the weaponGroup.addWeaponAPI(weapon) method. I have code in place to only call this method when the ship system is deactivated from an active state (thanks to the weaponRestored boolean), to prevent the CombatEngine from constantly trying to add the weapon back into the group when it's... well, already in the group.

Hmm. Am I using the addWeaponAPI(weapon) method incorrectly?

[Tartiflette]

I tried the weapon group method for the same goal and I never managed to make it work. You can remove the weapon without issue but adding it back is just not hapenning.

[Obsidian Actual]

I tried the weapon group method for the same goal and I never managed to make it work. You can remove the weapon without issue but adding it back is just not hapenning.

After some sidetracked experimentation, I believe I have also reached the same conclusion.

Interestingly, I have observed that if a weapon of any kind is in a Weapon Group of its own (e.g. a single Tactical Laser in Group 3), running the removeWeaponFromGroups(WeaponAPI weapon) method on it will blank out the entire Weapon Group. Afterwards, it also seems that I have no means of grabbing the respective WeaponAPI or WeaponGroupAPI instances either.

==========

What I would give to have a ShipAPI method along the lines of resetWeaponGroups().

Oh well, guess I'm going back to projectile weapons and the setRemainingCooldownTo() method then.

[Nicke535]

Look at the Sylphon's Tarima shipsystem. It works as long as the built-in weapons are of a different weapon type compared to the rest of the weapons; it involves some *** with cooldowns combined with increasing beam flux cost to 999999 times its normal value, prohibiting it from firing for even a single frame and thus not being able to charge up at all.

[Obsidian Actual]

Look at the Sylphon's Tarima shipsystem. It works as long as the built-in weapons are of a different weapon type compared to the rest of the weapons; it involves some *** with cooldowns combined with increasing beam flux cost to 999999 times its normal value, prohibiting it from firing for even a single frame and thus not being able to charge up at all.

Oh, that's clever. MutableShipStatsAPI methods to increase energy weapon flux cost immensely (along with neutering their RoF multiplier too just in case) to the point where CombatEngine's "fire control" refuses to trigger them.

Would require some clever juggling with how I restrict the ship's weapon loadouts... but without any setFluxCostToFire() methods in WeaponAPI at the moment, your suggestion seems to be as good as it gets for beam weapons.

Hmm...