Conversation
|
The class loading also needs to disable loading for abstract classes, but that can wait |
|
|
Co-authored-by: zNotChill <znotchill@znci.dev> Co-authored-by: mibers <midaswoah2@gmail.com>
# Conflicts: # src/main/kotlin/dev/znci/rocket/scripting/events/EventListener.kt
When first experimenting with this type of event handling, I found that there was an issue where every event was called regardless of whether it appeared in any scripts. This fixes this. Note that currently, disabling does not yet remove events from the handler, so that will be next
|
Note that currently, disabling does not yet remove events from the handler, so that will be one of the next parts |
…unctions (future)
Someone should work on this in the future, I'll try to remember to make an issue for it
Signed-off-by: Lexî Nuutraî <info@nuutrai.com>
zNotChill
left a comment
There was a problem hiding this comment.
Pretty much looks good to me, however unnecessary prints should be removed.
|
Whoops, should I just revert the debug commit altogether? |
This reverts commit e681fd0.
|
If you want to, as long as it doesn't break anything. You could just commit again with the debugs removed. Either way would work as long as nothing breaks. |
|
Let me know if that's better |
Signed-off-by: Lexî Nuutraî <info@nuutrai.com>
|
Merging is blocked pending #32. |
# Conflicts: # build.gradle.kts # src/main/kotlin/dev/znci/rocket/Rocket.kt # src/main/kotlin/dev/znci/rocket/scripting/ScriptManager.kt
|
I'm not entirely sure what other things need to be changed regarding the API since most of it is mainly file stuff |
|
@Nuutrai is this ready for review? |
| implementation("net.luckperms:api:5.4") | ||
| implementation("org.jetbrains.kotlin:kotlin-reflect") | ||
| // TODO check if needed | ||
| implementation("com.google.guava:guava:32.0.1-jre") |
There was a problem hiding this comment.
@blockarchitech said not to use guava, he should also comment here
| var previousChar: Char? = null | ||
| var record = false | ||
| for (char in function.toString()) { | ||
| if ((previousChar ?: ' ') == ':' && char == ':') if (record == false) record = true else break |
zNotChill
left a comment
There was a problem hiding this comment.
Looks mostly good to me, obviously needs to be tested, however there is some issues that should be addressed first
gibbiemonster
left a comment
There was a problem hiding this comment.
More info in the comments. I would generally ignore the Guava comments, on the condition we're planning to use Guava in the future.
Otherwise, do also solve the Qodana issues. There aren't a whole lot, though 🙂
Nice work!
| implementation("net.luckperms:api:5.4") | ||
| implementation("org.jetbrains.kotlin:kotlin-reflect") | ||
| // TODO check if needed | ||
| implementation("com.google.guava:guava:32.0.1-jre") |
There was a problem hiding this comment.
I think guava is a welcome addition but I see not usages of it here.
| val action = args[0].lowercase() | ||
| val scriptName = if (!args[1].endsWith(".lua")) "${args[1]}.lua" else args[1] | ||
| val rawScriptName = args[1] | ||
| val scriptName = if (!rawScriptName.endsWith(".lua")) "${rawScriptName}.lua" else rawScriptName |
There was a problem hiding this comment.
We may want to sanitize this to prevent directory traversal.
There was a problem hiding this comment.
Could you explain that further?
There was a problem hiding this comment.
Could you explain that further?
Directory traversal can mostly be prevented by removing any /es from the start, and ../ from the entire path. ./ is fine because it doesn't move to any directory
| val results = ScriptManager.loadAll() | ||
| if (results.isNotEmpty()) { | ||
| results.forEach { error -> | ||
| sender.sendMessage(LocaleManager.getMessageAsComponent("generic_error", error ?: "Unknown error")) |
There was a problem hiding this comment.
@zNotChill - we need better error handling 🙂
Want to open a ticket for that?
There was a problem hiding this comment.
@zNotChill - we need better error handling 🙂
Want to open a ticket for that?
On my new branch (not yet published), I have already mostly done this. Anywhere you use a RocketError will now work, whereas before it would not, and it would just produce a error calling _: nil error. Now it actually shows you what you did wrong.
| eventCallbacks.forEach { callback -> | ||
| val luaTable = convertEventToLua(event) | ||
| callback.call(luaTable) | ||
| println(callback) |
There was a problem hiding this comment.
This will be removed before merging as it was mainly for debugging
| private fun getSupportedEvents(): HashSet<Class<out Event>> { | ||
| val set = hashSetOf<Class<out Event>>() | ||
| for (eventClass in getBukkitEventClasses()) { | ||
| // TODO Add a debug setting to show these kinds of things |
There was a problem hiding this comment.
Leads to some of the QoL things I bug @zNotChill about 😁
There is a way to check if a debugger is attached, and thus, add some trace logs, but I haven't looked too much into implementation.
| * Maybe for a different PR, it depends on what znci is feeling | ||
| */ | ||
|
|
||
| private fun convertEventToLua(event: Event): RocketTable { |
There was a problem hiding this comment.
I do not like this. Can we convert to using a class so it's more portable? I defer to the greater team however this looks like a testing nightmare and I do not like how much this still uses the old API. I also am not a fan of the giant switch statement.
There was a problem hiding this comment.
As in a class rather than an event? I'm still looking into the new API, so I'll try to get those changed soon. What would you prefer instead of the switch statement?
There was a problem hiding this comment.
I agree, I don't really see what could be changed about the switch statement..
There was a problem hiding this comment.
I think we should rethink how this entire class works. It should be rewritten with the New API's capabilities in mind. I will elaborate in #dev...
|
|
||
| return luaTable | ||
| }) | ||
| table.setmetatable(meta) |
There was a problem hiding this comment.
I recall a while ago we decided not to use the metatable for some reason?
There was a problem hiding this comment.
Without the meta table, users can't have dynamic event values, or at least stringified event values. We'll hopefully add support for conversions though (just a thought)
There was a problem hiding this comment.
I meant directly. The new API fills out a lot of this stuff for you.
# Conflicts: # build.gradle.kts # src/main/kotlin/dev/znci/rocket/scripting/ScriptManager.kt # src/main/kotlin/dev/znci/rocket/scripting/events/EventListener.kt
This is a big event rehaul focused on allowing for dynamic events
I'm writing this in a sort of a rush as I need to go to sleep, however if you have any questions, feel free to ask as many as you need, and I'll get back to you as soon as I can.
Thank you!