Sorry your browser is not supported!

i got some code for a mutiplayer network game, but i have was wounding about someing, the "net message player from" command, it says it returns the player number, but i doesn't say what that number refers to, is it the player ID or is it something else, because i need to know if i can use it in a array. I post the bits of my code to show what i mean



theres a max of 8 player that why i put it like that. any know if that will work or not?

that will work most of the time...
the times that it won't work are not really important to you at this time but if you want to know ....


as players enter/leave your game the playerID number will increment. Letts say you have a 4 player game...
player 1 hosts
player 2 joins
player 3 joins
player 2 quits the game.....
(you now have 2 players in the game, player 1,3)
player 4 joins game
player 5 joins game
(you now have 4 players in the game ,1,3,4,5)
if your array is limited to 4 players
(dim Players(4) now your program crashes )

but there are work arounds.....
but first, learn the networking commands.

Ok thanks, that shouldn't be a problem as you can only join the game before the game starts (if that makes anysense), but i will have to refine that so that the game doesn't show if its playing, but thanks for the help

waffle...

that's not what my apps are showing under a P2P simulated network game.

I have 3 cloned apps, one connected as the host, the other 2 as joiners.

The player list of the host is not in the same order as the joiners. The joiners are always the same.

ALSO, if player 2 quits, and rejoins, there is NO player #4 created, the topmost player # is never above 3 in any case I have tried.

I was told by a DB expert who maintains a technical mailing list that any player leaving causes the player list to be reformed, thus removing the empty slot. Anybody joining gets put at the end of the list, but it should never rise above your player limit set in your CREATE NET GAME command.

I've tried and you can't join if the limit is already present.

Please explain your message more in case I am missing something!!

Should work then. Try it and see what happens.

I want to correct myself ad someone else on something. After 24 hours or so of testing DB's multiplayer features, I discovered:

Don't use the index#'s in the checklist for players... they are just for retrieving the player's data. The checklist value a(index) is their ID# and will NOT report the same across all player's machines. However, it remains the same under each app for that player throughout the session no matter who comes and goes. Use the ID# in any way you like. The string$(index) function is the NAME for that ID#.

In a 5-player game, if players 2 and 3 quit, SURE.. the player checklist reports 3 players in the game and lets you see their entries as indexes 1-3, but in each entry, you'll notice that the ID#'s for the remaining 3 players have NOT changed.

Also, when others join back in, they get the empty "ID#" slots (not neccessarily checklist entries) that were freed when the other players quit.

The ID# of a player never climbs above the player limit set in the CREATE NET GAME command.

Now, in a client/server game using the same players, etc. Only the host/server app sees a reporting of all the players in his checklist. All the clients see in their checklist is INDEX#1) theirself INDEX#2) the host
So sending to 0 or 2 causes the same result. And you can't send anything to yourself so that narrows it down.
A client sending to everybody still only goes to the host.

I have had 5 windowed apps running at a time, 1 host and 4 players and send messages back and forth under every circumstance, and the thing I see that is constant through all the shuffling is the PLAYER ID# and NAME found in each checklist entry are firm.

However, I did find that in a P2P game, the last player to join is always listed as the 1st entry of the checklist. Entries below this are almost always not the same across apps or players.

So, forget about the checklist index# and focus on the ID# found in Checklist Value A(index).

This all may sound easy as hell, but I it's actually a shuffled mess to have so many dern flags and references, indexes, etc. just to track a player in your game, and the DB docs are short to explain anything useful over a simple 2-player game WHICH BY THE WAY can happen even by accident since there's only 2 entries in the checklist! see? SO, many of the demos you see are not even fully coded right. They just asume things and it usually works for 2 players.

No, I'm not an expert but I did a long study and that is what I found to be the case when simulating a TCP/IP connection to say, 127.0.0.2 locally between 2 to 5 cloned DP apps.

Fun

so you figured out what i meant about the player ID,
i was not refering to the checklist index.
the checklist will list all players and all players ID
that can be refrenced from the index. This gets complicated to work out.

also, I haven't found much use for the client/server game type because of the ammount of extra work required of the server to keep other players informed. In another language that i use, i use the client/server method, but then it lets me setup multiple communication channels ...

Suggest it to the DBPro team sometime. After they have all the main bug worked out, of course .