Forum Replies Created

Viewing 15 posts - 526 through 540 (of 549 total)
  • Author
    Posts
  • in reply to: Turns Per Round . . reduce number? #12591

    hobbesme
    Participant

    @hoopy frood wrote:

    How about a new option when setting up the servers that would allow you to automatically set turns/per round based maybe on howmany people start the game.

    That way it would automatically adjust each game?

    I’ve had that idea as well.

    Unfortunately, it fails in real games since the number of players DRAMATICALLY changes from the start, end, & during each game — anywhere from 2-16 players.

    I’m assuming by your implied player-number dynamics that if a low number of players start a game, more rounds will be played. However, if more rounds are played, then it provides a long game where many new players can join & consequently slow down the game.

    If a high number of players start a game, less rounds will be played. If all but two players drop out, then the game ends quickly (however this is not nearly as bad as the previous paragraph scenario).

    Also, it would be folly for the game to dynamically decide at the end of each round the number of more rounds to play based on the current or past number of players in the game. It would just get insane trying to develop a reasonable algorithm to implement this.

    It’s also not feasible to lock the number of rounds based on the starting number of players — and then to block other players from joining. This would be very irritating to players that wish to join.

    In theory, dynamically determining the number of rounds to play based on the number of players is a good idea. In practice, the number of players that connect/disconnect/lag/get-booted changes so frequently within any single game, that it just wouldn’t work well.

    in reply to: Turns Per Round . . reduce number? #12589

    hobbesme
    Participant

    @willis wrote:

    Yes thank you hobbesme for clearifying my opinion, I should have worded myself better.

    You’re welcome; I was just providing my analysis, not trying to correct yours or Ebonite’s.

    @willis wrote:

    when … down to the final 4-5 turns … people are stalling, maybe someone is under a pile of dirt, or on a weird angle cliff … IMO if a person cannot make the kill by this point and time, so be it, they dont deserve to get the chance.

    1) I totally agree with this for the TEAMS server only.

    As a TEAM, if you can’t kill the other team off — no matter what the circumstances — in approximately 10 rounds or less, oh well; no team wins the round, move on to the next round.

    1.a) Willis suggested reducing the teams server’s number of moves per round to 10.
    1.b) Ebonite suggested 12 moves per round.
    1.c) NoMoreSteve suggested (I think) 7 rounds per game (see #2.b below)

    1.d) Either 10 or 12 moves per round sounds fine to me.

    The teams server rounds are inherently faster since two teams are working cooperatively to eliminate all the players on the opposing team. Thus, the rounds end faster than non-team rounds since there is a concentrated effort by both teams to eliminate all opposing players AND ALL players do not need to be eliminated — only all players on the opposing team.

    For the most part teams server rounds last 10 minutes max — sometimes as low as 2 minutes for first round carnages! Whereas non-teams rounds most often last 10-20 minutes, as long as 25 minutes!!

    Although the teams server rounds are MUCH faster than non-teams server rounds; the total number of game rounds for teams server is 5 whereas non-teams is 10!

    The obvious time-disparity is that teams server games are very quick — fewer, quicker rounds per game; while non-teams server games are VERY long (occasionally 2 hours).

    2) Although I do not suggest reducing the number of game rounds for non-teams, I do suggest increasing the number of rounds per game for the teams server.

    2.a) Maybe not so high as 10, …
    2.b) but more like NoMoreSteve’s Lucky Number 7.

    Just something more than 5 to allow the underdog team the possibility of overthrowing their oppressors for a game win.

    @gcamp wrote:

    1. Reduce the team server turns per game (to 10?)
    2. Reduce the time per move for the no bots server (but leave the buy time the same).

    1. As stated in 1.a, 1.b, 1.d above, 10 or 12 moves per round for teams server seems reasonable.
    2. Ebonite’s exact quote was :
      @ebonite wrote:

      I asked for the 10 second extension per shot on the team server, and would like to see it remain so, but I missed the discussion on extending the regular server by 10 seconds per shot, and would like to see it reduced back to 35

      I assumed Ebonite meant the non-teams, no-bots server when he said “regular server”. Is this correct, Ebonite?

      If it IS correct, then I agree with Ebonite to reduce the shot time to 35 or 40 seconds on the non-teams server ONLY. The teams server should remain at 45 seconds since team players need to team-chat in order to prepare their collective team shots.

    in reply to: Turns Per Round . . reduce number? #12584

    hobbesme
    Participant

    @willis wrote:

    moves per round [reduced] by … at least 5?

    @nomoresteve wrote:

    Typically, I like long games … save up some $$$ and get the cooler stuff in later rounds.

    I think Willis meant the number of moves per each round, not the total number of rounds per game.

    I think that 15 is WAY too many for TEAMS server since one team or the other should be able to demolish the other team in 10 moves or less. If not, both teams are either awful or are stalling.

    It’s harder to limit the non-teams server to 10 or less rounds since (like tonight) we can have 15+ people. Even at an average kill every two shots & each player targeting a unique player, that’s approximately

    log[2shots](16 players) >= 8 moves

    And that’s only IF all players kill every two shots targeting unique players (BTW, I know this inequality doesn’t exactly represent the scenario described, but it’s a close approximation).

    Thus, for non-teams server, more rounds may be a necessary evil — even if it can sometimes drag on & on.

    Speaking of which, our game with 10-16 players lasted 1:40!

    in reply to: dragon tank! #12573

    hobbesme
    Participant

    Awesome.

    I’m amazed at you graphic designers/artists.

    Good job.

    in reply to: Another Idea #12578

    hobbesme
    Participant

    @hoopy frood wrote:

    I believe real time of day lighting would be great. As the round progresses from morning to noon to night Etc. Moon phase to? Total darkness even on the plan view would be cool and require a flare to illuminate other tank positions. Military style parachute flare?

    I love this idea. Different mapboards already have different lighting settings — some have clear skies with direct sunlight; some are more overcast; some are twilight; etc.

    But a dynamic environment that changes as each turn round proceeds would be pretty cool.

    The only problem with darkness (total or partial) is that HUD displays pretty much point out where each tank is. Even with darkness, HUD displays would still give away exactly where each tank is.

    The ONLY thing that might matter is that in total darkness you might know where each tank is, but NOT know what type of terrain it is on anymore. I.e. it could be on a peak, in a valley, in a hole, etc. So, you might know where to shoot, but not what type of weapon to shoot (missile versus roller versus digger, etc.).

    in reply to: Very impressed! But… #12565

    hobbesme
    Participant

    @john DiFool wrote:

    the AI is pretty hopeless

    Yep; AI isn’t great.

    Therefore, play offline to refine your skills; play online against us pros.

    @john DiFool wrote:

    All the camera angles are very well implemented … but have trouble with :

    1. Seeing enemies …
      1. perched on very high hills
        OR
      2. covered by water
    2. Needs some sort of replay feature
      1. I can follow my own shot … but then I don’t know who may have been shooting at me
        OR
      2. I can use one of the wide-angle views, but then I lose the ability to fine-tune my shots.

    1. Don’t know your problem with #1a; but on Windows clients, you can press & hold the ‘ALT’ key to see through mountains, undergroud, & underwater.
    2. A lot of players, including myself, would like to see this.

      However, I not only want to see a replay — I’d like the ability to SAVE a replay in order to replay rounds offline.

      And the replay should include the entire STATE of the shot, not just a visual replay of what you viewed from the camera angle you selected. That way, you could replay the shot over & over from different camera angle to see yours & others’ moves.

      We could relive our best shots & learn from oour worst moves.

    3. Also on Windows, press ‘c’ to bring up a shot camera window. It follows your shot just like the first-person shot mode, but inside a small window. This allows you to view anywhere else on the mapboard on the whole screen.

    That’s my two cents. Good comments though.

    in reply to: keeps crashing #12425

    hobbesme
    Participant

    @anonymous wrote:

    your all a whole bunch of useless ***** losers who cant help anyone out.

    I don’t know who is the most loserishest :

    1. We “whole bunch of useless … losers who cant [sic] help anyone out”

      OR

    2. The anonymous loser who can’t see all the posts where us losers did help each other :
      1. http://www.scorched3d.co.uk/phpBB2/viewtopic.php?p=5250&highlight=#5250
      2. http://www.scorched3d.co.uk/phpBB2/viewtopic.php?p=5237&highlight=#5237
      3. http://www.scorched3d.co.uk/phpBB2/viewtopic.php?p=5224&highlight=#5224
      4. etc. etc.

    I thought that our community of players was very helpful with each others’ gaming problems. Maybe I was wrong.

    But who’s the most loserishest? Our community of players or the acting-like-a-13-year-old lamer who anonymously curses our community?

    You decide.

    @anonymous wrote:

    **** you united kingdom of crap.

    I have no idea what that means.

    in reply to: chat stuff #12405

    hobbesme
    Participant

    @bobirov wrote:

    That’s what I was referring to about the little reply and retell system. Its pretty standard in some MMO games.

    I love this idea. However …

    @bobirov wrote:

    It isn’t perfect or anything but it is much better than having to type out the name of the recipient EVERY time you want to send a private message to someone (especially when names are long and complex and there is no “partial typing of names” allowed).

    As Bobirov points out, long & complex names would be a HUGE problem in Scorched3D.

    Don’t get me wrong, I love that Scorched3D permits any & all ASCII characters to be used in player names (except for the special case of the NULL name — no characters at all, just the NUL ASCII character; very annoying, especially when listed on the stats page since you CAN’T select the NULL name to see his stats page!).

    But even with a reply/retell command, the long & complex names for some players would be painful to use the sayto command! For instance, shockwave’s recent player name has included some run-time-error operators like :

    .*=* sHocKwaVe *=*.

    I mean, who’s really going to type that or other more complex names for a private message, huh? But I guess that’s their fault if they have a complex name & consequently never receive private IM messages! 😛

    in reply to: chat stuff #12401

    hobbesme
    Participant

    @cbx550f wrote:

    If you hit the backquote (ie: same key as ~ on US style keyboards) it brings up the console which shows chat history (and kills etc). Page up/down works in there too.

    Although I use this feature extensively to catch up on chat that has already scrolled off the main screen, there is one problem with the back history of chat in the console window :

    Every time new chat or event text is added into the console window, it automatically jumps back down to the “bottom” of the console where the new text has just been added.

    This can be exceptionally annoying if you are page-up scrolling to older text entries. If you want to read a previous comment that has scrolled off the page or one from a few minutes ago, it is near impossible to scroll back that far as new player or game text will continue to automatically jump back to the “bottom” of the console text.

    This is a very common behavior for consoles & IM clients, but it is very annoying. If there is an easy way to remove this behavior from the console, I know I would appreciate it.

    Also, IMO there is a major omission in the console text — game winner & final game stats.

    For instance, at the end of each game, it says in graphic text, “[PlayerSoAndSo | Red | Green] Team is the Winner” & also brings up the final game stats window.

    However, this ending game information is NOT added to the console. If you happen to miss it or would like to read it for longer than the default display time, you can’t.

    And since most every other game message is added to the console text history, it seems odd that this important information is NOT added to the console text history.

    in reply to: Ground Based running water #12381

    hobbesme
    Participant

    @hoopy frood wrote:

    1. How about ground based running water on some maps.
    2. Water could be diverted with hits to it.
    3. Maybe water could do damage if redirected to an opponents position.

    I think all these ideas rock. I’ve also thought about rivers & waterfalls. I think all these ideas would be visually & gameplay enhancing.

    in reply to: This game is so unbelivable boring #12388

    hobbesme
    Participant

    How about those of us that enjoy Scorched3D as is, continue to show our support by :

    1. Playing the game with our community of fellow Scorchers
    2. Sending money to the developers

    Those that don’t enjoy the game :

    1. We wish you the best in finding other games that suit your fancy
    2. Kiss our MIRV on your way out
    in reply to: error/bug it won’t stop repeating #12369

    hobbesme
    Participant

    @bobirov wrote:

    I have seen this once before and I think it is somehow related to the landscapes that are in use.

    It is absolutely related to the selected landscapes.

    The following are my observations regarding selected landscapes & subsequent

    'ERROR: Failed to parse file
    "c:/documents and settings/user//.scorched3d/singlecustom.xml"
    Parse Error, Line xxx Col:yyy Error:not well-formed (invalid token)'

    errors — henceforth ‘Parse File’ error(s).

    I am running Scorched3D V37.1 with the following landscapes available :

      oldstyle
    lowlands
    hilly
    ridge
    islands
    halfed
    valley
    mountains
    FourStars
    Bullseye
    Plateau
    World Map
    USA
    bighill
    ring
    Castle
    Moon
    Pyramids
    Weathered
    HexWorld

    1) I have discovered that one or both of the following statements are true :

    1. Certain combinations of selected landscapes will cause a ‘Parse File’ error.
    2. Certain changes in the combinations of selected landscapes will cause a ‘Parse File’ error.

    Statement #1.b is definitely true; Statement #1.a is difficult to prove given Statement #1.b.

    2.a) To simply Statement #1.b with examples : If a certain combination of selected landscapes A is configured for a game, the game may or may not output the ‘Parse File’ error dialog before starting.

    2.b.1) However, after Configuration A game is played & exited; if other games with different selected landscapes (valid or invalid) are configured, played, & exited; it is possible that configuring a new game with Configuration A will produce the opposite error output behavior as the first time Configuration A was selected.

    2.b.2) For instance, if Configuration A had output a ‘Parse File’ error dialog the first time; it might not output the error dialog on a subsequent time — but only AFTER other game configurations (valid or invalid) had been configured, played, & exited.

    3.a.1) Additionally, if after a non-error producing game is configured, played, & exited; an error-producing combination of selected landscapes is configured for a new game, the ‘Parse File’ error dialog is output.

    3.a.2) However, after acknowledging the error dialog, the new game does immediately start — but NOT with ALL of the configured settings, but with certain default settings : 2 players, No Teams, BUT the selected landscapes configured are available during the game!

    3.b.1) If after an error-producing game is configured, played, & exited; the ‘Parse File’ error dialog is output (& acknowledged) PRIOR to configuring the next game — which allows a new configuration of selected landscapes to be configured.

    3.b.2) This new configuration of selected landscapes may clear the ‘Parse File’ error or may generate a new ‘Parse File’ error.

    4) Very specific examples :

    4.a.1) I configured the following landscapes for a new game (an ‘x’ before the landscape name indicates the landscape was selected by checkmark box from the ‘Land’ tab in the game configuration dialog) :

      x oldstyle
    x lowlands
    x hilly
    x ridge
    islands
    x halfed
    x valley
    x mountains
    FourStars
    Bullseye
    x Plateau
    World Map
    USA
    bighill
    ring
    Castle
    Moon
    x Pyramids
    Weathered
    x HexWorld

    4.a.2) After configuring these landscapes, I successfully played & exited the game without a ‘Parse File’ error dialog.

    4.b.1) For configuring the next game, I added the ‘islands’ landscape :

      x oldstyle
    x lowlands
    x hilly
    x ridge
    x islands
    x halfed
    x valley
    x mountains
    FourStars
    Bullseye
    x Plateau
    World Map
    USA
    bighill
    ring
    Castle
    Moon
    x Pyramids
    Weathered
    x HexWorld

    4.b.2) This configuration of selected landscapes output the ‘Parse File’ error dialog — immediately before starting the game with the default settings (see Paragraph #3.a.2).

    4.c.1) Configuring the next game, I kept ‘islands’ but removed ‘Plateau’ :

      x oldstyle
    x lowlands
    x hilly
    x ridge
    x islands
    x halfed
    x valley
    x mountains
    FourStars
    Bullseye
    Plateau
    World Map
    USA
    bighill
    ring
    Castle
    Moon
    x Pyramids
    Weathered
    x HexWorld

    4.c.2) This configuration successfully played & exited the game without a ‘Parse File’ error dialog.

    4.d.1) However, returning to Configuration #4.a.1 by removing ‘islands’ & adding ‘Plateau’ :

      x oldstyle
    x lowlands
    x hilly
    x ridge
    islands
    x halfed
    x valley
    x mountains
    FourStars
    Bullseye
    x Plateau
    World Map
    USA
    bighill
    ring
    Castle
    Moon
    x Pyramids
    Weathered
    x HexWorld

    4.d.2) This configuration of selected landscapes — which had previously started a game without outputing the ‘Parse File’ error dialog (see Example #4.a.2) — now output the ‘Parse File’ error dialog immediately before starting the game with the default settings (see Paragraph #3.a.2).

    5) This sequence of examples confirms Statements #1.b & Paragraphs #2.b.1 — that configuring some game(s) with specific configuration(s) may produce the opposite error output behavior as previous game(s) with identical configuration.

    6.a) Ironically, if ALL (of my available) landscapes are selected for a game configuration, the ‘Parse File’ error dialog is NOT output.

    6.b.1) Only certain subsets of all possible landscape combinations generate & output the ‘Parse File’ error dialog. And I have found that there are many more landscape combination configurations that are acceptable & do NOT output a ‘Parse File’ error dialog than combinations that do output the error. Which is good.

    6.b.2) However to be fair to this ‘Parse File’ error/Landscape Glitch, I did NOT come close to testing all 1,048,576 possible configuration combinations for my 20 available landscapes.

    7)@bobirov wrote:

    Clearing out the landscapes definition which will enable ALL currently installed maps … Clear out the “” line :

       Landscapes

    The next time you run a custom game all the maps should be enabled and hopefully it will work.

    7.a.1) As Bobirov stated above, clearing the Landscapes option in the singlecustom.xml file will enable ALL landscapes when a new game configuration is started :

      x oldstyle
    x lowlands
    x hilly
    x ridge
    x islands
    x halfed
    x valley
    x mountains
    x FourStars
    x Bullseye
    x Plateau
    x World Map
    x USA
    x bighill
    x ring
    x Castle
    x Moon
    x Pyramids
    x Weathered
    x HexWorld

    7.a.2) After a game configured for all landscapes is configured, played, & exited; the Landscapes option in the singlecustom.xml file will contain all the above landscapes :

    Landscapes
    oldstyle:lowlands:hilly:ridge:islands:halfed:valley:mountains:
    FourStars:Bullseye:Plateau:World Map:USA:bighill:ring:Castle:Moon:
    Pyramids:Weathered:HexWorld

    7.b.1) However, when the next new game is configured, one of the landscapes will have been de-selected from the ‘Land’ tab configuration. For my set of landscapes, it de-selected the ‘Plateau’ landscape first :

      x oldstyle
    x lowlands
    x hilly
    x ridge
    x islands
    x halfed
    x valley
    x mountains
    x FourStars
    x Bullseye
    Plateau
    x World Map
    x USA
    x bighill
    x ring
    x Castle
    x Moon
    x Pyramids
    x Weathered
    x HexWorld

    7.b.2) Inspecting the Landscapes option in the singlecustom.xml file reveals that the ‘Plateau’ landscape was deleted from the Landscapes option list :

    Landscapes
    oldstyle:lowlands:hilly:ridge:islands:halfed:valley:mountains:
    FourStars:Bullseye:World Map:USA:bighill:ring:Castle:Moon:
    Pyramids:Weathered:HexWorld

    7.c.1) On subsequent game configurations, plays, & exits; selected landscapes will sequentially be de-selected & deleted from the Landscapes option in the singlecustom.xml file.

    7.c.2) For my landscapes, the landscapes are de-selected & deleted in this order (starting from ALL landscapes selected) :

    1. Plateau
    2. World Map
    3. bighill
    4. ring
    5. Castle
    6. Moon
    7. Pyramids
    8. HexWorld

    7.c.3) For some reason, it skips ‘USA’ & ‘Weathered’ landscapes.

    7.d.1) Also, after the last game is configured, played, & exited (whereupon the ‘HexWorld’ landscape is deleted from the Landscape option in the singlecustom.xml file); the next game configuration will output a ‘Parse File’ error AFTER configuring the game but immediately before starting the game (see also Paragraphs #3.a.1 & #3.a.2).

    7.d.2) And after this default-settings game is played & exited; the ‘Weathered’ landscape is now deleted from the Landscape option in the singlecustom.xml file.

    7.e) This sequence is consistent & repeatable & may actually be started anywhere in the above sequence — i.e. the landscapes don’t have to start from all-enabled. The above landscapes will start to deselect/delete from the Landscape option in the above sequence with each subsequent game configured, played, & exited.

    8.a) I know this was a rather lengthy & confusing post, but I hope it provides additional info in solving this ‘Parse File’ error/Landscape Glitch.

    8.b) Good luck!

    in reply to: If I win program crashes #12314

    hobbesme
    Participant

    @oleksa wrote:

    I’ve just updated video driver. All works fine … I couldn’t understand what the difference in graphics” [has to do with the crash] …

    Now THAT’s a scary bug — and an even scarier bug analysis :

    @gcamp wrote:

    Yes I don’t understand either. I must generate some wrong graphics … or something ❗

    Scary. 😉

    in reply to: I am having some annoying problems #12295

    hobbesme
    Participant

    As Bobirov stated, it’s probably that several of the configuration settings are configured for minimal graphics detail :

    — Level of Detail Settings :
    —- Tank Detal : o Low o Medium o Max

    Set to Max for all tanks.

    — Detail :
    —- o Don’t draw water

    Uncheck to draw water.

    Weeks ago, my game settings/options mysteriously changed. I posted a similar post asking why I was no longer seeing water, hearing sound, etc.

    Gavin replied that I should double-check my configuration settings — which I had not done because it didn’t even occur to me to check my settings since the game had been working for weeks on the maximum graphical detail settings.

    But sure enough the configuration settings had been restored to the default “Safe Options”. I never figured out why they reverted back to the default safe options, but if it ever happens again, I’ll know to just go back & re-configure all the desired settings.

    in reply to: Lost Moves? #12269

    hobbesme
    Participant

    @gcamp wrote:

    Here is what happens on the server :-
    2) The server sends a message to all the clients telling them to move
    3) The server goes into a state waiting for moves.

    Once the server timer expires it times out any players whos move it does not have and moves on. If the server gets any moves after the timer has expired it throws them away.

    The server and client timers may get out of sync if the time between the server sending the messages and the client receiving gets large.

    I think I can do a simple fix for this that adds on a few seconds that the server will wait for moves. Although this will not fix times when the server link is just really, really slow.

    Why not REQUIRE the server to wait for a reasonable amount of time to receive either :

    A) A move from each client
    OR
    B) A packet indicating that a client’s Move count-down timer has timed out

    Assuming that all clients will communicate to the server within a reasonable amount of time (not guaranteed but irrelevant; see below), then the server’s move count-down timer does NOT need to be synchronized with any of the client’s timers since it is NOT going to execute moves when it reaches 0 seconds. Instead, the server executes moves when it receives from ALL player-clients either (1) a move or (2) an indication that player(s) failed to move before their move count-down timer expired.

    The server need only timeout on a larger move count-down timeout value so that it doesn’t wait forever. For instance, if the players’ move count-down timeout value is 45 seconds, the server’s timeout value might be 10-20% longer; e.g. 50 seconds.

    More aggressively, the server might use two timers — one set to the clients’ timeout value & one set to the clients’ timeout * 10% value — for example, 45 seconds & 5 seconds. If the first timer expires after 45 seconds, the server starts the 10% timer for 5 seoncds. The server could then start to actively ping (once per second) all player-clients that have not yet transmitted a move to determine if those clients are still active.

    The clients could respond to the ping with either (1) the player’s recently-entered move, (2) the number of seconds remaining in the client’s move count-down timer, or (3) that the player’s move count-down timer expired & that player failed to make a move.

    If the server receives pings back from ANY player-client indicating that the player still has time to make a move, it should reset its 10% timer since clearly the player-client(s)’ & server’s timer are out-of-sync.

    Once all ping replies indicate that all player-clients have made their moves or failed to make their moves, the server could then execute all the moves.

    If any player-client(s) fail to reply to the pings within the 10% timeout, then the server MUST mark those player-clients as having failed to make a move. And as currently implemented, after three consecutive failed moves, those player-clients would be forcefully disconnected.

    There are a few more issues. For example. a player-client(s)’ ping reply may continually indicate that the player has three seconds left to make a move. The server would continue to reset its 10% timer & wait for that player-client(s)’ move — and the client-server would be in a deadlock forever. So, the server should also disregard ping replies that don’t seem to show the player-client(s)’ timer as steadily decreasing to zero. Even though the player-client is replying to the pings, other portions of the player-client app may be locked up & should eventually be marked as failed to make a move & ultimately as disconnected.

    Ideally, the clients response to the server would be a ‘Move’ packet with the following data :

    1) Move
    2) Move Count-down Timer remaining time value

    The ‘Move’ portion of the packet is either a description of a valid move OR a NULL move (i.e. no move). The ‘Move Count-down Timer’ value is the clients’ remaining timeout value — if a move was entered BEFORE the client’s timer expired, then the timer value will (most likely) be non-zero; if NO move was made before the timer expired, the timer value will be zero.

    Regardless of whether this packet is sent BEFORE the server starts to ping the client or in response to each ping from the server, it will contain the same information every time & can be parsed/handled by the server the same way :

    if (PlayerClientMovePacket.Move != NULL) {
    Indicate ThisPlayerClient.Move = AVAILABLE;
    Set ThisPlayerClient.MoveFailedNbr = 0;

    } else if ((PlayerClientMovePacket.MoveCountDownTimer > 0) AND
    (PlayerClientMovePacket.MoveCountDownTimer steadily decreasing)) {
    Reset 10% Timer;

    } else {
    Indicate ThisPlayerClient.Move = NOT_AVAILABLE;
    ThisPlayerClient.MoveFailedNbr++;
    }

    if (ALL PlayerClient.Moves == (AVAILABLE or NOT_AVAILABLE)) {
    Execute Moves;
    }

    For (Each ThisPlayerClient.MoveFailedNbr > MoveFailedNbrMax) {
    Disconnect ThisPlayerClient;
    }

    [Note : My pseudo-code is NOT representative of the high-quality code I design on a daily basis. 8) ]

Viewing 15 posts - 526 through 540 (of 549 total)