Messages

1

TNet 3 Support / Re: TNet 3.0 upgrade guide

« on: February 15, 2016, 07:08:50 PM »

Yeah, I knew there isn't an Asset Store option. In that case, I'll get in touch with you through the "official" contact form and request a Pro license tomorrow morning. Would be good to get this done before I forget again. Thanks for being as awesome and quick to reply as usual.

2

TNet 3 Support / Re: TNet 3.0 upgrade guide

« on: February 15, 2016, 03:19:18 PM »

Forgive my very belated reply, but I'd like to ask a question about upgrading, and this topic fits.
The "current version" sticky tells us that 3.0 is already available to Pro customers. I picked up my copy of TNet on the Asset Store when I did, and I never quite got around to upgrading, which would have been quite useful, in hindsight. If I do it now, will that count as upgrading to TNet 3 and living happily ever after?

3

TNet 3 Support / Re: Using a Smartphone as a gamepad via TNet ?

« on: May 12, 2015, 12:28:28 PM »

Oh, I didn't think of that. Oops.
Well, a bit of digging around seems to show that you really can't have different scenes on one channel, but here's something I found:

No. Same channel means same scene. You can still send RFCs via private messages to players elsewhere, however.

Perhaps you could have one channel for the "controllers" and one channel for the actual game scene, link them up somehow (I don't know if you can retrieve a list of players on a different channel than yours, but even if you can't, there's probably a workaround for that), then send RFCs using "private messages" (I really have no idea what that means, still a TNet newbie), and have the actual game process the input as per the initial plan.

4

TNet 3 Support / Re: Using a Smartphone as a gamepad via TNet ?

« on: May 12, 2015, 08:52:50 AM »

Your idea sounds pretty nice! Instead of having a separate scene, why don't you simply have the "virtual analog sticks" below the actual scene, or on a different layer that isn't rendered by the default cameras and only by the "player" camera on the smartphone?
That way everything will be in the same scene, and you can get away by having only one local instance of the "controller" sticks.

5

TNet 3 Support / Best practice for saving server-wide variables? (team and player scores, etc.)

« on: May 11, 2015, 07:52:03 AM »

Greetings!
I'm pretty sure the answer to this is quite straightforward, but I've been busy with lots of different things and my memories of TNet's inner workings is a bit rusty. Tried a bit of searching, but that sort of failed to bring up anything interesting, so before I do something stupid, here I am.

The thread's title says it all: I'm wondering what the best way to save "global" variables is. Given that the dedicated servers in my game should behave more like any given first-person shooter's dedicated servers (though my game isn't an FPS), and not like a co-op game where the server stops existing once all players leave, I want to save stuff like team scores, and which team controls which objectives, that will then be relayed to newly-joining players.
What would be the most elegant way of storing these values? Encoding them into the TNManager.channelData string?

6

TNet 3 Support / Re: Targeted physics-based projectiles? How?

« on: February 20, 2015, 10:43:50 AM »

Thanks for the tip. However, I managed to avoid attaching TNObjects to missiles: I simply sync every player's mouse position along with their other data, then everyone spawns a local copy of the missile which follows the - supposedly - same logic and follows the same position. Of course, only the owner determines whether or not a successful damage-delivering hit exists, so even if some clients see it a bit differently, I'm sure I can live with it - it's a missile with a blast radius, after all, and not a precise shot which can be easily avoided.
It works, seemingly well-enough. Now it's time to fix up a team selection screen of some sort.

On a completely unrelated note, I was going to ask about an "issue" I just spotted. Given that all my player entities use physics-based controllers, I'm making good use of TNSyncRigidbody amongst other things, and I update once every two seconds. However, I just noticed that I seem to be getting noticeable "jitter" once every two seconds (my TNSyncRB update rate) on instances that are NOT the Unity Editor when my Transform gets repositioned. This had never happened before.
After a bit of confused fiddling, though, I noticed that I'd switched it from UDP to TCP (as I did want my transform repositions to be sent reliably); switching it back to UDP fixed the issue. I'm not quite sure it was an issue in the first place, but it's gone now, so I'm content.

7

TNet 3 Support / Targeted physics-based projectiles? How?

« on: February 19, 2015, 01:04:51 PM »

Greetings, everyone.
So I'm working on my multplayer game that uses TNet. Everything's pretty nice, I've managed to handle the movement and shooting parts, so all correct values are redistributed to all clients and so on.
My game uses mostly physics-based projectiles, so upon a user firing, I instantiate a projectile on all clients and let them do their own graphics logic; I deal the damage only on the affected entities (shooter - victim) and send out the new health values.
Everything's pretty great, but I do wanted to have a targeted weapon type, i.e. a guided missile that follows the shooting player's mouse cursor. A bit of physics and torques (gotta love those physics courses I took at university) allowed me to create the guided missile's logic fairly easily... but only in a singleplayer manner. And I want it working for MP, like all the other weapon types.

So, the big question is: what's the best way to have a targeted missile?
- The first (obvious) option would be to attach a TNObject to every instantiated missile, have it correct its course based on its owner's mouse position, and sending the position and rotation and stuff to all other players. However, that may lead to lots of TNObjects being spawned around, and that might not be the best performance-wise; besides, my previous (half-arsed) implementation was like this, and it gave out errors when I tried to create more than one missile, something about the ID not being unique - but I was using an ID of 0 with dynamic creation, so I've got no idea what that was all about.
- Secondly, there's also the idea of every player sending their "lookPosition" to all other players along with the other transform data, instantiating the missile like a regular projectile, and forcing it to follow the given lookPosition locally for all players. I don't know whether this method would have weaknesses, and I've not figured out how I'd notify the missile of its parent.

I'm not really certain which one of these would be the better choice. Maybe the second one?

At any rate, any tips would be greatly appreciated.

8

Misc Archive / Re: [WIP] Creating a UI Components pack! (Want something? Post here!)

« on: February 19, 2015, 12:08:43 PM »

Greetings everyone, and first of all, let me apologise for being inactive for so long.
Certain events happened, I changed computers, I even moved to a different country (lol excuses), and I kind of drifted away from NGUI... which means that I'm unlikely to actually make a "pack" out of this and add more stuff to it.
However, people do seem to be interested in the scrollable list right now, and - fortunately - I've still got the file and the "instructions" for it. Long live MediaFire and forum PM saving!
In clearer words, I intend to "release" this to the public as it is in its current state. Please check the first post again.

Once again, I'm really sorry for not doing this earlier.

@Aren: I know you don't want people to have access to your code like this, but this is just one file, so I hope you won't mind.

9

TNet 3 Support / Re: player.data - what, where, and when?

« on: December 15, 2014, 06:24:16 PM »

Thanks, Aren, this is a good idea. It'll also save me the implementation of some sort of a tree later on. I think I'm going to go with this... By the way, does player data get redistributed to newly-joined players automatically, or should I handle this myself?

10

TNet 3 Support / Re: player.data - what, where, and when?

« on: December 14, 2014, 10:47:28 PM »

Thanks for your input, but I'm familiar with the RFCs (as the whole networking, including guns and players and whatnot, is working, and I'm now moving onto the "other stuff"), but was kinda hoping to avoid using RFCs and to piggyback on top of the already built-in data thing. But we'll see; hopefully Aren, or someone who's experimented with this, will shed some light on what the data's actually meant to be used for.

11

TNet 3 Support / player.data - what, where, and when?

« on: December 14, 2014, 01:26:02 PM »

I'm not entirely certain what the player.data is best used for. The file it's defined in mentions that it gets synchronised on the server, but in one thread on here, Aren mentions that it's entirely local and does not get synced. Which one of them is it? (I did check all references to it briefly, and I saw it being written and parsed in a couple of places. Heh.)

Also, if we assume that player.data doesn't get synced, what's the best way for me to keep track of stuff like players' teams and score and whatnot?

12

TNet 3 Support / Re: Sending more server info to connecting players

« on: December 12, 2014, 02:59:12 AM »

You, sir*, are a bloody genious. Here's all the thanks I can give.

* or madam. Sorry, "Leslie" is an ambiguous name.

13

TNet 3 Support / Re: Sending more server info to connecting players

« on: December 08, 2014, 10:59:43 AM »

This is simply brilliant. But of course!
I was actually going to send the "map name" or something along these lines along with the server name, so that's what I was going to use. And (char)30?! Good God, using the built-in delimiter character as intended... I was thinking about which keyboard character I should use as a delimiter (and should therefore ban from server names)...
Maybe, just maybe, the past two nights of not sleeping are getting to me. Maybe...

By the way, how are you doing your static RFC call? Does the TNObject auto-compute some sort of RFC enum, or did you add one yourself?

14

TNet 3 Support / Sending more server info to connecting players

« on: December 08, 2014, 09:02:27 AM »

Greetings! I've been dabbling with TNet, and I'm so far thoroughly impressed (as a trained networking engineer who'd never actually done any network programming on end devices, lol). My relatively simple game took a trivial amount of time to setup, once I wrapped my head around the RFC idea (which, fortunately, didn't take long), and even my rigidbody-based guided missiles seemed to work basically right out of the box. Spectacular!
So, thing is, I'm now getting to the point where I need some testing that's not done by myself on my PC, connecting to my loopback, so I'll need a custom window for connecting (the server browser can wait until I get to when I really need it) to an arbitrary address.
Thing is, I'm not getting how to send custom data from the server - I'm using procedurally-generated "terrain", so I can't load some random level; all "maps" are to be loaded through one scene. Is there an explicit way to send extra data to the clients? Just asking, 'cause in one thread I found Aren recommends adding the data to the server's name. Is that the "right" way to do it?

Also, I'm not quite getting what "channels" are. Would I be right in thinking that a channel on a lobby server would be just a regular joinable server (the same thing that Photon calls "rooms", IIRC)?

15

TNet 3 Support / Re: [Guide] Setting up lobby in the cloud

« on: December 08, 2014, 08:48:56 AM »

Many thanks, Leslie. You seem to be happy about choosing digital ocean, yes? I'm looking for somewhere to host a master too, as my project seems to trudge along near to completion.