Links
Tags
Creators
Details
1.0-beta2
Compatibility
Required content
Changes
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"
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
Custom converters (<type> via <expression>) 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
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:M1vFyaZL:uge7wDfR"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:M1vFyaZL:uge7wDfR"
}

