Quote:

after some testing i realised that i have to put a sleep(1) bevore the level load, so that the on_server command is properly triggered when the client joins the game. iam wondering why nobody else or locoweed had this problem yet?




I ran across this problem a while back, though I thought it was just me(since I didn't re-create locoweeds level/tut, just used it for reference). I ended up putting the sleep in the on_server function, but I think i'll change that to putting the sleep before the level loading. Thanks for sharing that.

Some Tips:

- Proc_client/proc_local functions do not keep the "you" pointer when creating.

- Make sure your proc_local function isn't running code thats meant only for instances with your clients main entity. Use my.native for this.

- My.client flag and connection variable are your friends, i've used them alot.

- If you want a different interpolation solution for lan games, it's a good idea to create a global variable and differentiate between lan and internet play in your interpolation code. Lan cant have the ent_sendrate set at 0 so might as well reap the benifit and have options for it.

- If your creating a hybrid server you'll have to always keep in mind the server/client combination. Remember, this does not mean the server runs functions from proc_client or proc_local even though it's a hyrbrid. If your doing an rts or any game that requires a group of players before the game starts(not a server running and players come and go as please) then I think you'll need a hybrid server solution. I'm going for both hybrid server and a dedicated server solution in one.

- Checks and balances. Keeping track on whats realisitic when recieving and sending var/skills/arrays; hampers hacking.

- Watch your pointers! I cannot stress this enough, a large degree of my headaches come from pointer problems. Part of this is due to transfering a single-player code base to multiplayer, other part is due to stupidity. You can send pointers via handles to the other entities, but, if a new entity joins the game then it will not have the skills of the other entities. So... you have to resend the pointers.

- Are you sure you want to create a multiplayer game first? Why not create single player than take that wad of code and change it for mulitplayer? Currently i've been converting my single player base to mulitplayer for a little over a month now. I think if I went mulitplayer from day one, at my experience level(in day one), it would have took much much longer to get where I am right now due to time consuming multiplayer testing. Single player testing is not time consuming as you don't have to create multiple instances of your game over and over. If you do go single player first, create very modularized code(for example, for mine I can shut down each weapon, all weapons, chop up movement and still have functional code). This makes the task a bit easier bringing over to multiplayer as you create a base(creation of ents), and go thru your code from there 3-4 functions at a time. Keep in mind i'm speaking from my own experience, I havn't done any MMORPG work so mabye it's best to go multiplayer right from the get-go there.

- For single player I have 8 kart pointers, kart1 for the main player, kart2-kart8 for the A.I. For multiplayer, every kart creates as kart1 to keep all the single player code functional, and on top of that, I have new pointers from mkart1-mkart8 for each multiplayer kart to differentiate them. This allows me to easily transer ammo/health/ect. thru the different kart pointers, and also, keep the single player functions running well while keeping A.I seperate.

- Headeaches, i've still got a couple more weeks of them as I transer the rest of my weapons over to multiplayer, lol... I honestly cant say multiplayer has been any fun past the first week or so.