SS2 Rebalanced Skills and Disciplines

[6741901b29717RoSoDude]

I prefer worm piles to not be destructible at all, they're supposed to be floor hazards and allowing the player to wrench them to death is the definition of boring degenerate gameplay. I allowed fire and anti-annelid damage to kill them as a compromise, essentially just for random scenarios where a grenade, fusion blast, or exotic weapon explosion happens to include a worm pile in its radius. I don't anticipate players will bother spending resources to kill them, it's just a minor concession to AoE weapons.

[6741901b29a33Join2]

Agreed. Destroyed only by high value resources or invulnerable are the two sensible options. Destroyed by anything is the realistic, yet silly method.

Realism brain worms is a blight. Abstraction as it pertains to game design is a lost art of the glorious 1990s.

Let me highlight why with the following example: realism's end goal here is they are a not a hazard at all because they'd just squish immediately when stepped on by this 180lbs (or whatever) man. It is clearly explained the worms are in their infancy, and you can see when you look at the piles they're too small to do any damage puncturing future space marine footwear, nor withstand such weight when stepped on. So, realism's end goal is therefore they are nothing of consequence unless you take your boots off and run around the ship barefooted, or your footwear are otherwise compromised perhaps.
Realism for realism's sake is often antithetical to game design, even when the intentions are good e.g immersion, sense of freedom as is the case here. Irrational had it right by making them hazards that cannot easily be removed, simply do chip damage when stepped on instead of attaching to your foot and needing surgical removal, and yet were just straddling the line of believability for the player to not stop and question it. The only questionable part of their design here is encouraging players to get on their hands and knees with beakers collecting them all to use a gun that isn't particularly satisfying and requires significant investment. But I get their thinking. The idea is novel and cool, and could have been good. Just did not have the best execution.

That's a point too, keeping them indestructable preserves worm ammo counts for new players whom have no idea about any proliferator worm gun thing until much later. Are you sure you thought this through Zylon?

[6741901b2a1a2ZylonBane]

I prefer worm piles to not be destructible at all

They're already destructible even in vanilla. With a WormBlood implant you can destroy them with your teeth.

allowing the player to wrench them to death is the definition of boring

You might want to actually try that and see what happens.

keeping them indestructable preserves worm ammo counts for new players whom have no idea about any proliferator worm gun thing until much later.

Destroyed worm piles regenerate after five minutes.

[6741901b2a343ZylonBane]

Just a heads up that in Beta 6, SCP will be fixing the Soma Drain psi power so it can't heal the player for more HP than the target actually has. It will also fix the drain FX object only appearing on Creature type targets (the vanilla script never teleports it to the target location).

Since healing the player will be handled by the SomaDrain script, the DrainStim receptron that heals the player will be disabled by setting its effect multiplier to 0.

Code: [Select]

class SomaDrain extends RootPsi {
function ActivatePsi() {
base.ActivatePsi();
doDrain();
DeactivatePsi();
}

function doDrain() {
local mod, drain, heal;
local obj = ShockGame.GetDistantSelectedObj();
if (obj && Link.AnyExist("StimSensor", obj, "DrainStim")) {
drain = GetData("Data1");
mod = GetData("PsiStat") - GetData("Data3");
if (mod > 0) {
drain += mod * GetData("Data2");
}
heal = scp.Clamp(drain, 0, Property.Get(obj, "HitPoints"));
ActReact.Stimulate(obj, "DrainStim", drain, "Player");
ShockGame.HealObj("Player", heal);
createFX(obj);
}
}

function createFX(obj) {
local fx = scp.CreateAt("Soma Drain FX", obj);
if (Property.Possessed(obj, "Creature")) {
local lnk = Link.Create("ParticleAttachement", fx, obj);
LinkTools.LinkSetData(lnk, "Type", 2);
LinkTools.LinkSetData(lnk, "Joint", 3);
}
}
}

[6741901b2a677sarge945]

It's probably worth mentioning in the OP that the mod doesn't work with the hard security minimod for scp5, to avoid threads like these.

You might want to check the other minimods as well, and recommend people use alarming cameras instead of hard security. Or just change your objects script slot to make it compatible.

People might (rightly) think that "SCP beta 5" support actually means "SCP 5 beta (and all official optional components) support", which is a reasonable assumption.

[6741901b2a7ecvoodoo47]

generally speaking, if a mod that tweaks game mechanics makes changes in a certain area, it's very much not recommended to load more mods that touch the same area.

[6741901b2a93eZylonBane]

It looks like the only reason this clobbers the SCP security computer script is "so Security Expert trait doubles timeout duration".

But that (probably) could have been accomplished with just an additional script that sits on top of whatever security computer script is running and injects the adjusted hack time. Something like this:

Code: [Select]

function OnFrobWorldBegin() {
if (!IsDataSet("HackTimeOrig")) {
SetData("HackTimeOrig", GetProperty("HackTime"));
}
SetProperty("HackTime", GetData("HackTimeOrig") * (ShockGame.HasTrait("Player", eTrait.kTraitSecurity) ? 2 : 1));
}Not tested, this is just off the top of my head.

[6741901b2aa5bRoSoDude]

I guess that's a safe method of achieving the same effect. I was just trying to get the minimal SCP compatibility stuff out of the way, and I just flagged the hard security minimod incompatibility for later. Beta release and all.

I can get it cleaned up in the next version.

[6741901b2b2f7ZylonBane]

Responding to your post in the other thread...

3b. The security countdown displaying on top of the hacking window is a nearly unavoidable issue in RSD, as I reimplemented the hacking minigame in a custom overlay, but custom overlays display behind native overlays. I tried a bunch of elaborate hack fixes to address this by disabling and re-enabling the windows when certain conditions were met, but it led to buggy alarm behavior so I ultimately gave up on it.

I'm curious what sort of bugs you encountered. I just tried this, and it seemed to work fine:

On overlay open

Code: [Select]

if (ShockGame.OverlayOn(kOverlayAlarm)) {
ShockGame.OverlayChange(kOverlayAlarm, kOverlayModeOff);
}On overlay close

Code: [Select]

if (ShockGame.IsAlarmActive()) {
ShockGame.OverlayChange(kOverlayAlarm, kOverlayModeOn);
}Though of course you'd want to throw in a check of the HUD resolution to see if it's even necessary to hide it.

[6741901b2b45fRoSoDude]

It was probably a question of how/when I was checking for conflicts with the native alarm overlay, but my problem was that I would get alarms (or maybe security hacks, I don't recall which) endlessly looping. That was when I checked per overlay update, which would obviously not be my preference as far as performant code goes. I'm sure I must have tried doing the check on custom overlay open/close which must have had some other problem...?

Anyway, maybe I'll take another stab at it.

[6741901b2dc0eTheHEX]

RoSoDude
hi id like to send you to this post and ask for help?

https://www.systemshock.org/index.php?topic=12655.new#new

thanks

[6741901b2dda7ZylonBane]

Heads up that in SCP Beta 6, the hack text for the SHODAN shield interlock computers will be updated to reflect their altered effect. So you'll need to set HackText on CPU1/2/3 back to Shield_Interlock.

[6741901b2deddTheHEX]

could you just pop out a headshots dml mod for everyone on the mods page?

[6741901b2e0baZylonBane]

Yo RoSo, in your custom panel code, I'm curious how you integrated them into the native overlay system with regards to deconflicting with the other panels, automatically closing when use mode toggled, etc. I've been playing around with modding a panel replacement, and so far it seems like the only way to do this is brute force, i.e., on open deactivate every overlay that could overlap, then in the draw handler check for any of those overlays being opened. So I'm hoping you'd discovered a more elegant approach.

Edit: Well I've managed to resolve most of these issues, but still stuck on how to detect when the player has opened another MFD while my MFD is open. Looping through 23 overlays to check their visibility every single draw call seems less than ideal.

Edit2: Duh, CanEnableElement() was exactly what I was looking for.

[6741901b2e257RoSoDude]

Yeah, I have extensive checks in CanEnableElement() to ensure my custom overlays operate as they should. Most of it is just disabling native overlay elements where I want to insert my own, but it's also how I display stat/skill requirements on "?" and how I handled the Security Expert O/S applying to minimum requirements, among other things. In fact, the only way I was able to get my custom HRM minigame panel to know which object was being targeted was by letting the native window open for one frame.

I also have a hacky system for the custom overlay handler to send messages to scripts (my "message hacker" archetype) and for scripts to check the state and request updates of custom overlays (my "overlay oracle" object), since there is no default solution for communication between scripts and custom overlays.

[6741901b2e3f1CyrusVonNox2001]

Is this currently compatible with SCP Beta 6? I remember playing around with it with Beta 5 and noticing a glitch with the UI where the Security System countdown would bleed through the UI in-game. I was also wondering when the scary monsters AI upgrade would be updated to be compatible with Beta 6 as well.

[6741901b2e555RoSoDude]

I think Scary Monsters AI is already compatible.

SS2-RSD needs an update to fix some minor discrepancies with SCPb6. I already logged all of the issues and started resolving them but I don't have it ready for upload quite yet.

The security system countdown issue is known from earlier versions and I was not able to fix it before; however, ZylonBane did suggest a fix that I don't recall if I tried, so I'll give that a shot for the next version.

[6741901b2e675ZylonBane]

I tried SCP6 with SS2-RSD_2.03 and noticed that player flooring on level start wasn't working anymore, so it's definitely clobbering some functionality of SCP's player script.

[6741901b2e75fRoSoDude]

I'll definitely look into that.