oopsk by Sovde 
basic object oriented programming concepts for Skript
Events
0
Expressions
2
Effects
0
Conditions
1
Types
1
Sections
0
Structures
1
Total
5
oopsk by Sovde
oopsk 1.0 beta 2 release 193 days, 19 hours and 6 minutes ago
beta 2
Beta 2 introduces some very interesting features, namely concrete types and custom converters. These crack open the very heart of Skript's internals, so I'm rather tentative about declaring them stable. They should be treated with care. I want to double down on the advice that you should always reload all scripts after editing a struct template. This is even more important with the registration of types and converters, now. If you are encountering weird behavior, reload all and see if it still occurs.
concrete types:
struct alpha:
b: bravo struct
c: number
struct bravo:
d: string = "bravo"
function test(input: alpha struct):
broadcast {_input}->b->d # should always print "bravo"
b: bravo struct
c: number
struct bravo:
d: string = "bravo"
function test(input: alpha struct):
broadcast {_input}->b->d # should always print "bravo"
Concrete types means you can now use _ struct as a type in fields, functions, and more! This should help with specifying typing in your custom functions and nested structs.
custom converters
struct ServerPlayer:
player: player
money: number
max_health: number
converts to:
player via this->player
location via this->player's location
player: player
money: number
max_health: number
converts to:
player via this->player
location via this->player's location
Custom converters allow you to register types that Skript can convert your struct object to automatically. This lets you do things like teleport {struct} to me if you have a player/entity converter for the struct. Due to restrictions with Skript's converter system and the hacking I have to do to make this work, this will not register chaining converters for you, so if you provide a player converter, Skript will not be able to convert it to a location despite the existence of a player->location converter it could chain with. Use with care!
Changelog:
- Allows options in fields
- Allow single Object fields to accept any type in acceptChange (thanks @miberss)
- Adds concrete types for struct templates.
- Adds custom converters for struct types.
Full Changelog: https://github.com/sovdeeth/oopsk/compare/1.0-beta1...1.0-beta2
oopsk 1.0 beta 1 release 367 days and 50 minutes ago
beta a
Beta 1 should be a rather stable release. I intend to a set of (experimental) reflective syntaxes before release, like getting the type of a field, the field names of a struct, and unsafe accesses to structs with strings instead of literal field names. Excluding those, this beta is feature complete.
Changelog:
- Adds add/remove changers for fields
- Adds dynamic fields, fields that always evaluate their expression when retrieved, rather than evaluating once on creation. These cannot be set manually after creation.
- Fixes a few bugs with changers
- Adds automated test support
- Adds a
struct copy expression to get deep copies of a struct.
Full Changelog: https://github.com/sovdeeth/oopsk/compare/1.0-alpha2...1.0-beta1
oopsk 420 days, 1 hour and 18 minutes ago
oopsk
oopsk is a Skript addon that aims to add limited object-oriented programming tools to Skript in a non-invasive manner.
Basics
The current feature set revolves around structs, simple objects that group together a set of typed fields. Structs are defined by struct templates, top-level structures that define their name and the fields they contain:
struct Message:
contents: string
sender: offline player
const timestamp: date = now
contents: string
sender: offline player
const timestamp: date = now
A template's name and field names are case-insensitive. The template name follows the same rules as a function name, while field names can only consist of letters, underscores, and spaces.
Each field has a name and a type, as well as an optional default value. This default value may be an expression, as it is evaluated when a struct is created, not when the template is registered.
Adding const or constant to the start will prevent the field from being changed after creation.
Creating a struct involves a simple expression:
set {_a} to a message struct
{_a} is now a new instance of the Message template, with contents and sender unset and timestamp set to the date the struct was created. Fields can be accessed and modified with the field access expression:
set field contents of {_a} to "hello world"
broadcast {_a}'s sender field
reset {_a}->timestamp
broadcast {_a}'s sender field
reset {_a}->timestamp
Structs can also be created with initial values:
set {_a} to a message struct:
sender: player
contents: "hello world"
sender: player
contents: "hello world"
Type Safety
oopsk attempts to ensure type safety at parse time via checking all fields with the given name. This means having unique field names across structs allows oopsk to give you more accurate parse errors, while sharing field names can result in invalid code not causing any errors during parsing.
Any type violations not caught during parsing should be caught at runtime via runtime errors that cannot be suppressed. Note that code parsed in one script prior to updates to a struct in another script will not show parse errors until it is reloaded again, though it should properly emit runtime errors.
Modifying the Template of Existing Structs
Any modifications to a template will be reflected in all structs that have been previously created from that template. This can result in data loss if a field is renamed, removed, or changes type, as existing structs will have their modified fields either removed or re-evaluated as appropriate.
Note that this means default values need to be re-evaluated and therefore will not have been evaluated when the struct was created. oopsk will print a warning in console if any existing structs were modified as a result of template changes. Adding fields to a template or changing default values will not modify existing structs.
Removing a template will 'orphan' existing structs, who will function as if the template still existed, though it may be impossible to access their information as the field access expression may not recognize the field names. If a new template is added with the same name, these existing structs will be updated to match the new template.
If you remove a template, you should take care to remove structs that depended on it.
I recommend putting your templates in a separate script file, so you can limit the chances of them being accidentally modified or disabled.