Is that source release that I see being mentioned?

It's funny, I always hear about people talking about source releases and things but it never does seem to be as big as what the expectations are. I guess the devs can't really release the source without abandoning getting any future money out of the project so it just never happens when the community is at it's strongest.

To say that the community is strong now, is naive.
Anyways, post-source-release, I just hope people come back to this place, and do what modders did in Minecraft: make the game and the community.

that doesn't mean ♥♥♥♥.
examples being terraria 1.1 1.2

Minecraft.
How many times has it been fully released?

Single Player.
Multiplayer.
Survival.
Multiplayer Survival.
1.0
1.8.*
1.0 (again)
Now it's 1.7.*

I never said it was going to be ♥♥♥♥.

Mackerel, king of the 'you said that because I want'.

Whoa hoh, source release for the win.
Also this game is still great. It reminds me of the feeling of being a kid and having toy soldiers in a box, except they climb around and get mad and blow each other up.

In case Duh or Data come back, I'd like to ask if will we ever get more Reliable and/or Faster walking?
Pretty sure I love everything about this game except the lack of some sort of sprint type function.

I'm not a developer, just a forum mod.
I doubt there will be any major engine improvements, however Data can be surprising sometimes. The way walking is implemented, it's doubtful that it will get any better, because unlike most games there's no concept of a "speed" for actors, they literally push off the ground with their feet rather than get moved and make an animation to create the illusion of correct motion.

Vlads, king of the 'head trauma'

I figured it was in pretty deep in the code (and really any update to how it worked would probably mess up all the walkpaths for existing actors?) but I was unsure how much work it would be to actually alter.
Sometimes I wish walking would operate on some sort of simpler principle (like a 'speed' variable), but I suppose I have no idea how much havoc that would wreak with the way the actors are handled with the rest of the physics engine.

A common complaint amongst people who I've shown the game to is essentially that they want their soldiers to move more quickly on the ground.
I enjoy the game immensely regardless, but I get the impression from the people around me that the game's playership would increase if soldiers had as much maneuverability on the ground as they did in the air.

We could probably hack something in with lua scripts. If I recall correctly, someone DID make a mobility enhancing script with like all kinds of added jazz as well.

I remember mehman's mobility script. The only problem is when all 20 or something soldiers on screen are running it at the same time, the game slows down noticeably, meaning it would never be viable for every soldier to be capable such feats (unless you had some kind of monster computer I guess).

Wouldn't it be rad though

Just took a quick look at the mobility script: most of the system heavy stuff is the action roll and better jumping and dropship riding. The actual speed improvements are pretty simple (understandably so, it's not a particularly complex thing to do), just add a bit of forward velocity rotated to match the angle the actor's moving at. I think he's got a couple checks to make sure the actor doesn't get too stuck into the ground either (getaltitude() or whatever would probably be cheaper than a raycast), which are probably a good idea though they may make it a bit floaty.
So yeah, the speed boost by itself should be fairly cheap and easy to put together. Heck, you can probably just snip the relevant sections straight out of mehman's script.

Bad Boy: I did exactly what you are talking about to get the slow results I mentioned.

Even without the fancy stuff (walking on ships, kicking people or falling on them and doing particle damage), it's still a lot of work for each character to be running in the background.

Basically the problem breaks down to two leg checks (making sure fg leg and bg leg are indeed still there), obstacle rays casted from each leg (possibly the real killer and also the thing that makes it work), and various rotation checks so that the unit isn't flying forwards while upside down.

With all of those things running for every soldier while they are trying to walk 'normally' as the engine dictates, you get a laggy mess with anything more than 4 or 5 soldiers moving - and this is before a single weapon is fired (the thing that produces the most particles and slows the game down most noticably).

I am sure someone's awesome computer could do this, but it's basically a shame that running ground units are a high-end-gaming-computer only thing.

Yeah, the obstacle rays would be the big issue there and the one I completely forgot about, I guess this is more hassle than I thought haha.
You can probably cheat a bit and just use one ray from the body or from the body + a bit of ypos, that should accomplish much the same thing.
Also, strength rays may be cheaper than obstacle rays since they only have to check for terrain. Staggering them so they're done every 10 or 20 MS instead of every update sim would probably help too.
Finally, and I don't know if this is cheaper but it may be worth considering (it's off the top of my head as an idea so it may not actually be great):
1. When you find an obstacle terrain with your ray, save the actor's position (not really necessary) and make a vector with xpos slightly ahead of the actor in its facing direction then move that vector to ground.
2. Get the angle between the two points with some trig, if it's not something ridiculous like 90 degrees you're probably on a hill.
3 a. If you're on a hill, cast another obstacle ray with that angle (maybe a bit higher to account for little bumps in the hill you're hopefully on) and see how far it goes to make sure you're not in a small cave or under a small overhang.
3 b. If the ray hits an obstacle and the distance to that obstacle is>= to the distance to the grounded point consider the obstacle's position to be the check point, otherwise it'll be the position of the grounded point.
3 c. Then add velocity rotated by the angle (calculated previously) until the actor reaches the check point (or turns around etc.) and don't do any raycasts or anything until then. It'd probably be good to save the checkpoint, the direction for it and the position it was checked from so you don't have to keep recalculating it every time the player changes direction.
4. If you're not on a hill then you know you're probably at a wall or an overhang with a wall (though the last one may be untrue) so you can stop doing raycasts until the actor turns around or flies off somewhere, etc. Again that's probably worth keeping track of.

After thinking it through and writing it down, this all seems pretty complicated but it may be a bit less resource heavy since you can just do a few simple boolean checks after the intial raycasts and junk. There're also issues with underground since it relies on movepointtoground, there may be a better way of getting that original check point, I don't remember all the functions that might apply.
Thinking about it it'd probably be better to map out all the terrain into some global table and use that to figure out each actor's speedboost without having to cast a single ray, but that's way more complicated haha. If nothing else, try the first two suggestions, they'll probably help

Eugh, global tables still escape me and sound awful (especially just for dudes walking) but you do have a great point with the strength rays and their efficiency. I might investigate this suggestion further!