[WIP]Energy weapon gameplay enhancement #2677
Conversation
hopefully will add another set of limbs to the augmentor once I finish converting the sprites
mostly from paradise, I made the veymed ones from nsv sprites
gotta cherry pick this out
Pockets-byte
changed the title
Pockets-byte
changed the title
|
Question: would this also come with adding muni tech as a job to the whisp or would someone else (ie engineers/MAA/whoever the captain assigns) be responsible for this? |
this most likely will come with muni jobs on the wisp, yes- these changes will make single-manning the wisp much harder- but probably not impossible |
I obviously don't know exactly how this system will work but in that case it might be good to restrict the amount of tecchies that we it can have because I expect we will many see cases where lots of people sign up for it since they see it as "the necessary job for NSV" (which it is on basically all ships) but no one goes for engineering, which is absolutely more essencial for the functioning of the whisp. Of course it's all WIP and everything but I just thought I'd throw in my 2 cents considering the lack of engineers is a common issue for the map and it's a reason that people usually bring up as to why they dislike it. |
| charge_per_shot = 660000 //How much power per shot do we have to use? | ||
| var/max_charge = 3300000 //5 shots before it has to recharge. | ||
| var/power_modifier = 0 //Power youre inputting into this thing. | ||
| var/power_modifier_cap = 3 //Which means that your guns are spitting bursts that do 60 damage. | ||
| var/energy_weapon_type = /datum/ship_weapon/burst_phaser | ||
| var/static_charge = FALSE //Controls whether power and energy cost scale with power modifier. True = no scaling | ||
| var/alignment = 100 //stolen from railguns and the plasma gun |
There was a problem hiding this comment.
All your new variables should be autodoc documented for ease of use (via ///[comment] in the line before or //![comment] in the same line as the var)
There was a problem hiding this comment.
How do I actually do that? I tried to replicate the style of the other comments
There was a problem hiding this comment.
The second half of my comment states what sort of syntax is (most commonly) used to autodoc.
| obj_integrity = 1200 | ||
| heat_per_shot = 100 | ||
| var/max_freq = 100 | ||
| var/combo_target = "omega" //Randomized sequence for the recalibration minigame. |
There was a problem hiding this comment.
I agree with bokkie in that this should be handled via a list, and you did want an easier way to immediately fail when one is entered incorrectly (which that is unless you do REGEX shenanegans.)
This would also mean you could just omit the entire combo var since you'd only need to check if the entered letter matches the one at the current position in the cypher (otherwise you just autofail as you intented to)
| req_components = list( | ||
| /obj/item/stack/cable_coil = 30, | ||
| /obj/item/stock_parts/matter_bin = 4, | ||
| /obj/item/stack/sheet/mineral/copper = 30, |
There was a problem hiding this comment.
Please don't use this level of "true" sheet use for any machinery. It makes them loot pinatas if mapspawned and also is in itself a bit hillarious.
There was a problem hiding this comment.
I do think it makes sense for a heat related machine, and unless you don't want functional weapons, you can't scrap them, then again.
I don't want them to be super cheap though, should I make the boards more expensive in that case?
There was a problem hiding this comment.
You could use custom components which are expensive to print, for example; This makes them somewhat harder to efficiently cannibalize (and adds a layer of ambiguosity), over just ejecting & slamming in a stack of 30 copper.
There was a problem hiding this comment.
That's true. Probably a much cleverer idea than just slamming in a minecart's worth of raw metal
It will need sprites tho
| /obj/machinery/ship_weapon/energy/beam/bsa/after_fire() //NT gets to cheat and have no degadation or heating on their weapon because muni has enough to do and the BSA doesn't need buffs/nerfs | ||
| . = ..() | ||
| heat = 0 | ||
| alignment = 100 | ||
| freq = 100 |
There was a problem hiding this comment.
Bit hacky.
Potentially use a var to determine if the weapon uses a maintenance system and lock out maintenance need generation- aswell as resolving actions if not yes.
There was a problem hiding this comment.
I'd have to add a check for that in every part of the system though right? Would that be better
There was a problem hiding this comment.
It's the classic "address now vs. address later" issue.
For now it's probably fine with a single energy weapon that works this way, but if more appear, it may get a bit less convenient.
(Besides the fact you can do all the related maintenance steps on the BSA with this most likely despite them having no effect, and even get the examine talking about these things.)
nsv13/code/modules/munitions/ship_weapons/energy_weapons/subspacecooling.dm
Outdated
Show resolved
Hide resolved
nsv13/code/modules/munitions/ship_weapons/energy_weapons/subspacecooling.dm
Outdated
Show resolved
Hide resolved
| else | ||
| . += "it's completely inactive" |
There was a problem hiding this comment.
Can be on and also inactive which will print both messages that are somewhat contradictory. Missed an else if above?
There was a problem hiding this comment.
These are mostly debug messages, so printing both is still helpful even if confusing
It's mostly inactive appears when it's not cooling I believe
There was a problem hiding this comment.
despite this, should I add additional handling or re-phrase it?
There was a problem hiding this comment.
Given it is currently present as the PR is testmerged, it would be useful if examine information was precise.
There was a problem hiding this comment.
I'll see if I can add additional handling
There was a problem hiding this comment.
this is basically all the existing states FOR the cooling machines, so I'm not sure that they can actually have additional handling?
nsv13/code/modules/munitions/ship_weapons/energy_weapons/subspacecooling.dm
Show resolved
Hide resolved
nsv13/code/modules/munitions/ship_weapons/energy_weapons/subspacecooling.dm
Outdated
Show resolved
Hide resolved
Co-authored-by: DeltaFire <[email protected]>
How do I actually do that? Just like a var that's set while someone's doing something? I should take a look at how the other weapons do it |
Co-authored-by: DeltaFire <[email protected]>
Variable on weapon that is set when someone starts an action on it and unset when it is either completed or failed. ( |
more examine states
…r.dm Co-authored-by: DeltaFire <[email protected]>
There was a problem hiding this comment.
Mapping wise, I would rather you either expand the rooms to actually have the associated machines next to their respective lasers, or move things around so it is generally consistent where they all are (specifically noticing the heat sinks being all over the place)
|
UnTMing for now, I hope the testing ingame so far has been helpful |
…yte/NSV13 into energy-weapon-gameplay
Pockets-byte
changed the title
About The Pull Request
this is an attempt to make energy weapons more reasonable for muni players by bringing them several more statistics that need to be managed, and one entire minigame definitely not borrowed from ds13
energy weapons degrade and lose effectiveness the more they're used, and muni needs to be on their toes to keep them functional and not exploding in your face.
Why It's Good For The Game
muni gameplay on the wisp real.
there are three new stats to keep track of, weapon heat, weapon lens alignment, and weapon frequency alignment - should any of these reach their worst state, ::fun:: things happen, including weapon explosions, shutdowns, in-ship laser fire, and dangerous steam venting.
Testing Photographs and Procedure
Screenshots&Videos
Changelog
🆑
add: Added several stats to keep track of to energy weapons
add: Added a minigame from ds13
balance:some rebalanced energy weapons to make up for required downtimes and more measured use
/:cl: