result = remote.getStringId(s);
…on RemoteEntityData will send a message on through to the host.
Which will eventually call:
And that’s just calling:
…which will never return null but throw an NPE if the string doesn’t exist in the index yet.
But but but… you created that CONSTANT on startup, didn’t you? I mean, Java is creating TileTypes.LEGACY on start-up. What a waste? No. That’s normal practice.
So if you expect to be able to use that constant on the clients as a string ID then you should prepopulate them. Somewhere in the server startup code:
You could even cache them if you like. Or just use ints instead of strings in the first place… they’re constants after all and there is no reason other than “I like to see them in the logs” to use strings, really.
If Ali_RS adds the fix to no longer throw an NPE (which is a good fix) then what will happen instead is that you will get a filter that will never match anything. You’ll pass it to your EntitySet or Entitycontainer or whatever and never get any items in it and wonder why.
Bottom line: what’s weird, super-duper-weird, is to EVER call getStringId(someString, false) (note: the false) unless you are already sure that the string has been created (or you are checking the result to see if it has already been created).