#(drjoenh) Residence PR discussion

76 messages · Page 1 of 1 (latest)

novel dragon
#

HI, Ive been busy last few days, but finally got some time to fix some of my code, comments and whatnot. However there are few (or more than few) things that I have no idea how to fix or change...

No idea what to do here: https://github.com/DenizenScript/Depenizen/pull/397#discussion_r1038815252
No idea how to implement this:
https://github.com/DenizenScript/Depenizen/pull/397#discussion_r1038805320
No idea what to change here:
https://github.com/DenizenScript/Depenizen/pull/397#discussion_r1038520936

Thanks for your time and help

GitHub

New events:

  • residence player creates residence
  • residence gets deleted (cause: <cause>)
  • residence raid ends (residence: <name>)
  • residence raid starts (residence: <name>)

N...

amber apexBOT
#

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>

copper grailBOT
#
Changed to Discussion

Thread is now a Discussion thread. This indicates that the thread is not requesting help in any way, and is just discussing a broad topic openly. If you need help with something, use </helpthread:1028674284870180883> to switch the thread back to a normal help thread.

zinc elm
#

For the first one: the old way of adding tags / mechanisms to an object was creating property classes that always return null as their property value, for the sole purpose of adding tags/mechs to the object: extension properties.
Those has been replaced with a modern alternative, using the object's tag processor directly to register new tags / mechanisms, which is usually done in a separate class for organization; these are called extension classes.
You can see the one I linked there as an example, but basically it's just a *Thing**Object*Extensions class (e.g. PaperPlayerExtensions has PlayerTag tags/mechanisms for Paper), with a static register method that does *SomeObject*.tagProcessor.registerTag/Mechanism.
As to how should that actually be implemented, remove the current extension property, create a new extension class with the same tags/mechs (+ new ones added by that PR if any, ofc), and call it's register method when the bridge initializes.

#

For the second one:
Instead of manually doing the matching, you should implement the advancedMatches method in ResidenceTag, which would let you utilize existing methods for matching.
The advancedMatches method is used for, well, advanced matching - it takes a string and returns whether the object matches that string; see https://github.com/DenizenScript/Denizen-Core/blob/05ff7b333e58c87ddc9c96c4871c3982bbf9ffb0/src/main/java/com/denizenscript/denizencore/objects/core/ElementTag.java#L2546-L2555 for a simple example implementation.
In your case, unless you want to add more options, pretty sure all you'll need is ScriptEvent#runGenericCheck with the residence's name.
After you do that, you could change events to use built-in methods for switches / methods, such as ScriptPath#tryObjectSwitch.

#

For the third one:
You manually added a constructor tag base for ResidenceTag, that works but there's a util method to automatically do that: ObjectType#generateTagBase.
ObjectFetcher#registerWithObjectFetcher already returns that object's ObjectType, so all you need to do is call generateTagBase on that - ObjectFetcher.registerWithObjectFetcher(..., ...).generateTagBase().

zinc elm
#

@novel dragon what's the status on this PR? no worries if you need more time / planning on coming back to it later, just making sure you're aware there are still unresolved reviews on it

novel dragon
zinc elm
#

No worries, feel free to let us know once it's ready for another review

novel dragon
#

Welp I might need some help, looks like Im a total moron. I was able to convert ResidenceLocationProperties.java but not those with player - ResidenceLocationProperties.java...
The problem is that it throws an error with offline players, so something like <player.has_main_residence>
does work just fine but with <server.match_offline_player[qUranium_].has_main_residence> (which is my 2nd test account and it is not connected to the server) it throws an error
code: https://paste.denizenscript.com/View/104940
error: https://paste.denizenscript.com/View/104941

zinc elm
#

PlayerTag has methods for tags / mechs that require an online player

novel dragon
#

eeeeh, could you link me some example of usage?

novel dragon
#

nice I was able to make it work with offline players as well, yay
will do some testing tomorrow and if everything will be fine I will push that commit. 👍

novel dragon
#

Hello, did some testing and found out that everything works except for my implementation of advancedMatches. And Im actually running out of ideas as to why it doesnt work...
This is how my advancedMatches method looks like:

zinc elm
zinc elm
#

You're checking for a switch, but the event uses a matcher

#

You want tryArgObject

novel dragon
#

oh didnt notice that, sorry !

novel dragon
#

aaand now its just yelling at me

zinc elm
#

Well, what are the method's parameters?

novel dragon
#

index, matcher..?

zinc elm
#

Yeah, the index of the arg in the event line and the object to match against

novel dragon
#

soo something like 3, residence... right?

zinc elm
#

Yep, the arg's index is 3 and the object is the ResidenceTag

novel dragon
#

yes..?

zinc elm
#

Do you have an outdated Denizen-Core / Denizen build maybe?

#

May need to pull the latest changes and rebuild Denizen-Core then Denizen

novel dragon
#

yeah, ill try that, thanks!

novel dragon
#

yup, that was it, thanks :D

novel dragon
#

pushed those commits, ready for review 🙂

solemn river
#

also you committed a change to lib which is breaking the ability to merge

#

need to remove that

zinc elm
#

Can residences be renamed? if not ResidenceTag.name can be static

#

In ResidencePlayerProperties you fetch residence players by name - does the residence API not have a method to fetch by UUID? if it does then that'd usually be preferable

novel dragon
zinc elm
#

Ah I see, fair enough

novel dragon
#

I'll try my best to fix those issues and commit it asap 👍

novel dragon
#

#denizen-contrib message
soo... what do I need to do with it?

zinc elm
#

You don't need to manually register it

#

All you need to do is add the meta

#

(Which, btw, should probably make the meta fit the general constructor tag meta format)

#

!t map

red bisonBOT
# zinc elm !t map

Returns a map object constructed from the input value.
Give no input to create an empty map.
Refer to !ObjectType MapTag.
For example: <map[a=1;b=2;c=3]>

Returns

MapTag

zinc elm
#

!t item

red bisonBOT
novel dragon
#

oooo, I see. Thanks!

novel dragon
#

That means that I just need to remove the name() , or am I missing something ?

zinc elm
novel dragon
#

I think its ready for another review, but idk about that change to lib, is it possible to revert it somehow..? idk what Ive changed there 🤦‍♂️

zinc elm
# novel dragon I think its ready for another review, but idk about that change to `lib`, is it ...

lib is the submodule that holds all dependency jars, you updated the residence jar and included the submodule change in your PR, but should make a separate PR to https://github.com/DenizenScript/Depenizen-Lib for that (or the Jar can be updated by monkey when he merges your PR)

Not as knowledgeable with the CLI, but pretty sure you should be able to reset it by pulling the latest changes, and then git reset --hard origin/master; make sure you're in the lib submodule and not the main Depenizen repo

#

After that can commit the submodule change to your Depenizen branch through GitHub desktop as usual

zinc elm
#

Should add Matchable meta to ResidenceTag now that it implements advancedMatches

novel dragon
novel dragon
#

Ready for another review btw 🙂

zinc elm
# novel dragon I dont think that my english skills are capable of something like this :D

Can usually base stuff like that upon existing ones, I.e. for InventoryTag it's

InventoryTag matchers, sometimes identified as "<inventory>":
"inventory" plaintext: always matches.
"note" plaintext: matches if the inventory is noted.
Inventory script name: matches if the inventory comes from an inventory script of the given name, using advanced matchers.
Inventory note name: matches if the inventory is noted with the given name, using advanced matchers.
Inventory type: matches if the inventory is of a given type, using advanced matchers.
"inventory_flagged:<flag>": a Flag Matchable for InventoryTag flags.

#

So can use that as a template, basically

#
ResidenceTag matchers, sometimes identified as "<residence>":
"residence" plaintext: always matches.
Residence name: matches if the residence has the given name, using advanced matchers.
#

Maybe something like that? unless you added any other matchers

solemn river
#

uh

#

was confused where tf Residence downloads were