Menu ▾ ▴

#9 accounting for different types of requirements

open
nobody
None
5
2008-01-08
2008-01-08
Anonymous
No

Many people use the mplayer functionality in Flightgear for different purposes, as such there may be conflicting ideas about how to use it, what not to do and what to expect of other people: some are connecting to just have some fun, others want to practice real procedures, test new experimental aircraft, test new code, fool around with the ufo (or other weird non-standard aircraft) or whatever.

Preferably, there should be a way to ensure that certain sorts of users only get to see certain users, so that users may right from the beginning declare their intentions, enabling the multiplayer server to avoid propagating their state information to clients that may not be interested in their state due to the nature of the session.

likewise, this could also be useful to prepare flightgear for combat capabilities, where certain users may really want to "enjoy" full combat support, including shooting at eachother, mid-air collisions and crashes - while other (civilian) users may only want to fly with those people, but avoid being possibly affected by them.

So, there could be additional options such as: "show combat aircraft but avoid effects" or "full combat: shoot & be shot".

These would be runtime state variables, so that the mplayer server could decide what state should be propagated to certain clients and which shouldnt.

Baically, the suggestion is to introduce new "user classes" with a pre-defined set of rules, so that connecting users may subscribe to other clients matching their own "class" (or its requirements) in order to avoid clashes between users.

in fact, something like this (that is, selective state-propagation) could even be used to use one single server instance to enable clients to fly in different times (think YEARS), i.e. there could be a list of server-side fields:

- current (actual/today's time)
- pre 9/11 (i.e. to show certain landmarks such as for example the WTC towers)
- WWII to put all connecting clients into WWII state

meaning, clients connecting to any particular "time" would not see clients connected to the other ones

Discussion

  • Nobody/Anonymous

    Nobody/Anonymous - 2008-01-08

    Logged In: NO

    also:
    - dis/allow pausing simulator
    - dis/allow certain aircraft/fdms [i.e. using a simple hash of the property tree node resulting from loading an aircraft-set.xml file, trying to ensure aircraft validity]

     

  • Nobody/Anonymous

    Nobody/Anonymous - 2008-01-10

    Logged In: NO

    regarding the last comment: that would mean to hand over property control to the multiplayer server or rather that particular flightgear component, so that certain properties could not easily be modified at runtime.
    I am not sure if this is generally desirable or even feasible, given that we will still want to be able to do debugging.

     

  • Nobody/Anonymous

    Nobody/Anonymous - 2008-01-10

    Logged In: NO

    we might also want to handle cases where position data on the server indicates that aircraft flight paths were crossing eachother at the same time to come up with a "crash event" in this situation.
    Also, as a server admin I might want to prevent users from starting in air, and basically require them to start on airports only

     

  • Nobody/Anonymous

    Nobody/Anonymous - 2008-01-12

    Logged In: NO

    you may also want to disallow simulator time speedups/slowdowns (a/A keys), in fact the fgtracker cannot even yet deal with it, it doesn't account for simulator time at all.

     

  • Nobody/Anonymous

    Nobody/Anonymous - 2008-01-12

    Logged In: NO

    also, normally it should not make much sense from a logical point of view to allow clients to speed up simulation time, given that the actual simulation time is maintained globally -on the server-side- and should only be runtime-configurable for admins, I am not sure about the possible benefits of allow clients to maintain their own simulation time locally

     

  • Nobody/Anonymous

    Nobody/Anonymous - 2008-01-19

    Logged In: NO

    regarding the previous comments, I think their nature is best being described as asking for "remotely managed/controlled properties", that is properties whose state is to be modified only by a corresponding host, i.e. the multiplayer server-which in turn means that there needs to be some sort of concept for property "ownership" (as discussed on the fg wiki), in order to be able to optionally ensure that only certain subsystems are allowed to write to a property (the multiplayer subsystem in this case)

     

  • Nobody/Anonymous

    Nobody/Anonymous - 2008-02-07

    Logged In: NO

    I would just like to add that I truly appreciate the loosely-coupled nature of the multiplayer subsystem, simply because it comes with so much power and flexibility: I can easily change all sort of runtime settings locally, while not affecting other traffic, but still getting to see it in the simulator. Also, I like being able to pause the sim, reposition the aircraft at runtime easily and do pretty much anything else, while still remaining connected to the multiplayer server.
    Therefore, I ask you to please keep this power and don't make sharing runtime state mandatory, if state sharing among clients is implemented it should really be totally separate from the multiplayer protocol itself, so that clients only get a reference/url to such a state server from the multiplayer server and can then elect to use it or not.

    I feel that this would also be important to help the multiplayer protocol to remain lean and efficient, i.e. to avoid unnecessary bloat-after all, the most crucial information is indeed position/speed and animations, everything else should be optional, and really doesn't need to be updated as often/as much as the positional information.

     

  • Nobody/Anonymous

    Nobody/Anonymous - 2008-02-27

    Logged In: NO

    such a filter that optionally allows multiple different scenarios to be hosted by the same server would also be neat to allow cleaner separation between sessions using aircraft such as ufo,ogel,santa, bluebird etc

     

  • Nobody/Anonymous

    Nobody/Anonymous - 2008-03-03

    Logged In: NO

    if this is meant to be about different simulated "worlds" or "contexts", it is important to keep in mind that this may be as simple as maintaining a vector of extra attributes for each clients, i.e. clients having the same attributes may directly see each other.

    That way, multiple simulator contexts could be run on the same server, but only clients would only receive updates from other clients having the same attributes set.

    This could be as simple as maintaining a std::vector<std::map<std::string,bool> > or some other sort of list, so that client attributes can be maintained and queried.

    Given that this would be data that is unlikely to change regularly at runtime, this would warrant an extra message to allow clients to set their attributes, so that it would be possible for a client to selectively subscribe to certain data by setting server-side client-specific attributes (i.e. "only-real-aircraft" or "only-civilian-aircraft") which remains then active until it is reset/modified, which could even be facilitated at runtime by sending a new valid message to the server.

    This would then also allow for military aircraft to feature support for destroying scenery features and aircraft which have the corresponding attributes set (i.e. are not only visible by such aircraft but are also mutable).

    From the server side, the server might want to support another message to query valid attributes, so that a client is presented with a list of tokens that can be modified, possibly with an integer appended to illustrate how many active users are sharing these attributes (i.e. as in "active players in full combat scenario").

     

  • Nobody/Anonymous

    Nobody/Anonymous - 2008-03-12

    Logged In: NO

    regarding comment #1 (and some of the later ones): such issues could be easily addressed if the currently discussed publish/subscribe mechanism doesn't only work for the direction client->server, but also vice versa - so that servers may actually subscribe to client-side data (i.e. normally all aircraft-specific properties), but also so that servers may specifically subscribe to client-side state that should normally not be altered, or only be altered under certain circumstances. So that such properties would not really become "remote managed" but at least "remotely monitored"

     

Log in to post a comment.

MongoDB Logo MongoDB