System Shock 2: Enhanced Edition Update & Community Participation

[6779bd7ea8562voodoo47]

not gonna run on a Voodoo3 though.

[6779bd7ea8737icemann]

Ba dum dush.

[6779bd7ea8a91eldrone]

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.

[6779bd7ea8f25sarge945]

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)

[6779bd7ea9314eldrone]

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.

[6779bd7ea9482eldrone]

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]

[6779bd7ea9624ZylonBane]

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

[6779bd7ea9a1fsarge945]

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.

[6779bd7ea9ba7eldrone]

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.

[6779bd7ea9e18ZylonBane]

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?

[6779bd7eaa0d4sarge945]

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.

[6779bd7eaa42dXkilljoy98]

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.

[6779bd7eaa6dbZylonBane]

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.