Energy weapon gameplay enhancement

[Pockets-byte]

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:

[bluey89962]

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?

[Pockets-byte]

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

[bluey89962]

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.

[Bokkiewokkie]

You shouldn't put the commas in these strings, but just in the text when they are displayed. I don't see any places where it is actually visible to a player right now anyway. It might also just be easier to make combo_target a list if you do want to display them somewhere.

Suggested change

	var/list/letters = list("delta,", "omega,", "phi,")
	var/list/letters = list("delta", "omega", "phi")

[Pockets-byte]

it was like that on ds13 too, and the way it's set up, it looks weird when examined. it also looks weird with the commas, but less so- it's been quite a while. but I don't know a lot about lists- it's displayed on the weapon it pertains to

[Pockets-byte]

it's displayed in the next file, /obj/machinery/ship_weapon/energy/examine(mob/user) . = ..() if(in_range(user, src) || isobserver(user)) . += "<span class='notice'>The heatsink display reads <b>[(heat)]</b> out of <b>[(max_heat)]</b>.</span>" if(maint_state != MSTATE_CLOSED) . += "<span class='warning'>[src]'s realignment sequence is: [combo_target].</span>"

[Pockets-byte]

I tinkered with trying to improve it, but I couldn't make it work without sticking to the original design

[Bokkiewokkie]

This looks terrible, why not use a for loop to continuously let people insert new things until they've added 5? (Or if they press "cancel" somewhere)

[Pockets-byte]

Some of this is repaired ds13 code. I don't exactly know how to recreate it or modify it. I think it was originally supposed to be timed
It's also supposed to fail as soon as you mess up an input
it was horrible to get functioning again

[Bokkiewokkie]

Note for a different PR: compile this into like a global list or just use a different system.
(nothing you have to worry about in your PR, you can add a comment about it if you want.)

[Pockets-byte]

this was originally a list from ds13, but the sounds were in a completely different place in nsv, and I figured nobody else would use this, so there's no reason to make a list- then again it makes it more readable and stuff

[Bokkiewokkie]

iirc we use these for console interactions as well, and you using it here proves that there may be more future use cases, so a list would be way easier

[DeltaFire15]

Preliminary.

Also maintenance on energy weapons should have a lockout var to prevent several users from interacting with one at the same time (or worse, one user several times at once).

[DeltaFire15]

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)

[Pockets-byte]

How do I actually do that? I tried to replicate the style of the other comments

[DeltaFire15]

The second half of my comment states what sort of syntax is (most commonly) used to autodoc.

[DeltaFire15]

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)

[DeltaFire15]

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.

[Pockets-byte]

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?

[DeltaFire15]

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.

[Pockets-byte]

That's true. Probably a much cleverer idea than just slamming in a minecart's worth of raw metal
It will need sprites tho

[DeltaFire15]

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.

[Pockets-byte]

I'd have to add a check for that in every part of the system though right? Would that be better

[DeltaFire15]

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.)

[DeltaFire15]

Can be on and also inactive which will print both messages that are somewhat contradictory. Missed an else if above?

[Pockets-byte]

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

[Pockets-byte]

despite this, should I add additional handling or re-phrase it?

[DeltaFire15]

Given it is currently present as the PR is testmerged, it would be useful if examine information was precise.

[Pockets-byte]

I'll see if I can add additional handling

[Pockets-byte]

this is basically all the existing states FOR the cooling machines, so I'm not sure that they can actually have additional handling?

[Pockets-byte]

Preliminary.

Also maintenance on energy weapons should have a lockout var to prevent several users from interacting with one at the same time (or worse, one user several times at once).

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

[DeltaFire15]

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

Variable on weapon that is set when someone starts an action on it and unset when it is either completed or failed. (being_maintained for example, or whatever).