Huhhila
1 = Build archival helper tool. Similar to sharetool's area handling, but instead of changing ownership make it easy to flip access to several areas and/or protboxes in range with some priv-prot like "archived_build" which should prevent modifications (unless some conditions?), but still allow (P) travelnets. Maybe also a feature for creating +1/+2 sized wrapping areas to prevent issues with connected nodes.
SX
I'd say probably too complicated for very (extremely) narrow use cases. Better to just protect with overlay if possible (I think it is) and make travelnets either public or have separate areas for them (should be possible in some cases but not as easy in every case).
Huhhila
Yup +1/+2 sized banana-priv area does most of that... and most ships fit that. If there was a priv-like toggle for disabling nodetimers/abms/etc in an area, then could simply jump ships directly inside such a prepared archival area.
SX
Well, disabling normal active block functionality on area would be completely different thing. While still not exactly something that would be needed or wanted very often I could see some uses for that and it could very well include regular protection. But is more like "disable everything"-area.
Huhhila
2 = Add another staff-priv that is not revoked prior to entering OTP in case of otp_enabled players. Possibly named dental_plan or similar.
SX
In what case staff priv would be needed / to do what without supplying second factor first?
Huhhila
fakeplayer nodes are quite spammy if you wrap an area in staff-priv
SX
fakeplayer nodes are always spammy if you don't have access, probably better would be to silence some things until second factor is provided. I mean it is not staff issue and otp kinda becomes less relevant if it wont actually prevent full login.
Huhhila
Yup not really a staff issue... but having access to such a dental_plan type of priv benefit could allow tiny extra bit of design flexibility for staff members, likely with far simpler implementation than adding more complex features to otp.
SX
Having better UX for staff in problem situations is very bad thing to do because it essentially hides issues from staff and staff members are who should be aware of issues as soon as possible. So definitely needs better solution if it is significant issue.
Huhhila 1 = Build archival helper tool. Similar to sharetool's area handling, but instead of changing ownership make it easy to flip access to several areas and/or protboxes in range with some priv-prot like "archived_build" which should prevent modifications (unless some conditions?), but still allow (P) travelnets. Maybe also a feature for creating +1/+2 sized wrapping areas to prevent issues with connected nodes.
SX I'd say probably too complicated for very (extremely) narrow use cases. Better to just protect with overlay if possible (I think it is) and make travelnets either public or have separate areas for them (should be possible in some cases but not as easy in every case).
Huhhila Yup +1/+2 sized banana-priv area does most of that... and most ships fit that. If there was a priv-like toggle for disabling nodetimers/abms/etc in an area, then could simply jump ships directly inside such a prepared archival area.
SX Well, disabling normal active block functionality on area would be completely different thing. While still not exactly something that would be needed or wanted very often I could see some uses for that and it could very well include regular protection. But is more like "disable everything"-area.
Huhhila 2 = Add another staff-priv that is not revoked prior to entering OTP in case of otp_enabled players. Possibly named dental_plan or similar.
SX In what case staff priv would be needed / to do what without supplying second factor first?
Huhhila fakeplayer nodes are quite spammy if you wrap an area in staff-priv
SX fakeplayer nodes are always spammy if you don't have access, probably better would be to silence some things until second factor is provided. I mean it is not staff issue and otp kinda becomes less relevant if it wont actually prevent full login.
Huhhila Yup not really a staff issue... but having access to such a dental_plan type of priv benefit could allow tiny extra bit of design flexibility for staff members, likely with far simpler implementation than adding more complex features to otp.
SX Having better UX for staff in problem situations is very bad thing to do because it essentially hides issues from staff and staff members are who should be aware of issues as soon as possible. So definitely needs better solution if it is significant issue.