#I think, for modders the best option

1 messages · Page 1 of 1 (latest)

formal tangle
#

I mean no disrespect but read access should be alot safer. Patches might take weeks to months to release and this would mean modders would have to wait that long for changes to occur.

A globalized read method that's locked to exposed classes only would alleviate a lot of overhead for you guys and writing getters for everything.

I do agree making setters require a bit more leg work is unfortunate but probably necessary.

stark onyx
#

I definitely agree, reflection being locked to debug is a terrible hit on modding

#

There's also huge limitations with patching recipes that I had managed to go over thanks to reflection and while I haven't looked in it yet, I doubt any changes were made on that part to provide with proper ways to patch recipes from Lua without doing weird stuff

#

Overall the modding changes that were provided are amazing, I think that's a lot of fixes and improvements for things that had been in a shitty state for some time now so that's really cool, sadly that part tho is quite a huge impact on lots of deep technical modding

surreal totem
#

For now a fix would be advising our users to play in Debug Mode and I don't think thats a good solution, even temporarily

formal tangle
#

Yeah I want to add that I love the changes- sorry for dragging down on this point 😅

mortal basin
#

Yea Im really confused at the loss of read only access to <everything we could think of>

stark onyx
#

Modding zombies is even worse than before now 💀

mortal basin
#

If security for.. passwords or whatever is a concern, A: Lua can override the entire UI and have a user enter his password into a modded dialog, and B: You could have reflection explicitly blacklist a few names

scenic snow
#

there is definitely a valid security concern with field access, especially when using it to look into classes that aren't even exposed

#

however i do feel like this was a very sudden change that leaves us heavily reliant on TIS making changes for us, even to accomplish things we could already do before

formal tangle
#

Yeah... let's try to reach a mutual understanding and chill a bit

mortal basin
#

that would massively reduce any attack surface.

formal tangle
#

I wrote this in the reply 😅

mortal basin
surreal totem
#

Its only been a little bit and they've already responded to some feedback

mortal basin
stark onyx
#

You found something insane you can do by accessing that random ass field here and there ? You are fucked man lol

#

Gl waiting on next update when they are working on B43 and will never update B42

formal tangle
#

It does seem like less work for everyone to have a limited globalized reader -- but being fresh off a massive potential exploit they probably need a lot of time to think this over shrug

stark onyx
#

Also I am scared of checking IsoChunk, because previously accessing the ID of a chunk had to be done with reflection, or manually calculating it which was annoying. At least it's still possible to do I suppose 💀

mortal basin
#

ok nm my bad, I actually didn't ask for throttle to have a getter, I asked for other things that would have removed reflection from realistic car physics

surreal totem
#

The way I see it is that if it becomes impossible for some mods to function the way they did, I can see people put Debug Mode as a requirement for the mod running. Which I don't really think gets us anywhere

mortal basin
formal tangle
#

Sorry for inciting a dog pile eldenring2

I do hope this is reconsidered. I just can't imagine manually adding requested getters as being the best solution - but ultimately if that's what's decided it is what it is.

stark onyx
#

There's definitely a lot of concerns about it from experienced modders, addressing it is necessary

mortal basin
#

Maybe some automated code linter could also look for variables that don't have getters/setters and generate some?

#

(At least, among the already exposed classes?)

#

Some games also have options in the settings menu to explicitly allow things known to be 'risky', such as space engineers you have to enable 'experimental' mode that does nothing except allow scripting in blocks IIRC.

#

It might be nice to have some kinda option like that, separate from -debug because of how much -debug does (Debug mode is not really viable for any MP mods)

formal tangle
#

I also just realized I use this in SRJ 🥲 -- I'd have to check but I'd say I've used this for a makeshift getter in like 6 mods

mortal basin
formal tangle
#

Yeah I'll go through my repos and compose a list 😅

mortal basin
#

I'll have to make realistic car physics store the throttle value in car ModData or something for project summer car for now. -_-; People without both will just have to live with new wildly incorrect fuel calculations.

mortal basin
formal tangle
#

public boolean zombie.inventory.types.Clothing$ClothingPatch.hasHole
public KahluaTable zombie.scripting.objects.Item$defaultModData
public final java.util.ArrayList zombie.iso.IsoMetaGrid.Buildings
public float zombie.inventory.types.HandWeapon$weaponLength

@limpid canopy I crossed out buidlings because I think a getter was added(?), but the rest are still not available, ironically theres a setter for weaponlength 😅

formal tangle
#

I do also hope a global getter that respects if the object is exposed, and the field is public, is considered. It would keep this legitimate functionality alive and lighten the busy work for you guys.

#

setters unfortunately would require manual verifcation I imagine 😅

formal tangle
#

@umbral raft I think this would also solve your problem/request 😅

#

At least for reading stuff

umbral raft
#

Would be really good to have, though if it respects privacy it won't help access private fields. (Like BodyLocation.exclusive)

formal tangle
#

Ah yeah, I'm not sure about a solution for setters aside from having manual additions made by devs, or an additional opt-in allow "risky" behavior flag that allows a global setter for exposed and public classes.

#

Concieavbly, modders can flag their mods as needing this opt-in feature (could also be applied to cases where disabling anti cheats is needed) and have players make informed decisions when connecting / enabling mods.

Ex: The server you're joining / mod you're enabling has disabled XYZ anti-cheat and has allowed partial reflection etc.

umbral raft
#

In a world where users are expecteed to replace java files to get some mods working adding a "allow advanced mod access" isn't much of a security risk.

#

Much better than making a "install this java mod to enable other mods" Reflection Enabler.

surreal totem
#

Im not sure I love the idea of having to enable an esoteric option in settings is preferable either, tbh

umbral raft
#

Just make a mod to enable it and set that as a dependency. 😛

scenic snow
#

yeah that's a big thing, any kind of setting can probably be worked around by lua anyway 😅

mortal basin
#

(-unsafe? -reflection?)

#

Along with some kinda 'intro to PZ' like popup that alerts you to why -unsafe is a bad idea

#

Like, I feel a big part of such a setting or option is informed consent.

#

People should be told what they are signing up for, and not just... blindly following some mods 'install directions' with no idea what that actually allows a mod to do

limpid canopy
#

I have an idea on how to safely give you access to the PUBLIC fields of the EXPOSED classes. I'm working on this option.

The question is, do you only need to read these fields, or do you often need to modify them? I would like to have additional examples of your use of reflection.

mortal basin
# limpid canopy I have an idea on how to safely give you access to the PUBLIC fields of the EXPO...

B42.14, we couldn't actually modify fields unless they also had their own exposed setters as part of the exposed class. Like if the field was an ArrayList, we could used the exposed ArrayList class to delete/add items to that list. And if the object in the ArrayList had exposed fields we could call those. (We couldn't modify POD fields at all without a setter, and more complex classes only if they had exposed setters somewhere)

#

This was sufficient for a lot of mods, although we'd absolutely love being able to request more setters/getters in the future regardless if its not too much trouble/risk.

#

Reading just POD fields is what we had, but we basically had 'calling access' to any fields that where explicitly exposed classes.

#

(Never had write access)

#

Thought: you could have a wrapper for ArrayList that was 'secure' and wouldn't allow access via LUA reflection mechanism, incase you wanted to make sure some array (like say usernames/passwords/access status) was inaccessible from LUA

#

Or potentially blacklist ArrayLists containing certain objects. (I think you can detect that?)

limpid canopy
#

Yep, or return immutable ArrayList. But I think we can even give access to modify the ArrayList from public fields. Just need to check for potential risks.

#

I think we can hide some dangerous fields in exposed classes. And give API for get public filed names and values of EXPOSED classes.

umbral raft
# limpid canopy I have an idea on how to safely give you access to the PUBLIC fields of the EXPO...

Example of reading: Street Smarts reads forage zone information and/or street information to decide which parts of the world map are roads, so the player can start knowing roads near them. Immutable ArrayList would be fine.

Example of Writing: Wear Anything With Anything needs to edit the exclusions for BodyLocations. It can't do this before the exclusions are created because the lua script that creates them executes on load, before the files in the mod are looked at.

IMO the default differentiation for read vs. write would be "can lua put data into this thing?" If so, it should be able to also delete or change the data. If not, read-only is a good default.

mortal basin
#

Iv yet to see a mod that wanted to write stuff to anything you might deem risky for security purposes. So locking those down from whatever you give us is fine