Industrial Foregoing

Industrial Foregoing

95M Downloads

crash when connecting XNet to Mob Detector

Lescius opened this issue ยท 9 comments

commented

Industrial Foregoing Version: industrialforegoing-1.12.1-1.4.2-69.jar

TeslaCoreLib Version: tesla-core-lib-1.12-1.0.9.jar

XNet Version: xnet-1.12-1.4.0.jar

Crashlog (If Any): https://pastebin.com/wDPzPUKB

To reproduce:

Create a world. Place a mob detector. Place an XNet blue connector next to mob detector.

commented

I should probably mention that in multiplayer, this crashes the client, not the server.

commented

Thats XNet asking for null Facing in everything, I will fix it in my side but it should be really fixed by asking a not null Facing

commented

Facing null is a valid input for capabilities. Check the comment with it. It means 'internal' access

commented

For reference. This is in ICapabilityProvider:

/**
 * Retrieves the handler for the capability requested on the specific side.
 * The return value CAN be null if the object does not support the capability.
 * The return value CAN be the same for multiple faces.
 *
 * @param capability The capability to check
 * @param facing The Side to check from:
 *   CAN BE NULL. Null is defined to represent 'internal' or 'self'
 * @return The requested capability. Returns null when {@link #hasCapability(Capability, EnumFacing)} would return false.
 */
@Nullable
<T> T getCapability(@Nonnull Capability<T> capability, @Nullable EnumFacing facing);
commented

'internal' or 'self' ... not a pipe connected to the thing... a pipe is neither 'internal' nor 'self'...

not saying the machine should crash on 'null'... that's bad... but a pipe should not use 'null' either.

consider the case of those machines... where valid facings are configurable for each inventory... you set inventory A to be accessible for North and South... what should 'null' return in that context?... I would say false.

commented

XNet Advanced pipes have the feature that they can connect 'from any side' different from the actual side they are connecting too. That's why I have to use null on the client side because the client side does not know the actual side that will be used on the server

commented

ah... this is on client side only?... and it's using an actual non-null facing on server side?

commented

yes it is on server side. Note however that some of my other mods use null a lot. For example, the RFTools power monitor uses null because it doesn't connect from any side. It monitors from a distance. The One Probe gives energy readings with null as well because there is no side involved either. So personally I think 'null' is a valid input and should also be supported server side. There are many uses

commented

so 'null' would mean 'give me all your sides'... :S

so maybe a better filtering would be... as long as the inventory is configured for at least one side... it can be accessed with 'null' also...

hmm... interesting...