System Shock 2: Enhanced Edition Update & Community Participation

[679c0eaa43fb7voodoo47]

not gonna run on a Voodoo3 though.

[679c0eaa4412bicemann]

Ba dum dush.

[679c0eaa44329eldrone]

So, I've been working a bit on various squirrel side tools and systems:

There will be a new general player script where you can register handlers, essentially eliminating the need for future player scripts:

You essentially create a handler class, register it with the player, and it can grab any information it needs as well as subscribe to all kinds of messages related to the player, including frame updated, and a more solid way to know when the game is actually ready.

As an experiment I've made a simple debug handler that parses the entire pool of objects every frame and just draws information about them on screen at their location and any link connections and it just works.


On top of that there will be archetype creation available straight in squirrel so one could unify an entire new object in one single .nut

With those archetype tools templates can also easily be created so you can have very simple archetype creation.


But also: reaching the script instances of various objects should be fairly easy now.

[679c0eaa44607sarge945]

Does it have the ability to block vanilla event handlers?

So for instance, if casting a PSI power sends a message to the player to, say, increase their armour, would we be able to intercept this and say "ACKCHAULLY, don't do that at all"

Defining new archetypes in Squirrel could be interesting, but DML should still be good enough for most purposes (except for creating objects with physics - so I hope that's fixed)

[679c0eaa4492celdrone]

Does it have the ability to block vanilla event handlers?

So for instance, if casting a PSI power sends a message to the player to, say, increase their armour, would we be able to intercept this and say "ACKCHAULLY, don't do that at all"

Defining new archetypes in Squirrel could be interesting, but DML should still be good enough for most purposes (except for creating objects with physics - so I hope that's fixed)

That's an interesting scenario, I'll look at this, but I believe it should be.

Do mention any dbmod issues, if there's any I want to make sure we fix them, including better ways to add or change scripts and args.

Dml's are still preferable for directly altering vanilla game stuff or mission content.


I have brought up the possibility of having dml's only apply to the gamesys below it in priority order, just to stop that thing where vanilla dml patches has to be told to not apply to scp, so want to check what people's opinion is on that one.

[679c0eaa44a7beldrone]

oh and, going along with squirrel tools, here's a work in progress debug mode property inspector:

(and yes, every faint dot there in the background is an object)


I'm also going to see if I can add some ability to modify/add/remove properties in realtime for testing purposes.
[prop_inspector.jpg expired]

[679c0eaa44bd8ZylonBane]

It would be nice if a script API existed for accessing gamesys variables, like OS upgrade multipliers, main elevator destinations, etc.

[679c0eaa44edcsarge945]

Do mention any dbmod issues, if there's any I want to make sure we fix them, including better ways to add or change scripts and args.

I've linked it before, but you should try to implement as much as you can from my DML Wishlist to really make modders lives as easy as possible. It outlines a lot of issues that currently exist with DML.

Probably the most important ones to me are a squirrel API for creating brand new properties on objects, which will be properly kept on saving, transitioning maps, etc, and proper support for physics objects.

Currently, in the Coloured Laser Rapiers mod, I have to store the colour variable in the DoorCloseSound property because squirrel's GetData/SetData don't work through map transitions. This is hacky and awful and I wish I could use a custom property, something like RapierColour.

[679c0eaa45030eldrone]

I have to check these things, because I know that during the reverse engineering a bunch of things got fixed by default.


As a default archetype additions can never be saved during gameplay, but as a default the archetype edits in squirrel gets applied at the start of every mission load.

Applying property edits to live objects should always be permanent and saved.

[679c0eaa4527eZylonBane]

Currently, in the Coloured Laser Rapiers mod, I have to store the colour variable in the DoorCloseSound property

Isn't the color already "stored" in the object model and icon properties? Why store it again?

[679c0eaa454cbsarge945]

Isn't the color already "stored" in the object model and icon properties? Why store it again?

That won't work because some rapiers can be the default blue ones and I need to know if they are blue because they rolled blue or because they haven't been updated yet.

I could probably get away with not storing it, using some other method like sticking a metaprop on it, but it seemed like the least hacky option at the time.

[679c0eaa45858Xkilljoy98]

Are there any updates on this game btw? Not sure what would be keeping it or why they hadn't really said much. I guess if nothing else then "when it's done" is better than constantly moving the release window like they did with the SS1 Remake.

[679c0eaa45b0cZylonBane]

That won't work because some rapiers can be the default blue ones and I need to know if they are blue because they rolled blue or because they haven't been updated yet.

Just use Property.PossessedSimple() to check for non-inherited properties.

[679c0eaa45e1eeldrone]

System Shock 2 already has an extensive system for modifying all of the difficulty settings you mention. It just requires a text editor and knowledge of dml.

It's probably better for them to focus their efforts on things that aren't currently fixable by the community (like the multiplayer, etc) than to implement things the community can already do.

On that note

I would be eternally grateful if the squirrel services were updated to add functions to enable and disable manually saving the game with both the menu and quick save keys, disable or enable autosaves, and a function was added to create a quick save or autosave via script. Finally my "QBRs are actually gave points" mod idea can come to fruition

You know what, there's some new save and post save messages right now and while I haven't tested it, it should add the ability to essentially "break" a save unless script conditions are met.

This should theoretically enable ironman mode.

[679c0eaa45f6feldrone]

Just gonna leave a reminder here about the ss2ee contributor beta test:

https://www.systemshock.org/index.php?topic=12971.0

[679c0eaa4654asarge945]

You know what, there's some new save and post save messages right now and while I haven't tested it, it should add the ability to essentially "break" a save unless script conditions are met.

This should theoretically enable ironman mode.

This is a good step in the right direction, but for a mod like this to be really viable, it needs to disable saving in a clean way. Simply breaking people's savegames is a really obnoxious and janky way to approach the problem, and while it might be fine for a personal mod, I wouldn't be comfortable releasing a mod that does this.

[679c0eaa46670ZylonBane]

Something actually useful would be the ability for scripts to trigger autosaves. Would allow mods that save at regular intervals, or that save at significant progress points.

[679c0eaa46e14sarge945]

Something actually useful would be the ability for scripts to trigger autosaves. Would allow mods that save at regular intervals, or that save at significant progress points.

Yeah I suggested the same thing. A saferoom/save point mod would require a script function to disable saving altogether (which would also disable autosaving), and a function to trigger an autosave.

A function to create a custom named save would be nice, but SS2 uses a save slot system, so I'm not sure that would be a good idea, given it might clobber important existing saves.