Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Program Announcements / MikeNet - Multiplayer Plugin

Author
Message
dale2507
12
Years of Service
User Offline
Joined: 1st Apr 2008
Location: My own little world...
Posted: 21st Sep 2008 01:16
Hey

I'm changing from multisync to mikenet and so far have only 1 problem in that the mulisync command net message from seems to have no equivelant in mikenet.

I really don't want to have to add mnsendbyte to send the client id at the beginning of every transmission so any help would be greatly appriciated.

Thanks
sydbod
12
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 21st Sep 2008 10:36 Edited at: 21st Sep 2008 11:28
Quote: "I really don't want to have to add mnsendbyte to send the client id at the beginning of every transmission so any help would be greatly appriciated."


I am a little confused as to what you are actually sending.

Normally you build up the data within a packet and then send the packet.

When you are building up the data for a packet, then you normally add the Client ID and another ID to say what the data in the packet is supposed to be used for.

Within the server code

EG:


As you can see, you place as the first int value the client ID that is sending the packet.
The second int value has as ID to tell the receiving clients what the data is used for, so the receiving clients know how to handle that data.

In the above sample that packet is being used to hold real time data from a data structure for an aircraft.
The receiving clients know what the User ID is , that sent the data packet, and also know that the data is player position data, and therefor the data will have to be broken up in a fixed sequence of data types.

Within the client code the client ID is added automatically to the top of the packet so you do not have to add this Client ID in this packet creation code.
EG:



It is not necessary to send any other user ID on its own.
Emphasoft
13
Years of Service
User Offline
Joined: 2nd Jun 2007
Location: Deep Underneath the Center of the Earth
Posted: 21st Sep 2008 17:13
thanks for the download. comments coming...

I admire its purity, a lone survivor, unclouded by delusions of morality or conscience. -Parker, from ALIEN.
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 21st Sep 2008 18:54 Edited at: 21st Sep 2008 18:55
@ dale2507
The equivalent command is mnGetClientFrom() but in MikeNet the server loops through each client and checks for new messages from each client individually. This means that usually there is no need to use this command; have a look at the cube world demo as that should make it more clear.

@ sydbod
Yes, this should work. The client can check client numbers from 0 to maximum number of clients whilst the server can check client numbers from 1 to maximum number of clients. Let me know if you have any trouble with this.
Tav
13
Years of Service
User Offline
Joined: 20th Feb 2008
Location:
Posted: 21st Sep 2008 19:51
Hey, please help me debug this, cause I'm stuck xP.
The problem occurs when receiving new UDP packet.
Server

Client
main.cpp

Player.h

Thanks
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 21st Sep 2008 21:07
At a glance, here is a list of things wrong with your code:
-On the client, you are receiving via TCP, then via UDP and then trying to use the TCP packet and UDP packet so if a UDP and TCP packet are received at the same time, the UDP packet will overwrite the TCP packet before it is used.

-On the server, the operation code must be second and the client id must be first. The corrected code is below:


-When the client sends the angles/positions of object 101 it must include an operation code before the data because we are in UDPMODE_PER_CLIENT_PER_OPERATION.
Tav
13
Years of Service
User Offline
Joined: 20th Feb 2008
Location:
Posted: 21st Sep 2008 21:14
Hehe thanks. More bugs then expected.
dale2507
12
Years of Service
User Offline
Joined: 1st Apr 2008
Location: My own little world...
Posted: 21st Sep 2008 21:47
@ Micheal P

Thanks will look at it sometime.
Tav
13
Years of Service
User Offline
Joined: 20th Feb 2008
Location:
Posted: 21st Sep 2008 22:07 Edited at: 21st Sep 2008 22:10
Same error. "Error occured whilst dealing with new udp packet. Operation number must be less then the maximum operations."

Client
Main.cpp

Player.h

Server
main.cpp

EDIT: Happens when I start more then one copy of the client.
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 21st Sep 2008 22:22
When sending the positions/angles from the client you haven't added in the operation code that has to be at the start of the packet.

Also, when receiving via UDP you shouldn't be using mnGet commands to find the operation or client values because these are removed by MikeNet. You already know what client/operation the packet applies to because you specified it in mnRecvUDP.

I suggest you have a look through the cube world demo and compare your code to it, this should help you debug your code.
Tav
13
Years of Service
User Offline
Joined: 20th Feb 2008
Location:
Posted: 23rd Sep 2008 21:14 Edited at: 23rd Sep 2008 21:16
Sorry if I'm annoying you. Now here is the problem. My client connects to the server but then disconnects again. I took the cube demo as an example but still doesn't work.
Client
Main.cpp


Player.h


Server
main.cpp
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 23rd Sep 2008 23:23
Don't worry, you are not annoying me So far as I can see the only remaining problem is that CODE_MOVED_PLAYER is 1 but should be 0.

Operation codes begin at 0 and end at one less than the maximum number of operations. Client codes begin at 1 and end at the maximum number of clients.

When the server trys to deal with something from a client that it cannot handle, it silently drops the client (which is what is happening here). When a client trys to deal with something from the server that it cannot handle it will disconnect itself and usually display an error message explaining what went wrong.
Oneka
16
Years of Service
User Offline
Joined: 24th Apr 2004
Location: Hampton,VA
Posted: 23rd Sep 2008 23:34
So any news the on the progress of the next update? because iam an eager to get to work on my project again


Making dreams possible, one line at a time...
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 24th Sep 2008 01:03
It is getting there. I'm finalizing and testing the new TCP system. The tests that I have run show a dramatic increase in performance (huzzah). After finishing that off, I just need to make some changes to the way clients are dropped from the server, run some final checks and make changes to the documentation. This should all be done within a few weeks.

In terms of usage, the new version won't have changed very much. The main changes are in mnConnect and mnStartServer which have been changed to make them easier to use. This means that you can probably continue to work on your project with the current version, and then convert it (which will be easy enough) to be compatible with the new version.
Oneka
16
Years of Service
User Offline
Joined: 24th Apr 2004
Location: Hampton,VA
Posted: 24th Sep 2008 01:20
Yeah I really cant fully continue because I needed that multiple connections / server hosting within the same app to be able to work because I need to do some testing :p


Making dreams possible, one line at a time...
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 24th Sep 2008 09:50
Multiple connections/server hostings won't be in the next version. I intend to release the next version with everything but that, and then implement it later; sorry to disappoint! In about 3 weeks I have a few days off in which I'll lock myself in a room and implement it (if I haven't already done so by then).
Oneka
16
Years of Service
User Offline
Joined: 24th Apr 2004
Location: Hampton,VA
Posted: 25th Sep 2008 18:05
Thats cool I have a quick question about what changes you made to the get and send commands, because I have noticed that my ping code most of the time will return 15ms of delay between when it was sent from the client and recieved from the server, which I wouldnt expect it to be that high becasue iam hosting on 127.0.0.1 so it should be 0ms or 1ms at the highest lol, and in sometimes it is but most of the time it seems to cap out at 15ms even when I run more of the same clients, and I know its not my code as it returned 0ms when using Barnskis so I was wondering if in the next release will this be lowered?


Making dreams possible, one line at a time...
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 25th Sep 2008 19:22 Edited at: 26th Sep 2008 01:10
The next update will make receiving via TCP and packet formulation much more efficient and so you should see this reduced.

[edit] I decided to test this using the new TCP system on the loop back address. The ping (round trip time from server to client and back again) was 0 constantly where a ping request was sent every 3 seconds and nothing else was happening on the server/client. Seems to be success ; Here is a screenshot:

sydbod
12
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 27th Sep 2008 02:45
@ Michael P,

Just to let you know.
The Host/Client mode that I implemented, with modified Server code within the Host, looks to be working fine.
sydbod
12
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 27th Sep 2008 03:49
Quote: "I dont know if this is an bug or not but I noticed when recieving UDP messages, it does not clear the buffer of the packet after reading the data"


Thanks for that information Oneka.

I have a position extrapolation routine moving my models to where they should be over time (on a dead reckoning basis). The model positions are then re-synchronized to where they actually should be when a new packet gets received.

I have been chasing a stuttering of my models for some time and reported to Michael P that I think I was suffering from packet out of order problems.

I can now confirm that the problem I am suffering is actually caused by the problem that Oneka has reported with the UDP packets not being cleared after they are read, and it is not a packet out of order problem at all.

Am looking forward to the next release when this problem is fixed.
Tav
13
Years of Service
User Offline
Joined: 20th Feb 2008
Location:
Posted: 28th Sep 2008 14:41
Thanks for the help, works fine now.
Tv Xxx
13
Years of Service
User Offline
Joined: 23rd Sep 2007
Location: Behind You!
Posted: 29th Sep 2008 18:19
Hi, Im Having Trouble With Gettin The Packets, It Just Wont Do It For This One Part,

Bassically My Server And Client Work YEY but Im makinkg it login, thus im using a mysql plugin which compares the password you input and your actual password. this all worked, then i decided to add this bit to the server for security reasons, so i need to send the username and password entered to the server, then the server loads your actual password from the sql table and compares, then responds as needed, but i cant get the client to send the username, well it sends, but the server doesn;t recieve.

heres snippets of my server


and my client


any ideas?

Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 29th Sep 2008 18:54 Edited at: 29th Sep 2008 18:56
The following full code works for me using v1.02:

Server


Client


Screenshot


Check that the TCP receive buffer sizes on the server side are not too small and that the plugin you are using to take input on the client side is doing so correctly. Try the code above and let me know how you get on
Tv Xxx
13
Years of Service
User Offline
Joined: 23rd Sep 2007
Location: Behind You!
Posted: 29th Sep 2008 19:22
cheers mike,

the problem was that the TCP buffer was to low, just made it bigger and now it works, great plugin btw

yours tv

Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 1st Oct 2008 20:23 Edited at: 11th Nov 2008 17:23
Version 1.0.3

It is here

Changes since the last version
-mnConnect and mnStartServer's parameters have changed to make them more user friendly.

-To change the buffer sizes you should now use mnSetBufferSizes. Without using this command, they are set to 1024.

-To manually set local address information you should now use mnSetLocal.

-TCP store size on the server side has been removed
-Send buffer size on both the server and client side has been added. This is the maximum size that a send packet can be including its prefix (an integer, normally 4 bytes).
-TCP receive size must now be equal to or greater than the size of any incoming TCP packet (including its prefix); previously it could be smaller so long as the TCP store size was large enough.

-To disable message boxes from appearing whenever an unexpected error occurs you should now use mnDisableMessageBoxes.

-Client's can now connect to servers when behind a router with NAT enabled. Previously the client would experience problems.

-In client state, you can now find out what your client id is using mnGetClientId.

-All commands that had UDP or TCP in their name now have this in upper case e.g. mnGetTcpPercent is now mnGetTCPPercent. DBP users do not need to worry about this because DBP is not case sensitive.

-UDP and TCP are now treated separately e.g. Your TCP and UDP local port/IP can now be different. Below is a list of commands that are new or have changed as a result of this:
mnStartServer
mnConnect
mnGetLocalPortTCP
mnGetLocalIPTCP
mnGetLocalPortUDP
mnGetLocalIPUDP
mnGetConnectIPTCP
mnGetConnectIPUDP
mnGetConnectPortTCP
mnGetConnectPortUDP
mnGetClientPortTCP
mnGetClientIPTCP
mnGetClientPortUDP
mnGetClientIPUDP

-mnTCPPacketsWaiting has been removed
-mnRecvTCP returns a number greater than 0 if a new packet has been received. This number indicates the number of TCP packets in waiting.

-Commands concerned with buffer sizes now return or take unsigned integer instead of signed integer. Commands effected by this change include:
mnGetTCPRecvSize()
mnGetUDPRecvSize()
mnGetSendSize() (new)
mnSetBufferSizes() (new)

-TCP performance has greatly improved
-Packet formulation performance has improved

-mnRecvUDP will not receive packets that have already been received. Previously mnRecvUDP would always receive a packet and if no new packets were present it would use the last packet received.

-The documentation has been changed to reflect all of the above changes. Commands that were missing from the documentation or commands that had incorrect information documented have been changed or added to the documentation.

-The demo code has been changed to reflect all of the above changes and the DBP demo code has been written in a way that should be more familiar to DBP programmers.

Also..
I've restructured MikeNet quite a bit in preparation for the next big version which will include the ability to have multiple connections and/or server hostings in one application.

As well as this, I've redone some of the critical sections in place so that threads block on each other less.

Final words
You should see quite a big performance increase since the last version, especially when it comes to TCP. Sorry that it took me so long to release this, I haven't got much time and MikeNet is a complicated beast .

If you have any problems and you think it is due to a bug in MikeNet please let me know and I'll release a fix as soon as I can. Likewise, if something is missing or wrong in the zip such as some of the demo code for example, please let me know and I will rectify this.

Let me know how you get on

Attachments

Login to view attachments
RedFlames
13
Years of Service
User Offline
Joined: 25th Aug 2007
Location: Germania
Posted: 1st Oct 2008 22:54 Edited at: 1st Oct 2008 22:59
Sounds awesome, but...

well your new Cube World Example works fine for me (although you added # to every Integer, while in DBPro # indicates that its a Float ).
But when i implement the same code (same IPs/Ports etc.) into my Project only one client can connect . And there is no difference, no reason why...

Edit: I forgot to mention for the 2nd Client mn Connect returns 0 -> TimeOut.

Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 2nd Oct 2008 01:02 Edited at: 2nd Oct 2008 01:26
I've changed the DBP examples so that they are correct. I will look into the problem you've reported, if anyone else gets this please let me know.
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 3rd Oct 2008 01:41
Version 1.0.4
In this version are a few bug fixes. The following has been fixed:
-A problem with the new connection system that meant that in certain circumstances clients were unable to connect.
-A general problem that meant in certain circumstances the server would become unresponsive.

Thankyou to RedFlames who identified these problems.
sydbod
12
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 3rd Oct 2008 05:15 Edited at: 3rd Oct 2008 07:58
Has a quick try with the 1.0.3 version with DarkGDK last night.

The server code looked to be working, and the client code looked to be working. (only a very quick test was done) Managed to get 2 clients joining to the one server with no problems.

The work around that I was using with earlier versions to create a "Hoste mode" always caused the joining "Client" machine to crap up and then drop to desktop with this version.
I don't think the new "Client" code liked dealing with packets that had an ID number of "0".

Anyway, that is no longer a concern for me as it looks like a client instance and a host instance are happy to run simultaniously on the one machine, so I will rewrite my code to do it this way.

Will post a proper test result later next week when I have done the rewrite and run some thorough tests with the 1.0.4.
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 3rd Oct 2008 09:45
I'll have a look into this problem next week, hope the tests go well
sydbod
12
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 4th Oct 2008 11:07 Edited at: 4th Oct 2008 11:35
@ Michael P,

Using 1.0.4

Quote: "iResult = mnSetLocal(LocalIP,LocalPort,LocalIP,LocalPort);"


I end up with an iResult of "0" no matter if I use a valid existing network device IP, or if I use a wrong non-existing network device IP.

Here is the relevant code section:
sydbod
12
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 4th Oct 2008 11:33 Edited at: 4th Oct 2008 14:38
@ Michael P,

Using 1.0.4
First attempt at using this function.

Looks like this function is missing.
Quote: "mnGetClientID( )"


Here is the error message
Quote: "1>.Network.cpp(178) : error C3861: 'mnGetClientID': identifier not found"


Here is the relevant code section:




EDIT: It looks that in the PDF documentation you have used "mnGetClientID" where as in MikeNet.h the function is actually called "mnGetClientId".

It may be worthwhile to standardize that function name to "mnGetClientID" as it is consistent with the rest of your naming convention.
sydbod
12
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 4th Oct 2008 17:39
@ Michael P,

A little bad news.

My original post about the ver 1.0.3 working is not totally correct.

It appeared to be working because of the "Host mode" That I was using. One of the machines was intercepting Client data in the middle between the receive and resend mode of server code in the first client. As I was looking at that machine when testing, everything looked to be OK but it was not so on the other machine.

Running pure Client mode through a Server,
2 machines can log onto the Server.
Both machines get the correct Payer ID from the server.
Both machines send their data correctly to the server, and the server correctly receives that UDP data.

NEITHER of the client machines appear to get any UDP data.
I am not certain if the Server is not sending the UDP data, or the Clients are not handling UDP traffic from the server.

Currently I can not fault my code, but I will have to sleep on it as I am tired, and re-examine things more carefully tomorrow. It can still be a fault in my code.

May even change my current code back to use the earlier NAT Beta that you gave me and make sure my current code works properly with it, just to double check.

Sorry about the incomplete news at present.
sydbod
12
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 4th Oct 2008 19:02
@ Michael P,

I could not sleep so I grabbed the above file set and changed it backwards to the earlier version of NAT 1.0.3 BETA .

this version again works properly with the Server and Client mode.

In the new 1.0.3/1.0.4 version it is now confirmed there is a problem in the path somewhere from sending data from the server, up to the reception and detecting the UDP traffic up to and including the mnRecvUDP() function.

It may or may not be related to my packet data, as this point has not been investigated yet.

Will look into it further in the morning.
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 5th Oct 2008 03:04 Edited at: 5th Oct 2008 14:32
Sorry about this sydbod, hope you didn't lose any sleep over it ; thankyou for identifying this problem.

Version 1.0.5
The problems that sydbod has had with MikeNet have been resolved in this version. This was down to a silly mistake in the mnSend commands.

Here is a full list of changes:
-Fixed another bug that could cause the server to become unresponsive. All of these sort of bugs should now be resolved.
-Improved performance of send commands.
-Fixed a bug that meant that if a send operation fails, memory is not properly deallocated (present in all past versions).
-Fixed a bug that meant that send operations from the server would not work (new to v1.0.4).
-Changed mnGetClientId to mnGetClientID. DBP users do not need to worry about this because DBP is not case sensitive.
-Changed the DBP ini file so that the parameters of the mnSendAll commands are correct.



@ sydbod
Quote: "I end up with an iResult of "0" no matter if I use a valid existing network device IP, or if I use a wrong non-existing network device IP."

mnSetLocal only converts the IP and port for use with winsock and stores it. During mnConnect and mnStartServer actual usage of the IP/port takes place and so you will receive an error message at this point if the parameters of mnSetLocal are incorrect.
sydbod
12
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 5th Oct 2008 03:32 Edited at: 5th Oct 2008 12:23
@ Michael P,

With the 1.0.5 , All appears to be good with the world again.

Later today I will clean up all my code once more, and reintegrate the "HOST" mode workaround once again.

I suspect this mode will now work again.

Thanks for the 1.0.5 release.
sydbod
12
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 5th Oct 2008 08:38 Edited at: 5th Oct 2008 12:22
@ Michael P,

Could you please check if:

mnRecvUDP(iPlayer,iCode)

can handle a value of iPlayer == 0 .

I suspect these last few versions can not handle this value anymore and this may be why my "HOST" mode is now failing with the later versions of the library.
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 5th Oct 2008 14:38 Edited at: 5th Oct 2008 14:44
Version 1.0.6
This version contains a small fix that addresses sydbod's issue.

Full change list:
-Clients can now receive using a client id of 0. This enables the server to send UDP data to a client when this UDP data is not related to another client.

Version 1.0.6 (Mirror 1)
Version 1.0.6 (Mirror 2)
sydbod
12
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 5th Oct 2008 16:17 Edited at: 5th Oct 2008 16:19
Thanks Michael P.

HOST mode is again working.

Should you be interested, I would be more than happy to send you my "Flight Sim Proof of concept" file set to see how I have implemented the HOST mode with your library, should you be interested in redoing your samples to also demonstrate how this feature can be done.

My code is not overly pretty, but it can be followed reasonably.

Now back to more important information.
I will give this version a good working over again, on the net, over the next week.
One of my associates has an internet satellite connection , and that will give your "packet out of order" code a good working over.
Will let you know how it all comes out.
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 5th Oct 2008 16:22 Edited at: 5th Oct 2008 16:24
I'd love to have a look at it I'll turn it into an easy to read demo at some point, probably for the next big version when I do multiple connections/server hostings. You can email it to me using the email in my TGC profile or just post it on this thread.
sydbod
12
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 5th Oct 2008 17:15
Here is the file set.

If you want a working compiling set with the media attached, so that you can play with it and compile while doing experiments, then just let me know.

It is not top secret kind of work ...... I am just a hack hobby programmer.

The Network.CPP file will be the important one.

Attachments

Login to view attachments
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 5th Oct 2008 18:41
Just had a quick look through network.cpp and I've noticed a small mistake. The last line of this section should be "if(iTcpPackets > 0)" not "if(iTcpPackets == 1)" because since v1.0.3 mnRecvTCP returns the number of packets in waiting, which could be more than 1.



Quote: "If you want a working compiling set with the media attached, so that you can play with it and compile while doing experiments"

Yes please
sydbod
12
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 6th Oct 2008 03:19 Edited at: 6th Oct 2008 03:39
Here it is.

Thanks for spotting that error.

"F5" in Debug mode will run the game (the media is preconfigured for that.

You will require a Joystick with a twist handle for the rudder or you will have to reprogram the operations yourself, until I get around to including game configuration modules at a later date.

Have fun

EDIT: Darn ... that upload did not work.
Will try again in the following post.

EDIT2: It claims the zip file is over 50MB when it is only around 20+ MB.

Will have to try rapidshare or some such service. Will post link when ready.
sydbod
12
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 6th Oct 2008 04:14
Here it is:

http://rapidshare.com/files/151295861/Package.zip.html
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 6th Oct 2008 09:50
Got it, thanks
dale2507
12
Years of Service
User Offline
Joined: 1st Apr 2008
Location: My own little world...
Posted: 22nd Oct 2008 12:20
Hey having some trouble with this plugin (Version 1.0.2).

I'm currently incorporating chat into a game using the tcp in mikenet howeber the client is being disconnected from the server when the message is sent. I have however found there are no problems if there is a delay before sending the message. Was wondering if it was because there is so much udp data being sent? here's some code.

Client:


Server:


appreciate any help.
dale2507
12
Years of Service
User Offline
Joined: 1st Apr 2008
Location: My own little world...
Posted: 22nd Oct 2008 13:53
Ignore last post Tv-XxX figured it out. He doesn't no how but it's working now. lol.
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 22nd Oct 2008 15:42
Excellent You should probably upgrade to the latest version because there are some major increases in performance.


By the way, I have several days off next week to work on the next version of MikeNet; hopefully I'll have the will power to put in the necessary work
GIDustin
12
Years of Service
User Offline
Joined: 30th May 2008
Location:
Posted: 28th Oct 2008 06:25 Edited at: 28th Oct 2008 06:26
Quick question for you.

I have been looking into creating a "battle.net" type system for my current game. If would be a large global staging ground for creating and joining games.

My initial thought was that the server could "create a game" with a large number of players. Then each player joins that game and there is chat code and whatnot. When a player hosts their own game, it send a message to the lobby about the server IP and info, from which other players in the global lobby can connect. Once the game is started, the players might leave the global lobby "game" to save on resources.

Is this the proper way to handle this? Is there a better way? The reason I post here is that to do this I need 2 net connections (the main one to the global lobby, and the one to the individual game) and MikeNet is the only MP DLL so far that (will soon) allow for multiple connections.

Edit: If this is possible, it would make a great tutorial to include with the future dll /wink
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 29th Oct 2008 12:58
This should be possible with the next version of MikeNet and I would say that you are going the right way about doing it. I'll think about doing a tutorial

Login to post a reply

Server time is: 2021-02-27 22:30:33
Your offset time is: 2021-02-27 22:30:33