Dynamic jump height
I haven't delved into the code for this, but from what it looks like in just playing with the engine, jump height is static/pre-calculated. I know there's a "gravity" setting, so I'm guessing that factors into it. It also seems like the engine determines that the player character will elevate to its full jump height as soon as the Up key is pressed.
I was wondering how difficult/feasible it would be to modify jumping in the following two ways:
1.) Give player characters some sort of "jump statistic" that is used to determine the PC's maximum jump height. I think it would be cool to have PC's jumping ability modified by player stats, buffs/debuff effects, etc. Maybe do the basestat vs. modstat thing, as with the other statistics, and then when the jump button is pressed, calculate the jump height based off of the modstat. (I might be totally off on this. Spodi, if you want to point me in the direction of where jumping is calculated, maybe I can take a look at it.)
2.) Allow PCs to jump less than their maximum height by validating whether the Up key is still being pressed every fraction of a second, and only continuing their jump towards maximum height if that is the case. This one, I can see being more difficult to do, both from a programming perspective and a load/latency perspective. You'd probably have to have the client continuously send packets to the server and have the server process whether a PC is still jumping, so incoming packet processing would be increased (not sure by how much). I'm not sure it would have as big of an effect on the server's outgoing traffic and updates to the clients, since you still have to update the PCs' horizontal position constantly, even when they are jumping.
Anyway, just thinking outloud here, and hoping Spodi or someone else more familiar with the engine will chime in.
1. That is do-able. Calculating the height rather than velocity might be a little work, but should be able to be solved with a time-based equation (I think I remember an equation from calculus that could help). I'll probably have the jump velocity (along with move velocity) properties synchronized at some point so they can easily be dynamic instead of a constant.
2. Probably won't ever happen. Like you said, latency would become a huge issue. Anything that involves network synchronization, instant-response (like something happening right as you press a key), and latencies less than a second is not going to be a good mix at all. It is possible, but you'd need more of a FPS-style "roll-back" physics simulation which is quite complex to implement, and is quite heavy on the server.
1. Ah, I wasn't sure how jumping was calculated. What if you just made the jump velocity dynamic then? Seems like that would serve the same purpose of modifying maximum jump height, and maybe would require less tweaking from a formulaic/coding standpoint?
2. Yeah that's what I figured. Oh well, was a nice thought. 
Dynamic velocity would definitely be easy. Though I probably want to find a quick and efficient way to calculate the actual height based off of the velocity and gravity anyways since I will need it for when it comes time to add decent AI/pathfinding. But in any case, I'll get to adding that at some point. 
Probably will do it at the same time I do dynamic speeds and attack rates.
Just let the server know how long the jump key was pressed, and then the server can calculate off that. It doesn't matter if someone puts in a 'hack' to make it always maximum, seeing as you would compromise lack of control anyway.
If maximum key down time is one second and the guy pressed it for a fraction of a second, then multiply a fraction of a second, by the maximum jump velocity.
That's not the same as what I was asking for in #2. You're describing some sort of "charged" jump, where the jump would not start until you lift the jump key, and you could send the server the length of time the jump key was pressed. My idea was to have the jump start as soon as you push down on the jump key, and then so long as the key is still pressed, keep the PC moving upwards (until it hits the maximum jump height). That would require constant validation that the jump key is being depressed to work.
Well not constant validation as such, just validation when the key is pressed and depressed, but yeah it probably wouldn't work, which is why i mentioned the charged jump over the mario jump, as it isn't affected by latency.
A "charged jump" is what I was thinking would be the best alternative, too. A lot of games (at least older ones) do this by crouching first before jumping, resulting in a little bit of delay time (as you have to crouch first), but a higher overall jump.
Other alternatives could be a key assignment to different kinds of jumps, though that would be quite unintuitive and overwhelming. You can also have a double-jump, which would be fun, but you will still have latency concerns (though not as big of ones).
I'm not sure about latency but speaking from just the code, it seams easy to me.
something like this I think:
maxZElevation = groundElevation + 50 // Z is how high something is in a 3D game, might have to just be X in 2D
while (jumpKey = 1) // 1 = pressed key
playerAnimation = Jump.XXX // Jump.xxx being the jump animation
if (playerZElevation != maxZElevation)
++playerZElevation // makes the player rise up
else
jumpKey = 0 // force the jump key to off so that when it's pressed again, the player jumps again
while (jumpKey = 0 && playerZElevation != groundElevation ) //0 being not pressed
playerAnimation = Jump.XXX
playerZElevation -- // makes the player go down
if (playerZElevation = groundElevation
break // stop all prosessing. This is best done in a function.
If I'm wrong, let me know.
Yeah, it is FAR more complicated than that.
I like the idea of a double/multiple jump, Spodi, if you think it's feasible lag-wise. If you require that the player press the jump key before reaching the peak of their first jump for them to double jump, and then you have the double jump only happen at the peak (no matter when they press the jump key), would that help control the additional latency?
Can I get a snippit of the code for jumping? Pwease?
The current jumping code? Why don't you download it and take a look?
*facepalm*
I feel stupid....
Charged jumping is how Asheron's Call (one of the original 'big 3' MMOs) works, for precisely the reasons Spodi describes. It's a nifty way of doing things and I recommend it.
Question: Does Maple Story have 'Mario style' jumping? Will latency performance for a mature future version of NetGore be significantly different than what they're able to pull off?
I'm not sure on Maple Story, but Wonderking Online uses 'Mario style' jumping (i.e., you always jump the maximum height every time). You can double jump in WKO as well. I'm on my work laptop right now, so I'm not sure if you can execute the second jump at anytime during the first jump, or if it's limited.
By Mario style jumping i meant the longer you hold down the jump button the higher you go. 
Maplestory has fixed jump depending on stats.
Maple story is probably the worst game to look towards as far as technologically advanced or innovative features go. Their characters are even just bitmaps that only face one direction (turn around and your left arm becomes your right and so on).
lol, weak MMo
Gotcha. Latency wise, what can we look forward to with NetGore? Is there any reason to think that a finished, mature netgore game w/ a decent server will have more rubber-banding/lag than other MMOs?
The networking still isn't fully finished (still a bit of work to do with out-of-order packets and such), but it should be able to perform as well as many other online games after it is finished being tweaked.
As long as it doesn't lag as much as SVO (vbgore) does I'm happy.
No more spam, please.
Well I'm pretty sure gravity is calculated by weight and velocity. That might help ya a little more
Oh and don't get the damage gravity mixed up with the entity (world) gravity!
Sorry if that was no help to you, but I'm also still learning the engine.