677c421553eb1

677c42155565f
3 Guests are here.
 

677c421555f86eldrone

677c421555fd7
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.

677c42155622asarge945

677c42155627a
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)

677c4215565adeldrone

677c421556628
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.

677c42155678beldrone

677c4215567eb
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]

677c4215569d6ZylonBane

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

677c421556deesarge945

677c421556e47
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.

677c421556f55eldrone

677c421556faa
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.

677c4215571b8ZylonBane

677c42155720d
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?

677c421557436sarge945

677c42155748b
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.

677c4215576d1Xkilljoy98

  • Company: N/A
677c42155772e
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.

677c421557972ZylonBane

677c4215579cc
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.

Your name:
This box must be left blank:

A familiar passcode with 3 digits:
3 Guests are here.
Long winding road you got a secret but you won't share it
Contact SMF 2.0.19 | SMF © 2016, Simple Machines | Terms and Policies
FEEP
677c421558b29