[ModAPI] Mods don't have access to give ownership when welding projectors
The main issue here is that Players can exceed block limits and mods need to be able to prevent this exploit.
This references the Nanite Control Factory and Nanobot Build and Repair System mods.
Links:
- Nanobot Build and Repair
https://steamcommunity.com/sharedfiles/filedetails/discussions/857053359
- Nanite Control Factory
https://steamcommunity.com/sharedfiles/filedetails/?id=219757726
The mods in question allow building of blocks via projector.
The projector blocks it does build, have no ownership and do not count towards the players build limits on the server, thus allowing the players to bypass these built limits.
As a server admin, this exploit is used quite frequently, but cannot be fixed easily because the blocks themselves are mods, and I have discussed with the mod authors why this happens.
The reasoning behind it, is because the modapi does not have the ability to assign players blocks built via projection, thus allowing players to bypass all limits.
I am not sure what exactly needs to be done, but I do know there are two paths at least.
1. Forcing projections to be owned by the player who inputs the projection into the projector
2. Adding modapi function to assign blocks built by projection.
I have forwarded this post to the authors of the mods in question and they may be able to elaborate what is needed better.
I like this feedback
Simply, mods need access to a MySlimBlock.BuiltBy setter, as this can be useful for mods that don't use projectors. Currently this value is only stored in the object builder for the block, which can't be written to directly by mods (but can be read).
Currently, the game itself can't even do this, it sets this value when it creates the block (from the creator code, not inside the block itself), which means the block can't even change its own BuiltBy. In fact, it's effectively immutable, and can never be changed again.
As for projectors, an additional property for setting the BuiltBy of projected blocks would be nice, as it would be more efficient to let the projector do it each time. Such as "BuiltByProxy".
For the record, mods can change this value, but it requires saving the object builder, destroying the original block, then re-adding the block back in with the saved object builder with the modified BuiltBy, though this has its own issues (grid splits), so we need a better solution.
On the flip side, as a workaround, modders can create the blocks by hand, with AddBlock() iirc, and passing in the object builder from the projected grid's block (after changing BuiltBy, of course). I'm not sure how to maintain the link with the projector though, if it doesn't automatically maintain that link (worth testing).
Not ideal, of course.
Simply, mods need access to a MySlimBlock.BuiltBy setter, as this can be useful for mods that don't use projectors. Currently this value is only stored in the object builder for the block, which can't be written to directly by mods (but can be read).
Currently, the game itself can't even do this, it sets this value when it creates the block (from the creator code, not inside the block itself), which means the block can't even change its own BuiltBy. In fact, it's effectively immutable, and can never be changed again.
As for projectors, an additional property for setting the BuiltBy of projected blocks would be nice, as it would be more efficient to let the projector do it each time. Such as "BuiltByProxy".
For the record, mods can change this value, but it requires saving the object builder, destroying the original block, then re-adding the block back in with the saved object builder with the modified BuiltBy, though this has its own issues (grid splits), so we need a better solution.
On the flip side, as a workaround, modders can create the blocks by hand, with AddBlock() iirc, and passing in the object builder from the projected grid's block (after changing BuiltBy, of course). I'm not sure how to maintain the link with the projector though, if it doesn't automatically maintain that link (worth testing).
Not ideal, of course.
Maybe some additional info might usefull,
Internally the projector has a function: MyProjectorBase -> public void Build(MySlimBlock cubeBlock, long owner, long builder, bool requestInstant = true, long builtBy = 0L)
The modding api only offers: IMyProjector -> void Build(VRage.Game.ModAPI.IMySlimBlock cubeBlock, long owner, long builder, bool requestInstant) so the "builtBy" could not be set via modding api.
Second missing thing is a modding api function "IsWithinWorldLimits".Maybe the MyShipWelder -> private bool IsWithinWorldLimits(MyProjectorBase projector, string name) could be pulished.
Maybe some additional info might usefull,
Internally the projector has a function: MyProjectorBase -> public void Build(MySlimBlock cubeBlock, long owner, long builder, bool requestInstant = true, long builtBy = 0L)
The modding api only offers: IMyProjector -> void Build(VRage.Game.ModAPI.IMySlimBlock cubeBlock, long owner, long builder, bool requestInstant) so the "builtBy" could not be set via modding api.
Second missing thing is a modding api function "IsWithinWorldLimits".Maybe the MyShipWelder -> private bool IsWithinWorldLimits(MyProjectorBase projector, string name) could be pulished.
This needs more attention. Please KEEN fix this. Its breaking your own rules.
This needs more attention. Please KEEN fix this. Its breaking your own rules.
Given how many people used those mods in survival to save them from building billions of welders I would like to see this fixed
Given how many people used those mods in survival to save them from building billions of welders I would like to see this fixed
Yeah it is super annoying to deal with. Wish it could get fixed soon
Yeah it is super annoying to deal with. Wish it could get fixed soon
This broked my single player world :( Can't use Nanites till this get fixed :/
This broked my single player world :( Can't use Nanites till this get fixed :/
Replies have been locked on this page!