Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Lumos

Pages: [1]
1
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?

2
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.

3
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?

4
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? :P

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)?

5
Greetings!
A few days ago, I was trying to build my game's options menu. NGUI is a blast, but creating a potentially long list of resolutions meant that I couldn't use NGUI's built-in PopupList, as that component always insists on showing the entire list. I am targeting the PC, and I don't want to do a cheap "here you go, a couple of buttons with pre-determined resolutions" solution. I needed a replacement. Tried using some sort of buttons instantiated at runtime, but it was honestly terrible, so I searched for a replacement. It appears that a member of this forum, by the name of "adam718" had written something like that about two years ago. I tried it, didn't work even after porting. Therefore, I trashed that idea as well.
And so, in the end, despite being quite inexperienced with NGUI (I am well-acquainted with programming, though), I sat down and wrote a new list, based on the current one. This one is scrollable.

So what's this all about? I'm intending to create a few more components for NGUI, then publish them on the Asset Store (as Aren has stated that he doesn't want his source code floating around everywhere, and the Asset Store should deal with that with the "requires NGUI" thing they've got going on). I'll likely provide the entire pack for free, or for a couple of euro only, as I am quite broke at the moment - as a symbolic price, tribute to the free time I've spent on them.
So, what do you guys think? Is anyone interested in a component pack?

After this scrollable list, I'll do some sort of a list which has got only one element showing up at a time, with left/right arrows for selecting the other elements (Battlefield 3/4 options menu style), which could possibly also show the amount of elements using some sort of a small sprite. I had something else on my mind as well, but I seem to have forgotten it at the moment. :P
So, if anyone's interested, post here. I am likely to do requests, so if you want to see a specific GUI component NGUI's been lacking, and you can't be arsed/don't know how/don't want to write one yourself, just post here and (if it's not too complicated) I'll make one and include it in the pack.

Current projects and Unity 4.6 GUI and whatnot render me unlikely to continue using NGUI, so the above paragraph is very unlikely. However, you can now grab the scrollable list if you want to.

In any case, let's get to demonstrating the scrollable list.
Ladies and gentlement, without further ado, I give you the...

> Scrollable Popup List
It's got its own scrollbar, and can be quite small...


Positioning it above works as expected, and how big it is is up to you to decide.
The Inspector is naturally based on the existing ones from NGUI, but exposes more variables - particularly these relating to the scrollbar.

The Scrollable Popup List is great for displaying long lists, unlike the regular PopupLists which may, at one point, become longer than your screen. This one's "open size" is dictated by the "Max Height" variable exposed in the Inspector. (Setting it to 0 will give the same results as a regular PopupList, and you can change that during run-time if you so desire for whatever reason.) Naturally, you can populate such a list during run-time in rather the same way you'd do with a regular list.
The scrollbar handles clicking and dragging, and behaves just as a scrollbar should. Most of it is also exposed (including the colours its foreground and background sprites use), so you can customise it as well.

A scrollable PopupList (or, should I say, a ListBox for those familiar with .NET development) is perfect for displaying a variety of different things. I wrote it because I needed a resolutions list, but it can be used for basically anything - as a debugging tool to display all items in your new RPG, as a complicated dynamic statistics graph filter for that 4X strategy game you're working on, or perhaps as a list of all maps during your new FPS's server hosting screen.
It was odd to me that NGUI didn't have one of these by default. One'd think that such functionality is indispensable.

Limitations:
- Requires a minimal modification to the UILabel class in order to display the choices on the given label.
- Does not support phone-style dragging directly on top of the list. I do things for the PC, not for random portable devices. PC master race FTW. :D

Note: This list does exhibit some strange behaviour from time to time, IIRC, so keep in mind that it's not perfect. YMMV.
DOWNLOAD (.zip, 9.41 KB)

"Installation" instructions:
Just like every other UI component, just drop the files in some proper folders. You can use a regular PopupList prefab, and just replace the default list script with this one.
However, one modification should be made to the UILabel class in order to allow the labels to handle updates from this specific kind of list. Open up the label file, and find the SetCurrentSelection() function and add the part after my comment from the excerpt below:
  1.     /// <summary>
  2.     /// Convenience function, in case you wanted to automatically set some label's text
  3.     /// by selecting a value in the UIPopupList.
  4.     /// </summary>
  5.     public void SetCurrentSelection ()
  6.     {
  7.         if (UIPopupList.current != null)
  8.         {
  9.             text = UIPopupList.current.isLocalized ?
  10.                 Localization.Get(UIPopupList.current.value) :
  11.                 UIPopupList.current.value;
  12.         }
  13.         // Lumos: Scrollable popup lists
  14.         else if (UIScrollablePopupList.current != null)
  15.         {
  16.             text = UIScrollablePopupList.current.isLocalized ?
  17.                 Localization.Get(UIScrollablePopupList.current.value) :
  18.                 UIScrollablePopupList.current.value;
  19.         }
  20.     }
  21.  


Hope I've interested someone. I do feel like doing a few more components.

Any comments, opinions, remarks? Let me know.

6
NGUI 3 Support / Anchored clipping
« on: May 07, 2014, 11:21:01 AM »
Greetings.
This is my first ever post on here, and I hope this is the correct board. If it's not, please excuse me.

In any case, I am relatively new to NGUI, but I reckon I've gotten the hang of it now. So, the whole point is to make resolution-independent UIs, right? I'm working on my main menu, and it would seem that in order to create scrollable panels, I need to define a fixed "clipping rectangle" of sorts, which is not fit at all for my UI which is entirely dependent on anchors. Is there a way I can force an entire widget to act as a "clipper", or to give anhorcs to the clipping rect, or anything? How would one create a completely resolution-independent UI if I can't create non-fixed scrollable views?
(In context, i.e. why I need to have an anchored clipping rect: My "options" screen on the main menu slides into view from the right-hand side, and therefore the clipping rect appears in a different spot whilst editing it than where it is during run-time. My "sliding" was done through forcibly hacking the sliding panel's anchors' absolutes and then tweening them when needed - it's probably entirely incorrect, but I couldn't find a way to do a sliding panel (I'm a noob), so this could be the source of my problems)

Any help will be greatly appreciated!

Pages: [1]