Development Blah

All other topics around Descent and D2X-XL

Moderators: Frustikus, simX, Aus-RED-5

User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Multiplayer bugs fixed

Postby karx11erx » Sun Jun 29, 2014 10:34 am

Today is a good day for playing multiplayer games with D2X-XL ... again! ;)

As I had written above already, I had found out that D2X-XL's multiplayer had stopped to work through some not so nice comments about D2X-XL on the internet.

I had some time to look into it this weekend, and to my dismay the reports had been right. The last time I had been playing multiplayer games with D2X-XL, everything had been working really well, but that had been quite a while ago (at least two, maybe three years). So I started looking into the code. Just getting a handle on the cause of the problems proved to be a challenge. Debugging multiplayer code is pretty difficult, since so many things happen simultaneously on different game clients and often are time critical; so halting one client on a breakpoint could lead to the problematic constellation not happening.

Finally I found out that the problems are mainly rooted in Descent clients quickly disconnecting other players if they didn't receive some data from them in time. However, this is a scenario that is pretty frequent particularly when players are moving from one level of a multi-level mission to the next. If a client was loading a level, he could quickly exceed the 10 second timeout of other clients listening for it to send a data packet. This problem was exacerbated by players being able to stay in the previous while other players already entered the next one. All that needs to happen for that is that one player hasn't yet passed the mine exit, while another one already has left the end level score screen and has loaded the next level. Players could also die in the mine or still be in the mine exit sequence (the rendered or cinematic exit tunnel flight sequence) while others were already proceeding.

It didn't help that the end level score screen had its own player timeout handling, with different timeout values than the regular timeout handling.

What made such situations worse was my adding (or changing) handling disconnection of the game host. In that case, another player rather quickly took the role of the game host. Now if all other players suddenly disconnected due to their level transition while a client was in the end level score screen, that client made himself the game host, rendering him incapable of reconnecting to the actual game host and hence the entire game in progress. D'uh.

The solution for the entire problem was to make the connection checks independent of general program (main thread) execution by putting it in a separate thread that would keep running regular basic network activity even if the main thread was busy. The new networking thread will periodically send a ping request to all other players in the game to let them know the local player is still alive, and it will process such messages from other players to keep them from timing out locally. It will also take over timeout checking for the end level score screen, properly handling player timeouts and disconnects.

The game host availability test will only switch game hosts if the current game host has not just timed out, but completely disconnected.

Since the networking thread is running all the time independently of other program activities, timeout and disconnection detection now is much more reliable and doesn't have to make questionable and unreliable assumptions about the state of other players during level transition.

All in all these changes will lead to a much more stable connection handling during multiplayer games.

I am still in the process of testing a few of these changes, but a new program version should be available later today.
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Not done yet ...

Postby karx11erx » Sun Jun 29, 2014 6:41 pm

Looks like I am still not quite done with fixing multiplayer connectivity ...

First of all it has turned out that I had messed up the end level score screen's behaviour. Players should wait there until every other participant of their multiplayer game has arrived there, too. The only way to prematurely leave it would be to quit the game altogether.

My introducing multi-threading in the networking has brought a bunch of problems with it I hadn't foreseen, too: Certain calls now need to be thread-safe. Fortunately this only concerns a few key areas.
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Multiplayer woes continued ...

Postby karx11erx » Mon Jun 30, 2014 2:37 pm

Looks like multiplayer connectivity is ok now. Players obviously get out of sync though, and the more objects a level contains, the sooner that happens and the worse it gets.

There are several possible reasons for that I can think of:

Possible bugs

Just checking that with a few particularly error prone network messages.

Different results of random controlled operations relevant in this context (e.g. spawning of child robots)

The game host enforces usage of identical random seeds on all clients. I haven't investigated whether some local seeding might still be applied in the process of a match.

A consistency check I have introduced that may produce different results on different clients

This should only happen as a result of random seeds differing between clients.

Packet loss

All data is sent using the UDP protocol, which has no guarantee that your data will eventually reach its destination. I also don't know how the OS's UDP services handle the situation of a lot of packets arriving which are not fetched immediately by the application. Does some buffer overrun occur, that is handled by newer data overwriting older packets?

To avoid buffer overrun, I am currently moving all network packet handling to a dedicated thread that will poll the low level networking interface sufficiently often and will buffer the packets received until they can be processed.

Packet loss is a different story though. I am considering moving non time critical packet traffic to using TCP/IP. This would e.g. be suitable for initially sync'ing new players with the current state of the match, as new players will not enter the match until sync'ing has been successful. Since for the game host sending sync data is time critical (due to him/her usually being playing), I need to make sure to make TCP/IP operations non blocking on the game host.

The game also does on the fly sync'ing. I still need to look into its details (long time no see ;)), but that could probably be done via non blocking TCP/IP operations too. The general problem with this is that sync'ing huge amounts of object and game states can take so long that the ongoing match can significantly change these states.

A difficulty of using UDP and TCP communication side by side is to keep the proper sequence of packets.
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: Development Blah

Postby karx11erx » Tue Jul 01, 2014 8:11 pm

I have been doing a lot of the things I have described in my previous post, and while doing it, have discovered a few issues that may have caused the game worlds to differ between clients.

I have also discovered quite a critical bug in object handling. The background of that is the D2X-XL keeps several linked lists to group objects by type and quickly access objects of the same type. I had introduced that because the basic data structure objects are kept in is a table (vector), and there can be significant gaps between two valid objects in that table. Doing an operation on objects of a certain type means having to scan the table until all objects have been found and handled, and with lots of gaps between them that is rather unefficient. Too dumb the list handler had a bug that could cause live objects to disappear from the lists ... :roll:

Another thing I have done is to make listening to the network adapter for incoming game data packets independent of the main thread. This means that regardless of how slow D2X-XL runs on a computer, it will always fetch all data packets sent to it, and not drop any just because the time span (which is the frame time) between two adapter polls is too long. It also means that D2X-XL will not miss packets anymore that are sent while the main thread is completely busy and unable to poll the network adapter at all. Before that change, D2X-XL only polled the network adapter once each frame, and the longer a frame took, the more likely packet loss due to buffer overrun was.

After this started to work, I expanded this model to defer sending of huge batches of data, which is something that mostly happens when the game host synchronizes a new player with its game state. Until now, the speed of this was depending on the game hosts frame rate, too. Now, the game host will simply push all synchronization data to a queue, and when it is done will tell the network thread to send that data while proceeding with the main thread. The network thread will currently poll and send data at a time interval of five milliseconds (1/1000 s), which should be fast enough for every thing other Descent clients throw at it or demand from it. Being able to push sync data so quickly also means that clients may sync faster and have less of a chance to get out of sync with the game host during a lengthy sync process where the host player is changing his game state due to playing the game. In the past, this could lead to other players not being able to join at all - particularly if they lost packets and the game host had to restart the sync process.

To do all this, I have created a bunch of nice new classes handling data packets, packet queues and the network thread tasks. I have also overhauled and unified the network address types and have introduced a network address class. This makes handling the code much easier and straight forward.

Btw, re-syncing in case of a sync error had been optimized by me in the past as well. The original game just restarts the complete sync process. D2X-XL clients are able to tell at which data packet they got out of sync, tell the game host, and the game host will only start transmitting sync data beginning at that packet. Particularly for huge levels this can mean the difference between being to able connect despite a shaky internet connection and disconnecting.

Of course, I will still have to do a lot of testing, and I haven't even been starting to actually try and reproduce cases of massive de-syncing in an ongoing game, which apparently very much likes to happen when a player with a huge weapon loadout explodes or when a destroyed robot spawns child robots. First things first though. :)
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

More bugs than you can shake a dead robot at

Postby karx11erx » Thu Jul 03, 2014 6:32 pm

Heya!

More bugs from multiplayer code hell have reached out for me after my recent multiplayer code fixes, and boy do they have long arms! :shock:

I have found two bugs that had quite a massive impact on multiplayer matches: One where a destroyed player ship didn't drop anything on the clients not owning that ship, and another one where robots just stayed passive when facing players that weren't the game host. Both were bloody hard to track down.

These weren't the worst issues though - that were cases where I removed certain conditions in the code to ease debugging and broke well behaved code that way. Add to that high speed concurrent code execution, and you still cannot imagine what that meant in terms of nailing such issues down.

Multiplayer clients are talking to each other now, but there still seem to be a few issues I need to iron out. Getting closer though. :sweat:
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Working my ass off ...

Postby karx11erx » Fri Jul 04, 2014 11:31 am

I have literally been working my ass off this week trying to fix D2X-XL's multiplayer code, and I have identified and removed a couple of issues in it, one of them being a rather critical one where powerups dropped by a robot weren't reliably replicated on all clients. While tracking down that bug I had an interesting insight btw: A robot must never drop more than four powerups or child robots in total in multiplayer games, because that is the limit of what is transmitted by the client controlling the robot's destruction to the other clients ... If a robot has instance specific drop items specified, it will also not drop any of its type specific items.

"Huh, whaddya mean?" :think:

A robot "instance" is a single, existing robot of some robot type. Robot types are the various kinds of robot (Class 1 Drone, Small Hulk, Lou Guard, etc.). Descent allows to specify random drop items for robot types: For instance, every Diamond Claw will drop between zero and three shield powerups. However, when building a level and placing robots in it, you can pick any of the robots placed there (the pre-existing ones when loading a level so to speak) and make each of them individually drop items. You could e.g. pick one of the Diamond Claws you place in a level and make it drop three ITSC robots. If that particular Diamond Claw gets destroyed, it will not drop its zero to three shield powerups, but exactly those three ITSC robots specified for it.

Now older missions may have never exceeded that four drop item limit, but D2X-XL missions do, and I never put a proper cap in the multiplayer code to limit the amount of drop items for such robots in multiplayer games. So I have done two things here:

  1. Capped the number of robot drop items in multiplayer games
  2. Increased the cap limit for D2X-XL games to fifteen


Another thing I have made is to move network communication (listening and sending) into a separate thread now. This allows better control of PPS (packets per second) sent and reduces the chance of missing packets when the main thread is busy. It also allows more fiddly tricks with packets that have been received, like keeping them for a short while and resending them if necessary.

Unfortunately that doesn't seem to have been the end of the story. When testing the multiplayer code, I still had regular issues of robots dieing on one client but not on the other. Right now, I cannot tell whether this is due to packet loss or more bugs in network communication handling of D2X-XL. It is pretty hard right now to exclude any of these possibilities. One problem I was (and maybe still am) having here is that I am testing both clients on the same computer (which works well on my main development machine), using the local network interface (127.0.0.1) to communicate. However, I have found that when sending packets too fast, significant packet loss occurred - during computer-internal communication! :horror: :think: I still kept experiencing packet loss after reducing PPS, and it took me the better part of an evening to find out that I had circumvented PPS limitation by excluding some code to make debugging easier ... :wallbash:


So the next thing to do is to add measures to detect packet loss to the concurrent network communication handling. Descent already has that, but it works on a higher level than I need it. If the problem indeed is packet loss, then I am having a problem: Due to the nature of the networking protocol used (UDP/IP), lost packets cannot be retrieved. In this case, I would either need to introduce some light weight handshake mechanism for "important" packets or switch to TCP/IP for these - the latter with all consequences for synchronicity of game states.

Bleh. :?
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: Development Blah

Postby karx11erx » Sun Jul 06, 2014 1:03 am

So I was writing and debugging networking code for the entire last week, spending all time I could spare (and some on top of it), weeding out all the bugs the new code had before I could even get down to the core problems. The worst problem of all was some weird packet loss on my single computer, two game client setup. It was totally unexplicable for me. It took me days to understand that polling the network adapter for packets in a background thread running at full speed on a system with a 3.6 GHz CPU and 1.8 GHz low latency tripple channel RAM would bog it down so much that half of the packets a client tried to send got lost. Wouldn't have been such a problem with a single client setup, but as my setup is very comfortable for debugging I chose not to use two computers (which I have ... I actually have three).

This bug was the "punching yourself in the face long and hard" kind. :P

Anyway, connectivity is looking good, and I have identified a couple of issues in the networking code, but I still manage to desync the clients rather easily by blowing up a few robots. The question is whether that happens due to a bug or due to packet loss. I hope it's the further, because that would mean stability can be achieved here.
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Hitting myself over the head :P

Postby karx11erx » Mon Jul 07, 2014 12:20 pm

Regarding D2X-XL, the last 10 days or so were the hardest in the last couple of years for me.

While tracking down the multiplayer bugs I knew of, I rewrote and created a lot of code, introducing new bugs I had to hunt while doing so. Some of the code did not make it into the actual release, which I am a bit sad about since I liked it so much: The concurrent network communication processing has turned out to cause massive packet loss at least in my local test setup with two D2X-XL clients on the same computer connecting via the local network address (127.0.0.1). D2X-XL works great with its original implementation of the network communication, so I am happy enough with the result of my work.

All the effort I have poured into D2X-XL has had its benefits anyway: I have identified and eliminated a couple of critical bugs, that could and did disturb proper match execution. Some of the bugs actually were of the "How could this ever work?" kind. :think:

As it turned out, the main coop issue after the level transmission failures had been fixed were out-of-sync problems when a robot got destroyed and dropped powerups and/or other powerups.

One of the causes for D2X-XL's faulty behavior was home-made: It was the result of D2X-XL's PSALM not properly keeping track of which game items were allowed in a level. Btw, do you remember that term? Probably not. It's the Powerup Spam And Loss Minimizer. Awesome acronym, eh? Sounds really professional, I like it. :mrgreen: The PSALM keeps track of all powerups in the game, be it in the mine or on ships and detects whether there are too many or too few powerups; In that case, it removes excess and replaces missing powerups. When a robot dropped more than one powerup, the PSALM didn't sufficiently increase the permitted amount of those powerups in the level and subsequently suppressed the creation of those powerups. This bug mainly was responsible for too few powerups being dropped, not necessarily for out-of-sync problems.

The other cause lay in the original Descent code. In multiplayer, each object has an owner. That is the player on whos system the object was created or by whom it was destroyed. In case of a robot being destroyed, the object owner will initiate the robot's destruction and the dropping of powerups on his system and sends messages about that to all other clients. These will only destroy the robot and drop its powerups when receiving the corresponding messages. However, dropping powerups has a twist in Descent: If a robot drops other robots, there is a chance it also drops some shield powerups on top of them. This means that a robot can randomly drop more objects than specified in its drop information. A bug fix I had made in the original code here caused D2X-XL to potentially drop more extra powerups than the original game. That fix had been necessary, but I hadn't overseen all of its implications, so I had introduced that flaw.

(Regarding that old bug fix: Each dropped powerup needs to be taken some extra care of, but the original code only did so for the last in the list of items dropped by a destroyed robot.)

The problems with that is that Descent has a limit as to how many drop items can be sent to the other game participants. However, the owner of the operation does not regard that limit, he only enforces it for the other players. I have done two things here: First of all, the player creating the powerups will not create more powerups than can be transmitted to the other players in multiplayer games. Second, I have raised that limit from four items in standard Descent to fifteen in D2X-XL games.
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Improved multiplayer synchronicity

Postby karx11erx » Mon Jul 14, 2014 11:51 am

Recently, I had become aware of the Descent Retro Mod, which is authored by Drakona, and had come to know that it had fixed various bugs in the original Descent code as well as in the Rebirth code the Retro mod is based on. Investigating this led to the insight that D2X-XL only suffered from one of the bugs identified there, which is stemming from the original Descent code, and which could cause problems with the game's collision detection. I fixed that bug and could even give some hints to a more elegant solution for the problem than the one originally implemented by Drakona. The other bugs had all been introduced by the Rebirth project, which I find quite amusing given that Rebirth had always been hailed as the Descent mod that was most true to the original and working best in multiplayer.

...

Another thing I had come across when looking into the Retro mod was Zico having implemented a handshake mechanism for important messages to make sure no desync'ing occurred because some of these were dropped. The Retro mod will disconnect players not acknowledging the receipt of such messages in time. I had read about Zico thinking about implementing something similar on the Rebirth forum. After having looked into Drakona's work I understood that Zico was rather considering back porting her fixes and improvements to Rebirth.

Initially, I had not deemed a handshake mechanism a good idea because it seemed to be too unflexible, and had considered a different, more flexible approach to keeping multiplayer clients in sync. However, my idea didn't prove viable due to the potential mass of data having to be transmitted between the clients, so I went back to the handshake idea. I started to like it at a second glance, so set out to implement it. That task proved to be really simple and easy to integrate with D2X-XL's networking code, and after about 12 hours of work put into it I had a working version of it.

So in future D2X-XL versions, the client originating an important event (like picking up or dropping a powerup, destroying a robot, etc.) will store the related message in a list and keep it there until it has grown too old or all recipients have confirmed that they have received the message. Until that happens, the originating client will periodically resend the message to all other clients who haven't confirmed receipt of that message. In order to avoid clients processing such a message several times because their confirmation message has been lost, the clients will keep a list of confirmed messages and drop list entries when their maximum life time has been reached, which correlates with the maximum lifetime of the message to be confirmed on the originating client. D2X-XL will only resend important messages to those clients that haven't confirmed their receipt, and a confirmation for an important message is only sent to its originator.

Important messages (i.e. messages that are resent until a receipt confirmation has arrived) are:

  • Dropping a powerup
  • Picking up a powerup (i.e. removing it from the mine)
  • Destroying a robot
  • Dropping a destroyed robot's contained powerups or child robots
  • Destroying a player ship
  • Dropping a player ship's equipment and weapons
  • Jettisoning a player weapon
  • Destroying a reactor
  • Creating a robot (robot generators, boss robots spawning minions)
  • Creating a powerup (equipment generators)
  • Kill score information
  • Opening a door
  • Activating a trigger
  • Changing a wall (including forcefields)
  • Picking up a flag
  • Dropping a flag

Such messages do not occur very often, so the handshake mechanism will not overflow the clients' internet connections. It is also not critical to receive them with a certain (small) delay. Of course this cannot stabilize a chronically bad connection between multiplayer clients, but it will help to iron out occasional hickups in their connections. For multiplayer games this means significantly improved synchronicity in the future; And it didn't even take a great effort on my side to realize this. I had of course been thinking about how to implement this handshaking mechanism for a while, so when I started coding I had both the concept and the important details ready in my mind.

I have to say that I really love how this works. :laola: :laola: :laola:
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: Development Blah

Postby karx11erx » Tue Jul 15, 2014 12:45 pm

When asking Drakona about some details of the Retro mod's package loss prevention system, she explained to me that it had actually been developed by Zico and that the game host handled this entirely. I don't know any details of this, so I can only make assumptions: Since events can be triggered by any multiplayer client, this means that they need all to be passed through the game host. What if the game host doesn't receive such a package? This approach is prone to errors due to packet loss itself, and also potentially introduces additional packet travel times.

As explained above, D2X-XL has a different, peer-to-peer (P2P) approach: Here, the client causing the event (which is the one notifying the other participants of the match anyway), will resend the corresponding message until it has timed out or every other client has confirmed its receipt. This means that packet loss prevention starts right at the source of these messages, without a chance that a lossy connection might corrupt the entire mechanism.

Since the traditional Descent code isn't multi-threaded, update frequency of the packet loss prevention system also is frame rate dependant in Rebirth. In D2X-XL, it is not: The packet loss prevention system is updated every millisecond (i.e. at 1000 fps) by the networking thread running independently from the main thread. This means that even if the the main thread should lag, messages will be resent and confirmed in time.

Assuming my assumptions about the packet loss prevention implementation in Rebirth are right, the P2P approach is the safer and potentially better performing one, as the game host's internet connection doesn't present a bottleneck for it.
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: Development Blah

Postby karx11erx » Wed Jul 16, 2014 2:41 pm

D2X-XL v1.17.57 with the new packet loss prevention system ("PLOPS"? ... :P) is out!

I have ended up securing a lot more messages than listed below. However, all of them are sent rather infrequently, but are critical for a match's consistency. In case of problems, please post a bug ticket containing the log file created by D2X-XL when playing that game session.

The new version contains a few more bug fixes, a few of them under the hood, that further increase the program's general stability.

Have fun with it. :)
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Now that I have time again ...

Postby karx11erx » Thu Jul 17, 2014 10:30 am

Right now, D2X-XL v1.17.58 is available, and each and every bug it has been criticized for in the last months has been fixed, be it hires texture management, multiplayer connectivity, or multiplayer game consistency.

Now that I have learned a lot about the Rebirth based Retro mod, I want to come back to a statement from a discussion thread on Steam:

In particular, Rebirth (with Retro mod) has a lot of multiplayer-focused bugfixes that make it suitable for high level competitive play, which XL is lacking.


Actually, the Retro mod has fixed a bunch of bugs which Rebirth had introduced and which have never even been an issue in D2X-XL.

Rebirth has a mechanism to reduce loss of important game messages which is potentially inherently insecure and introduces additional lag due to the game host handling it exclusively and the other clients having to route such messages via the game host. The Retro mod is actually having problems caused by this mechanism.


PLOPS (Packet LOss Prevention System)

D2X-XL has a similar mechanism, but like Descent's entire multiplayer messaging it is working fully peer-to-peer. It does not introduce additional packet travel time, and it secures messages starting right at their point of origin, which is the client originally generating them. Still, while such a system can ensure game consistency on internet connections that are generally stable, it will fail on connections that are notoriously bad.


PSALM (Powerup Spam And Loss Minimizer)

Therefore, D2X-XL has additional measures to prevent too many or too few powerups being present in multiplayer matches by keeping book of all powerups both in the level and on player ships, respawning missing powerups and removing excess powerups in case game consistency was broken due to packet loss.


COME (COncurrent MEssaging)

To make sure D2X-XL's multiplayer messaging does not depend on varying frame rates of the game clients, it runs on a separate background thread that will poll the network adapter at 200 fps for incoming messages and store them in a queue for subsequent processing when the main thread has time for that. This means that even at a very high incoming message rate, D2X-XL will not lose multiplayer messages due to the network adapter getting overrun by them because they aren't fetched in time. The networking thread will also supervise important message delivery at 1000 (one thousand) fps. That is something no other Descent mod offers.
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Observer mode

Postby karx11erx » Thu Jul 17, 2014 2:51 pm

Hey guys,

what do you think of an observer mode for multiplayer matches? One where you can either freely roam the entire level, or follow another player (only players from your own team in team games ofc)?

:mrgreen:
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Observer mode!

Postby karx11erx » Sat Jul 19, 2014 4:41 pm

So another D2X-XL version is out, and it has an observer mode for multiplayer games!

Check "enable observer mode" in the gameplay options menu to activate it. When it is active, you will re-enter the level in observer mode after having been killed. Initially you will be able to freely roam the entire mine. You will move at double your normal speed to make watching duels and changing your position quickly. When pressing the space bar, you will be placed behind another player's ship in chase cam mode and will be able to watch him play. Press space bar again to switch to the next player and finally to free roaming mode again. Press Escape to enter the match as regular player.

In team games you will not able to roam the mine freely -you will only be able to watch your spawn area. You will also only be able to follow your own team's players.
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: Development Blah

Postby karx11erx » Mon Jul 21, 2014 12:40 pm

So I was finally trying to play a few matches with my son over our home network, only to find another bug everytime we had a go at it. Some bugs had been introduced by me, but one that made me particularly "happy" :evil: had been introduced by steel01 when he tried to get rid of some g++ compiler warnings. These warnings had actually been rather pointless, but steel01 was on a crusade for 100% perfect, warning free code. Well, perfection seems to be relative. He got his warning free code, and I got a broken multiplayer messaging.

That is the result of some overly eager coding newbie (from my perspective of 25 years professional coding experience, most programmers are coding newbies ;) ) believing he knows everything better, and promptly starts speed coding and hacking their ingenious ideas in no time into some code they hardly understand ... causing weeks and months of debugging afterwards. But they were so fast! In the beginning.

RRRRROOOOAAAAAAARRRRRRRRRRR!!!!

:lol:

Anyway, I believe that I may have finally really weeded out each and every flaw in D2X-XL's multiplayer code. The only thing that could be added on top of that would be some measures to re-establish game session integrity in case it had been compromised due to packet loss too massive to be compensated by what D2X-XL already does to compensate it.

Since I am not having the impression that many people are playing multiplayer games with D2X-XL right now, I will keep that for the time when people actually will and need additional networking stability in D2X-XL.

Return to “General Discussions”

Who is online

Users browsing this forum: No registered users and 3 guests