Schall Recharging Weapon

Experimental recharge mechanism. Introduced energy weapons, which recharge from personal batteries! Currently includes laser rifle, laser sniper rifle, laser shotgun, laser machine gun, mega laser cannon, chainsaw. (Locale: English, Deutsch, 正體中文, 简体中文, Português Brasileiro, Русский)

3 months ago
0.17 - 0.18

g [Responded] Design Question Regarding Energy

1 year, 1 month ago

Hi Schall, I love your mods and will probably be playing with more than half of them from now on. Quick question: I see in ammo.lua that you originally had a magazine size of 1. Why did you change it? I guess what I really want to know is why you store charges in the gun at all, instead of just drawing energy every shot from the equipped batteries?

1 year, 1 month ago
(updated 1 year, 1 month ago)

Short answer: balance between realism and performance (UPS).

Now let me explain in detail.
Yes, it would be ideal in realism, since the weapon needs not store energy but just take directly from grid system.
BUT, in game update mechanism, I used mainly event "on_player_ammo_inventory_changed" to do the charging, which triggers when the amount of magazines of player ammo slot changes. This means if magazine size is set to one, the charging call would be made EVERY shot! Each charging call has to scan for every equipment item on grid and try to take energy from it. This takes some update time.
It may not be apparent if you play singleplayer only and play on a powerful computer. But on multiplayer servers, when multiple players are fighting at the same time and with high fire rate weapons (e.g., chainsaw, laser machine gun), the update time MULTIPLIES, potentially causing performance hit like laggy and choppy gameplay.
Having a magazine size means the update is called only when the whole magazine is consumed. Magazine size of 25 (chainsaw) means the charging calls consume only 1/25 of original update time. I scaled the magazine size with the fully-upgraded fire rate, to roughly an update every 1 second (instead of every 0.04 seconds...)
So I guess it is a good compromise?

PS: Some similar mod used event "on_tick" instead for this kind of update. But I am never a fan of using on_tick event. Using this means the mod is keep consuming some update time, even if no one is fighting. (I guess fighting takes less than 10% of total play time for most players?) Thus, using on_tick is not as effective IMO, and makes the script unnecessary complex (i.e., bug-prone) to distribute the calculations to multiple ticks in case of multiple players.

New response