66ee0b4eb7590

66ee0b4eb7e5b
1 Guest is here.
 

Topic: SS2 Rebalanced Skills and Disciplines
Page: « 1 ... 14 [15]
Read 73211 times  

66ee0b4eb862cRoSoDude

66ee0b4eb8691
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.
Acknowledged by 2 members: sarge945, Join2
66ee0b4eb8940
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?
« Last Edit: 29. April 2024, 04:28:55 by Join2 »

66ee0b4eb8e77ZylonBane

66ee0b4eb8ecd
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.
Acknowledged by: Join2

66ee0b4eb8ffbZylonBane

66ee0b4eb9048
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);
}
}
}
Acknowledged by: RoSoDude

66ee0b4eb92a4sarge945

66ee0b4eb92fa
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.

66ee0b4eb9410voodoo47

66ee0b4eb945d
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.

66ee0b4eb9548ZylonBane

66ee0b4eb9593
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.

66ee0b4eb964aRoSoDude

66ee0b4eb9695
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.

66ee0b4eb9d77ZylonBane

66ee0b4eb9dcd
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.

66ee0b4eb9ebdRoSoDude

66ee0b4eb9f0b
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.

66ee0b4ebc330ZylonBane

66ee0b4ebc38d
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.
Acknowledged by: RoSoDude
66ee0b4ebc46d
could you just pop out a headshots dml mod for everyone on the mods page?

66ee0b4ebc58bZylonBane

66ee0b4ebc5d7
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.
« Last Edit: 08. September 2024, 23:19:08 by ZylonBane »

66ee0b4ebc714RoSoDude

66ee0b4ebc762
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.

66ee0b4ebc8b4CyrusVonNox2001

66ee0b4ebc906
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.

66ee0b4ebc9e9RoSoDude

66ee0b4ebca37
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.

66ee0b4ebcaefZylonBane

66ee0b4ebcb3b
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.

66ee0b4ebcbc3RoSoDude

66ee0b4ebcc0e
I'll definitely look into that.

Your name:
This box must be left blank:

Name the company that developed System Shock 2:
1 Guest is here.
i'll let you know when i do something of value.
Contact SMF 2.0.19 | SMF © 2016, Simple Machines | Terms and Policies
FEEP
66ee0b4ebd2c2