indigo hull
https://forum.denizenscript.com/resources/dcommands.122/
https://github.com/Bill-Gates-Denizen/dCommands/blob/main/dCommands.dsc
https://paste.denizenscript.com/View/102900
i think this is everything needed, if i should add more lmk
Edit: these links are old
empty summitBOT
https://forum.denizenscript.com/resources/dcommands.122/
https://github.com/Bil...
Hi I'm AutoThreadBot! Don't mind me, I'll just be adding the helper team to this thread so they can see it. A human will get to you soon.
You can block this bot if you don't want to see these messages, I won't mind.
<@&525394568410038282>
indigo hull
nope i am on mobile
indigo hull
is this tabcomplete necessary?
yeah, if not there it shows player names
tbh for the tab completions i have no idea if i should use <list> or <empty>
steel relic
also
why are you using flags for ban instead of the "normal" way
line 260 has unnecessary stop
indigo hull
why are you using flags for ban instead of the "normal" way
i couldn't figure out a way to show fancy messages for the banned players when using the ban command
steel relic
line 260 has unnecessary stop
and the else: if can just be else if
indigo hull
but i guess i could just slap the proc on the normal ban
indigo hull
yeah i can
steel relic
any reason this uses op instead of a permission?
also i tend to avoid generic flag names like this
indigo hull
any reason this uses op instead of a permission?
hmm yeah i should add a permission like dcommands.showdisabledcommands for players instead of using the op
indigo hull
also i tend to avoid generic flag names like this
oop, i'll just change it to dcommands.restarting later
indigo hull
LMAO i was waiting for you to see that
uh, how do i explain my train of thought for that
makes it easier to get the data values and doesnt even impact performance that much
but yeah i could just add em manually on every relevant script, that was just lazy fix
steel relic
if you really wanted to cache the config in a flag for performance reasons, you could just flag dcommands.config with <script[dcommands_config].parsed_key[]>
and then you could use <server.flag[dcommands.config.etc.etc.etc]>
indigo hull
oooooohhhh
steel relic
also instead of <color[<some tag>]> you coudl just do <some tag.as[color]>
indigo hull
does that make a difference though?
oh yeah its overusing constructor tags
yeah i see why
south zinc
if you really wanted to cache the config in a flag for performance reasons, you ...
I highly doubt that'd make any significant change if at all, and would also block people from using dynamic stuff
indigo hull
uuhhh
steel relic
I highly doubt that'd make any significant change if at all, and would also bloc...
yeah
i think its best to just use the script.data_key
south zinc
parsed_key if you want to allow tags, but yes
south zinc
does that make a difference though?
No, matter of preference
Personally I like .as[type] better but <type[]> and .as[type] are the same thing
steel relic
<color[<script[a].data_key[b]>]> and <script[a].data_key[b].as[color]> are the same thing
but i personally prefer the second
indigo hull
parsed_key if you want to allow tags, but yes
so i could change all data_key[thing].parsed to that?
steel relic
yes
indigo hull
ayy
steel relic
i dont think these brackets are necessary
steel relic
ok
heres another example of the constructor tag thing
<duration[<context.args.first>].if_null[null]> vs <context.args.first.as[duration].if_null[null]>
but thats just me
but uh why
why the raw color code
south zinc
Not really a thing that's worth pointing out more then once, constructor vs as is a matter of whatever you prefer
south zinc
`<duration[<context.args.first>].if_null[null]>` vs `<context.args.first.as[dura...
Re that ^, forgot to reply
steel relic
yeah
just me being nitpicky
for the enderchest command, i think you should have a separate permission for opening other players' enderchests
heres more instances of raw color code for some reason
kind fable
for the matter of following your screens you can mention the line
steel relic
ok
steel relic
for the enderchest command, i think you should have a separate permission for op...
enderchest is 437, raw color is 504
line 519, bad description?
kind fable
also probably better to make one large reply including everything
indigo hull
for the enderchest command, i think you should have a separate permission for op...
definitely! i overlooked that
steel relic
same for gamemode, vanish, etc
indigo hull
line 519, bad description?
😭 😭
steel relic
and fly for that matter
indigo hull
yea, will implement permissions on everything
indigo hull
just remembered why i'm using flags for checking bans. default ban command shows this, and my whole thing is for the ban message to be customizable
indigo hull
but thats just me
but uh why
huh, i thought color tags didn't work in console for some reason, weird, just tested and they work
crisp geodeBOT
!t player.is_banned
kind fable
!t player.ban_reason
crisp geodeBOT
!t player.ban_reason
indigo hull
oh, prelogin fires before the ban, nice to know
also, quick question, if i give a player the permission dcommands.heal, will they also have all permissions inside that, like dcommands.heal.others?
kind fable
!tias
indigo hull
also, quick question, if i give a player the permission ``dcommands.heal``, will...
answer: no
indigo hull
alright, so i have a weird issue going on rn.
i have flags for when a player gets banned/tempbanned, for use in the prelogin event.
for the tempbanned flag, i store the timetag of when the ban will end in the flag, and use it later on a proc
i use the same duration definition for both the ban and flag expire: args, but only the ban expires, the flags continues there
kind fable
!t player.ban_expiration
crisp geodeBOT
!t player.ban_expiration
indigo hull
i'm sure it's that the flag isnt expiring, because if i try to ban remove myself, it says im not banned, and player.ban_reason errors
indigo hull
don't have to calculate the time via flag
i'd still have to use a flag for the prelogin event
but nice to know
kind fable
can't you call player.ban_expiration_time in it?
kind fable
wot
indigo hull
if i use - flag <[player]> dcommands.tempbanned.expiration:<util.time_now.add[<[duration]>]> expire:<[duration]> the flag doesnt go away
BUT
if i just use - flag <[player]> dcommands.tempbanned expire:<[duration]>, it works
normal wasp
that looks like - flag <playeR> true:true
kind fable
but dcommand.tempbanned stays an empty map
normal wasp
y double expire
kind fable
but uh
indigo hull
didnt thnk of that
kind fable
technically you dont need flags I think
because there are tags to return the ban expiration, ban reason etc
indigo hull
doesnt seem to have a format option anywhere, + the default ban's message looks like this
maybe thats an oversight? or im blind and have no idea
indigo hull
yeah
kind fable
oop
indigo hull
xD
kind fable
still dont need that expire flag
indigo hull
now the only things using flags is the prelogin event, reasons and expirations use the tag
indigo hull
still dont need that expire flag
yea i removed it
kind fable
neato
indigo hull
now its just - flag <[player]> dcommands.tempbanned expire:<[duration]> to use it in the prelogin 😎
indigo hull
the prelogin fires before the ban thing, so i can override the ugly message and send my own
thats what the proc does
kind fable
no i mean why do you use a flag for ban expiration
kind fable
now its just ``- flag <[player]> dcommands.tempbanned expire:<[duration]>`` to u...
whats that for
indigo hull
on player prelogin flagged:dcommands.tempbanned:
- determine kicked+<proc[dcommands_tempban_proc].context[<player>|<player.ban_reason>|<player.ban_expiration_time>]>
for this
only for this
kind fable
couldn't that be one event?
for banned and tempbanned?
just asking, the implementation is up to you
indigo hull
idk i'm using two separate procs rn, i dont think combining them into one and checking if ban_expiration_time is truthy just to show the tempbanned message is worth it
if there isnt really a problem i'll stick with this, way more readable
kind fable
ye
indigo hull
and with the ban command working, i am ready to update the script
indigo hull
hell yeah
kind fable
with such "large" projects it's ideal to create a dev branch
in which you make your dev changes
and occasional merge it into main
when you the dev version is ready to be stable
kind fable
in summary type your commit name
and in the description you can put optional a description to it
indigo hull
huh
kind fable
you have to select files above
send screenshot of whole thingo
not just a little piece of it
indigo hull
so like this
indigo hull
ahh yeah thats way more understandable
where should i put the list of permissions?
in the readme?
kind fable
as example
can create a GitHub Wiki too
as example uh
I'd prefer a GitHub Wiki tho
indigo hull
oh yeah thats better
indigo hull
indigo hull
message so thread doesnt go inactive
steel relic
!e prelogin
crisp geodeBOT
!e prelogin
indigo hull
it seems like it is, it works and when i space them it kicks without the message and sends an error
south zinc
The usual accepted format is thing:value, so should probably do that
That meta should probably be updated to that format as well, it seems to be documented with a space which means you'd have to use quotes
south zinc
Don't think this can be closed yet as he's applying for confirmed high quality - will try having a look later today
indigo hull
lmao
kind fable
Let us know when we can re-review your script
indigo hull
also thanks for reminding me of this, when i get home i'll finish a quick update on it that i stopped working on
indigo hull
Let us know when we can re-review your script
yeye
indigo hull
ready to be reviewed!
https://github.com/Bill-Gates-Denizen/dCommands/blob/main/dCommands.dsc
re-reviewed*
kind fable
line 266: smallest unit are ticks, 0.01 seconds is not a thing, the minimum you can wait for is 1t
line 279: missing tab completions
line 441: missing tab completions for duration arg
line 311/312, 456/457, 1089: inconsistent duration null fallbacks
line 482: tab completions outputs raw objects
line 537, 569: maybe a wait here, so the player can read the message before opening the inventory
line 1035: inconsistent color <&4>, have that also spread around the script, see my general comment about colors
line 1104: missing invulnerable in your usage format
line 1177: text is not an alias nor an valid argument, weird usage format here?
line 1192, 1193, 1212: dangerous, !guide don't trust players, never parse user's raw input, consider parse_colors
general:
lusty lintel<&[warning]>, line 951 -> <&[error]>, but you also have a color config which has these values, you might want to use !m server.default_colors in a scripts loaded event to add your own ones, so you don't have to pull from config everytime?<&[error]> is perfectly predefined, different colors for errors will be misleading for users
steel relic
damn icecapade working so hard
kind fable
there also several parts in your script that might need a cleanup
indigo hull
line 266: smallest unit are ticks, 0.01 seconds is not a thing, the minimum you ...
266: fixed
279: not really, it's supposed to be empty because the input isn't exact
441: same thing
or i just don't have any idea on how to make a proper tab completion for that. like, do i add in a 15s, 15m as examples?
311/312 and 456/457: fixed
1089: this line uses if_null[1] to have a default delay even if the user hasn't given a delay, or if it's not valid, it's supposed to be like that
537, 569: fixed, 3t wait on both
1035: it's supposed to, so you cant downplay the severity of inputting an invalid max/min argument count. it's there mostly for if someone tries to add their own commands using my injectable and mess things up.
1104: fixed
1177: fixed, it was a placeholder, now it's name
1192, 1193, 1212: fixed, changed all to parse_color
havent posted any of these things to github yet
will look into color stuff, since it's more time demanding
kind fable
line 279, 441; i've used this in the past, but also keep in mind that 25s-50s are also valid duration tags (random duration between 25 and 50 seconds)
tab completions:
2: <context.args.get[2].if_null[0].is_integer.if_true[<list[s|m|h|d|w].parse_tag[<context.args.get[2].if_null[<empty>]><[parse_value]>]>].if_false[<empty>]>
line 1035: maybe use <&[error]> then?
looking at your config:
but yeah, that's probably also part of the color thingy you'll work on
indigo hull
currently burnt out from denizzlin, i'll get to this later™️
for now, do i close it?
south zinc
You can close and reopen once you'd like to get back to it
indigo hull
alright