.NET 9

[elevatorguy]

I don't operate a public Terraria Server, so just single-day local testing; haven't thought through other failure modes, code still pending my review, etc. With the go-ahead, perhaps I can make further commits as needed, but no worries without.

@Hidendra Do you mind if LWC for Terraria gets updated? (pretty sure you gave me permission, though that was nearly fifteen years ago so asking in case you might not appreciate the Assistant(s) - can remove this former fork from github if you'd prefer, but the plugin doesn't crash TShock in current form - 3d94b93 - and no noticeable issue(s) with Terraria 1.4.5.6 so far outside of TShock's command and permission system as interface requirement)

dotnet build -c Release to get LWC.dll.

Assistant Prompts

...

---

Any other changes before client test? (ran it again, so serverlog.txt should have updated)

---

Can't make an issue on the github - the issues tab is missing - and it doesn't show it as a fork...

---

Meaning that would be tshock issue not plugin? (unfamiliar with TShock 6.1 plugin-feature list)

---

LWC stands for lightweight chest - it is a protection plugin, so protection needs to be tested from within the game-client too once tshock server is good-to-go.

---

Anything else before game client load? (serverlog.txt has another server launch)

---

On a separate tshock install, it seemed /sudo /cinfo prevents unregistered chest opening, while password protected chests open though do show the text prompting to unlock it; /sudo /cremove doesn't seem effective on any chest, but /sudo /cprivate results in text of registration. Does this rely upon the tshock /login - didn't test opening as non-logged in player. (does it have to be the first chest opened after issuing command?)

---

Can the .csproj copy the .dll to the /opt/tshock/ServerPlugins folder? (post-build step)

---

TShock server is running; just waiting on the client join - presently.

---

Okay, so put down five chests and made private, public and password, then logged out - each chest opened, displayed contents. So the bug earlier that happened with /sudo /cinfo wasn't actually a protection? (as an aside /sudo /cremove and /sudo cinfo does seem to work as expected presently) No messages regarding access denied if not logged in or does it have to be a different player name?

---

TShock does have /reload <pluginname> command, though.

---

reload doesn't show version number, so how do we know update took?

---

Right; console isn't the same as ServerLog.txt.

---

/reload LWC doesn't seem to result in messages in serverlog.txt; though, probably could have restarted it by now.

---

Can confirm tshock /logout doesn't stop chest access, but creating another character and joining does prevent protected chest access (private and password); though if player logs in as the player that registered the chest, it seems tshock login is ignored. (this may be as expected, eg. not a bug - thinking of more tests to try on client)

---

Right; after /logout the commands aren't available - though that may be tshock config - to have all players have command permission(s). (haven't configured tshock permissions yet, just using /sudo override as player setup as server owner.)

---

Can confirm Group default has been modified successfully. as /group addperm default lwc.public lwc.private lwc.password lwc.unlock lwc.info lwc.remove; haven't started game-client to test without using TShock's /login just yet - TShock 6.1.0 server running.

---

Commands not in list; restarted TShock - still not available. (seems there is more to setting up TShock permissions to be done)

---

With /reload LWC can confirm guest has list with /help - TShock 6.1.0. (/cpublic, /cprivate, /cpassword, /cunlock, /cinfo) Added /cremove separately without needing plugin reload; so permission(s) are tshock - eg. not necessarily entirely plugin.

---

Is issue; perhaps - may be feature that chest removal doesn't auto deregister. However, any future player(s) placing chest(s) may find they don't own.

---

If the owner removes a chest but doesn't deregister it, should it auto deregister? (they'd need to issue command(s) again if so)

---

Regarding 0626e06, what is 21, 88, 471 and 472? (unfamiliar with e.EditData)

Note(s)