The spidermonkey tutorial (64 posts)

Topic tags: api, client, internet, mulitplayer, network, server, SpiderMokey, tutorial, update
  • Profile picture of cheatcat cheatcat3p said 1 year ago:

    I dunno if this is the right place to write this, I basically ask if there is anyone who are interested of a updated version of the SpiderMonkey tutorial I might be able to update this (if the Author allow me to do that). I will going through this to learn more how SpiderMonkey works, but if there is no interest I will use another API instead.

    #
  • Profile picture of pspeed pspeed805p said 1 year ago:

    Yeah, the SpiderMonkey tutorial is pretty out of date and should definitely be updated to the new API. There is a document I posted on converting an app that uses the old API to use the new one. Maybe that helps someone convert the tutorial, too.

    …I’d have done it but my time has been split too many ways already lately.

    #
  • Profile picture of iamcreasy iamcreasy57p said 1 year ago:

    It would be great if someone step up to write Spider Monkey tutorials. :)

    #
  • Profile picture of cheatcat cheatcat3p said 1 year ago:

    Maybe a completely new tutorials needs to be done. I give the old tutorial a try first and see how much of that could be used with the new revamp. I don’t have a big knowledge about network programming but if I found something interesting I could put up that as well. My project I am working at is all about network so guess I will learn a lot. I think any links to such tutorials could be placed at the top of this page http://jmonkeyengine.org/wiki/doku.php/jme3:advanced:networking. If you have a better idea please tell me.

    #
  • Profile picture of pspeed pspeed805p said 1 year ago:

    The linked document is the best place to start. (even if I do say so myself.:))

    Some random thoughts as you get under way:
    -Serializer and the @Serializable stuff is probably the trickiest thing you’ll have to deal with… though it’s at least a lot friendlier error-message-wise than it used to be.
    -It’s a good idea to put a static utility method on a class somewhere that registers all of your messages with the Serializer and make sure to call that initialize method from both client and server.
    -The TestChatClient and TestChatServer are decent examples of the basic SpiderMonkey usage… even if a little compact.
    -Pay attention to the warnings that SpiderMonkey kicks out at runtime. It used to fail silently for a lot of the common mistakes but I’ve done my best to make it easier to use in this regard.

    And feel free to ask questions here if you get stuck beyond what that one document provides. Seeing others bump their way through sometimes gives me ideas on how to improve things for the next person.

    #
  • Profile picture of cheatcat cheatcat3p said 1 year ago:

    Where is the TestChatClient and TestChatServer you talk about, I cannot find it.

    #
  • Profile picture of pspeed pspeed805p said 1 year ago:

    In the JME tests under networking. Do you have the other JME tests?

    I can probably dig up the link for it in the SVN web browser if you don’t have them.

    #
  • Profile picture of cheatcat cheatcat3p said 1 year ago:

    There, I found it :) I am trying to figure out how the connector filter works now, I need to do a check with the filterConnector function that takes a InetSocketAddress. I don’t know what I should use for parameter.
    Okey, something like this could work:

    ConnectorFilter cf = new MyConnectorFilter();
        Server myServer = Network.createServer(4040, 5050);
        myServer.start();
        Client myClient = Network.connectToServer("localhost", 4040, 5050);
        myClient.start();
        System.out.print(cf.filterConnector(new InetSocketAddress("localhost", 4040)));

    In discover host section they suggest a code that connecting to each server it found and saying that it wouldn’t work properly. I think it would be better to make it try to connect until it found a server where connection are successful. How do I tell if a connection failed?

    #
  • Profile picture of pspeed pspeed805p said 1 year ago:

    ConnectorFilter is part of the old deprecated API. I think I have accidentally left it undeprecated but everything in the “connections” package is supposed to be deprecated.

    What is it that you are trying to do with it?

    #
  • Profile picture of cheatcat cheatcat3p said 1 year ago:

    Not sure, filter connections? Like banning I think.
    Also, there is any new method for getting the server list? Client.discoverHosts() doesn’t exists it seems and there is no convention for that..
    Seemed a bit illogical that it was the Client who checked up all servers. :P

    #
  • Profile picture of pspeed pspeed805p said 1 year ago:

    I want to add some kind of host discovery but haven’t ported the old approach forward. It only worked on a LAN and I’d like to somehow see about standardizing an API to link to game matching services or something.

    re: filtering… I have not implemented auto-banning yet. When I do it will use the filtering that is in the network package that is currently used to filter broadcast messages.

    #
  • Profile picture of cheatcat cheatcat3p said 1 year ago:

    Game matching services? You mean some kind of master server thingy with a list of servers from different games?

    #
  • Profile picture of pspeed pspeed805p said 1 year ago:

    Wouldn’t it be cool?

    Yeah, something where a game server could register itself so that other clients could find it. It’s just an idea on paper. I may prototype it for Mythruna.

    #
  • Profile picture of cheatcat cheatcat3p said 1 year ago:

    Indeed it would be cool. Looking forward to this. :)

    Would this be a good way to use the Message class:

    @Serializable()
class HelloMessage implements Message {
    boolean F;
    String hello = "Hello!";

    public Message setReliable(boolean f) {
        F = f;
        return this;
    }

    public boolean isReliable() {
        return F;
    }
}

    I am not sure what the F is and why the set method should return a Message object trough.

    #
  • Profile picture of pspeed pspeed805p said 1 year ago:

    Just extend AbstractMessage to get all of that. So:

    @Serializable
public class HelloMessage extends AbstractMessage {
    String hello = "Hello!";
}

    Though, obviously, most messages will have constructors, get methods, etc. most likely. Just remember that if you add your own constructors that all Messages need to also have a no-arg constructor.

    For the other…

    setReliable() tells SM how you’d like the message to be sent… basically TCP=reliable, UDP=fast but unreliable.

    setReliable() returns Message because the old one did and I saw no reason to change it. It allows you to do things like:

    client.send( new MyMessage().setReliable(true) );
    #