VRSpace.org

Hi Carlos,
thanks!

Now one dolphin is a VRObject but the other dolphin is a Client. Client is Owned and it's properties can not be changed by other Client instances.
So clicks on both spheres create a dolphin and another click on the sphere removes it. But click on one dolphin is shared, and the click on the other is shared only if it comes from the owner.
You should see error in the console of the other browser, an in server log, 'Cannot change owned object' SecurityException.

Client may be what just you need to implement NPCs. Currently that's how bots and event recorder are implemented - there are server-side classes that extend Client. So they can do everything that a user can, they receive events and so on, except they don't have associated Session. Basically you'd need to override processEvent and sendMessage methods of Client, see e.g. https://github.com/jalmasi/vrspace/blob/master/server/src/main/java/org/vrspace/server/obj/Bot.java and https://github.com/jalmasi/vrspace/blob/master/server/src/main/java/org/vrspace/server/obj/BotLibre.java

That really depends on what you want your NPCs to do, of course. These respond to chat events only. Should they respond to movement, you'd need to handle VREvent objects instead of/in addition to Add/Remove in sendMessage().
This may be somewhat confusing due to method naming. Like, sendMessage() is supposed to send the message to the client, while you might expect it to be used for NPC to send a message :)
But I guess that solves NPCs.

General owned shared objects aren't there yet, because I did not need them yet. But it should be easy enough, like

@Owned
public class OwnedVRObject extends VRObject {
}

That should be all, literally. There still needs to be appropriate test suite to confirm it works though :>
Then your client code would simply create these OwnedVRObjects instead of plain VRObjects.
You could also use Owned annotation of some fields of publicly accessible objects. I really don't know what for, but it seemed a good idea at the moment ;)

Who's the owner?
A Client who created the object, or an Admin, but there's no Admin yet. Specifically, that's about implementations of Owner interface.
And so on.

So let me know how this works for you, if you need anything, and especially if you want to contribute.

Many thanks for the detailed reply! I will check how it works with a `OwnedVRObject` and come back.

I would be happy to contribute on this or other developments. For this one, what about a PR with a minimal example with some dolphins? I might be able to also share the bigger case once it's ready if you like, although I would need to double-check first with my partner who is actually doing the world's design.

Cheers!

I think start small, see how it goes.
Test coverage you need is in DispatcherTest.testOwnedClass() - one client tries to change the name of the other client.
In your case, you'd

OwnedVRObject owned = new OwnedVRObject(123L);
c2.addOwned(owned)
String payload = "{\"object\":{\"OwnedVRObject\":123},\"changes\":{\"something\":\"whatever\"}}" 

Thanks for the tip! My last message was more in the line of defining some kind of "longer-term" goal that would work for your repo too.

Following your message, I've created the following `testOwnedObject` that works as you expected so far:

  public void testOwnedObject() throws Exception {
    OwnedVRObject obj = new OwnedVRObject(123L);
    // VRObject obj = new VRObject(123L); // This won't throw
    Client c1 = new Client(1L);
    Client c2 = new Client(2L);
    String payload = "{\"object\":{\"OwnedVRObject\":123},\"changes\":{\"something\":\"whatever\"}}";
    c1.addOwned(obj);
    printJson(c1);
    System.err.println(payload);

    ClientRequest req = mapper.readValue(payload, ClientRequest.class);
    req.setSource(obj);
    req.setClient(c2); 
    // req.setClient(c1); // This won't throw

    assertThrows(SecurityException.class, () -> dispatcher.dispatch(req));
  }

I'd say start small see how it includes longer term goals ;)
If you use it, and you think it would be useful for someone else, publish it. Generally, I'd welcome it to the repo.
But then there's a small matter of maintenance. Will you, can I?
And so on, that 'see how it goes' part gets complicated.

Re long term goals, I'd love to see this project under the hood of apache foundation or alike.

Hey Carlos,
I just realized that multiuser-test was broken :(
I.e. using non-humanoid avatars did not work.
Fix pushed.