NetGore

Welcome, Helix!

There is definitely places to help out, and always will be. The first step is reading the [[joining the development team]] page. Then, find a place you'd be interested in helping out in. You might not want to dive into the engine core yet since things can get tricky down there and require understanding the details of NetGore, but different things you can help with are:

• Resolving reported issues
• Bug hunting
• Feature development (though non-intrusive features, and ones coded well, are allowed in the engine directly)
• Misc minor tweaking (improving minor issues with the UI or usability than you run across)
• Helping out with the site (e.g. writing tutorials, etc)

Just send me your information so I can give you write access on the SVN repo, and then you can start on whatever you want, whenever you want. Though unless its minor tweaks to the UI, resolving issues, or writing unit tests, I'd prefer if you sent me a PM before starting work on something.

On a side note, the editor re-designing is actually being lead by Skye. You can find the SVN repo for the editor UI mock-up at http://code.google.com/p/netgoredevkit/. Unfortunately, it hasn't really gone anywhere since those who wanted to help out with it seem to be busy. Since I just today almost finished the updater, I'm going to be low on tasks shortly, so having the mock-up UI done sooner would be a huge help.

Send me your instant messenger info or email address in a PM so we can get in touch properly ^^

@Spodi: Looking at the issue tracker there's still quite a few weeks of coding left if you ask me Also DF looked into the Dockpanel Suite but couldn't really get it to work >_>

Thanks! I've contacted both of you.

Skye wrote:

@Spodi: Looking at the issue tracker there's still quite a few weeks of coding left if you ask me Also DF looked into the Dockpanel Suite but couldn't really get it to work >_>

Most of it is features, which can be done at any time and are of no big importance. I'll be done with the features far before anyone actually needs them.

You think so? SVO could use most of the features that are on the tracker right now
E.g.
- Chat channels
- More GM commands
- Friend/block/online lists

Issues SVO would benefit from if resolved: 166, 162, 178, 177, 48, 91, 95, 157, 158, 161, 163, 164, 176

Anyway, I explained the DevKit to Helix and he was going to look into it as well. Hopefully he'll have more success in getting it up & running

Yeah, but you don't need them right now is my point. None of them are halting development or anything, and only a very few would even benefit development.

Oh whoops, if you put it that way then you're absolutely right with the fact we really need to get the DevKit GUI done because the lack of good editors is slowing down development.

However, i you run out of "priority" tasks, you can always try to make the engine more accessible with more (on-site) documentation on the key components of the engine and their methods.

Well I just decided a little bit ago that I need to rewrite majority of the networking, so I think I'll be plenty busy.

Documentation, although needed, is probably something I'll wait on doing myself until I start working on my own game. I know its a bit late, but by that time the engine should be quite stabilized and I'd have a chance to do things from a user standpoint, not developer.

Well yay, better networking is always a good thing, hopefully it'll get rid of the infamous idle bug for good ^^

Ever consider Lidgren for networking? It's highly stable, unless you're looking for your own implementation.

Horrible networking is the thing that killed vbGORE for me.

Netgore is looking very good in the networking aspect but it needs a lot more fine tuning.

Lidgren look interesting Helix.

I heard it had performance issues with large packets. (resending them over and over) I've had good experiences with it in the past though. Might have to change the source a bit to get the right disconnection behavior you want. (I'd rather send my own packet instead of a string as a good bye message)

Was actually what I was already thinking of implementing. No way I am rewriting everything from scratch - that took forever.

I have actually been considering using the Lidgren networking since over a year ago, but felt my implementation was "good enough". After spending all night last night screwing around with some stuff, I'd rather just say screw it and use a better library.

Yeah. It's not good enough IMO LOL

I think Lidgren is probably one of the only UDP libraries on the .NET platform. (Not sure of any others that are close to it)

Spodi's already experimenting with it (looking at the commit log). No more idle bug please! >_>

Do you think this Lidgren library would have any more success with faster paces games like fighters or shooters or would it basically just be implemented to fix problems and bugs while keeping the same general networking we have now.

For the most part, no. It boils down to an issue of design at that point, not the networking. To put it simply, fast-paced games use far different, much more resource-intensive techniques to compensate for latency. What you see on your screen is not what is actually used by the server for calculating if your shots hit since the server knows that every client is behind the server (due to network latency). As a result, the server usually will "roll back" based on your latency and calculate information using that point in time. This is why someone with a laggy connection can shoot you even though you already ran out of their sight. If you are behind a wall now, but were in their view 500 ms ago, and they have a 500 ms latency, the server will roll back 500 ms to see where you were, and say "okay, when he shot, you were there, so even though you are not there at all now, it will count." Then you go, "how the hell did he shoot me through a wall!? >:|"

But if I do things right, latency should improve since I can throw more things on unreliable and unordered streams. Though it shouldn't do much for the positioning since that was already using UDP.

Yah I know what your talking about since the 3D engine I work with is T3D. What was it called network interpolation or interpresomething I dunno.

Maybe it guesses where you will be in a few seconds based on current speed and vector. Just a guess I got no idea xD

Interpolation, yeah. Or extrapolation. NetGore uses interpolation combined with delaying to smooth out the movement, but makes it less accurate to what the server is actually at. This is what a lot of FPSes do also (the client runs a little bit in the past then interpolates, that way you don't have to extrapolate or just stop moving completely), but NetGore doesn't combine it with the server-side rollback, so you don't have the "accuracy" FPSes do. If I didn't do this, you'd see your character skipping around a ton as the position is extrapolated, they stop, then they "bounce back" due to over-extrapolating.

Ahh well its not a big deal because like I said before.. making a fighting game or a 3D game is something out of the question in terms of ability to complete.

Actually without netgore I doubt I could complete a game. I usually don't get past the prototyping phase xD