tterrag - Today at 6:41 PM
lex: I'm trying to get to the bottom of all this hasCap/getCap nonsense and misunderstanding. so I'm going to ask this very directly, so it's clearly laid out, and then we can move forward:

1. Is it expected that hasCap should always be called before getCap? Is it a failure to follow contract if it is not?
2. Is it required that if hasCap()==false then getCap() must be null?
3. Is it required that if hasCap()==true then getCap() must be nonnull?
as far as I can tell, the javadocs are kinda vague on all these points
I'm looking into clearing them up

LexManos - Today at 7:07 PM
1) No, 2) No, but it would be stupid. I don't see any case where a false would then lead to code that tries to use the cap... 3) Yes
tterrag - Today at 7:07 PM
okay
so furthermore, can we discuss the implications of that answer to #3?
what about this case?

It also has other implications: To support hasCap() for rendering purposes client-side means that you also have to support getCap() client-side, which means that you have to sync your complete data for the cap to the client---because people will bug-report client-side cap objects that do nothing.
what's the solution?
LexManos - Today at 7:08 PM
has is LITERALLY a replacement for instanceof
get is LITERALLY a replacement for (Cast)
tterrag - Today at 7:08 PM
sync all the data? or should the caller not rely on clientside info?
LexManos - Today at 7:08 PM
nothing should ever rely on clientside shit.
tterrag - Today at 7:09 PM
okay
so the proper implementation is to just return a dummy capability with unsynced data
LexManos - Today at 7:09 PM
Thats a general design concept for anything server/client
tterrag - Today at 7:09 PM
am I understanding that right?
LexManos - Today at 7:09 PM
if you feel like it yes
tterrag - Today at 7:09 PM
the problem I see with that is something like a fluid pipe
LexManos - Today at 7:09 PM
its not 'proper'
tterrag - Today at 7:09 PM
might want to use extended states for rendering connections
and you can't easily sync that data
LexManos - Today at 7:09 PM
the only defintion of 'proper' is to not return null if has returns true
tterrag - Today at 7:10 PM
well this is a real problem we are having, not a theory
we have caps with large amounts of data that have no need to exist on the client
LexManos - Today at 7:10 PM
not really.. what are you doing on the client that requires real data?
tterrag - Today at 7:10 PM
it's not us, but the other mod using the cap clientside
LexManos - Today at 7:10 PM
what are they doing that requires real data?
look at chests
tterrag - Today at 7:11 PM
I don't have a specific example
LexManos - Today at 7:11 PM
we return a cap on both client and server
but the client's are empty
as the data isnt synced
tterrag - Today at 7:11 PM
IE is doing this: https://github.com/BluSunrize/ImmersiveEngineering/blob/master/src/main/java/blusunrize/immersiveengineering/common/blocks/metal/TileEntityFluidPipe.java#L437-L439
GitHub
BluSunrize/ImmersiveEngineering
ImmersiveEngineering - Wires, transformers, high voltage! Bzzzzt!

relies on the handler's tank properties existing
which isn't hard to keep in sync (the amount of tanks rarely changes)
but it's still something
LexManos - Today at 7:12 PM
all that seems to do is check if there is a tank
it doesnt need to know that its lava and has 14mb
tterrag - Today at 7:13 PM
right but it does rely on the clientside cap returning some kind of IFluidTankProperties
and this is just one example
I just want to be clear that a "dummy" cap on the client is valid
so we can justify it later
LexManos - Today at 7:13 PM
sure, if the client doesnt ahve shit it doesnt ahve shit
thats on the API of the cap
nothing to do with Forge/ICaprovider
It WOULD be perfectly valid for someone to write a cap that REQUIRES valid data on the client.
But that is up to the cap designer to explicitly state