Search results for query: *

I was/am busy with another project - A New Life.
I'm just out the diaper phase.

Looking forward to try out the mod, too bad there are no servers 

I forgot everything I'm afraid.

Lemme check it out first. The key arrived today, download in progress.

Elenmmare said:

...Or running out of fuel.

Click to expand...

They had as much so they had to jettison some of it just before the crash.
Besides, they always take more than needed, just in case they have to land somewhere else in case of bad weather or something.

Just tested some on tutorial dummies in 0860 (if similar mechanics applies to MP, there are indications it does)

horizontal slash does at least about 80% of max damage at the very beginning of the swing
overhead chop does at least about 80% of max damage to targets directly behind your back.
contrary to what Armagan wrote, there are no signs of variation according to distance, it's either not implemented at all or it doesn't work.

Seems like we're not getting this.

Started happening for me too, since .800

Looks like occasionally, a single frame lasts for 1-2 seconds. It's worst in the first minutes of a match, things seem to get better with time.

Jack_Merchantson said:

That's great, if you're talking about speeds over a 20m distance.  What about over a 2m distance?  What about unsustainable movements?

Click to expand...

20m distance consists of 10x2m distances, you know.
You probably mean the first 2m, well, the principle is the same, the same constraints make you unable to accelerate backwards as efficiently as forward, there's nothing magical about the first two meters.

Jack_Merchantson said:

This is why a simple percentage speed limit fails.  Barring realistic acceleration and deceleration, a changing rearward speed limit is required to balance short-range tactical movement with long-range retreats.  And/or added limitations on rearward movement.

Click to expand...

Still can't see why it would fail.
Your changing speed limit is required to work around other associated misconceptions. Combat footwork and locomotion don't balance, because they are two different modes.

Jack_Merchantson said:

Manitas said:

Whatever, running or jogging in any direction while fighting is bull**** anyway.

Click to expand...

http://www.thearma.org/essays/Tactical.htm

Click to expand...

Nice anecdotal evidence, but still it's described as something unusual.
A reenactment teacher employing ineffective technique to humble his students. Good for him he didn't have to care about effectiveness of his blows or staying alive. Apparently anything goes if you're fighting against little girls as shown in the attached pictrue of the group.
Chances are he'd do equally well if he rode in a wheelchair.

Jack_Merchantson said:

I agree, rearward movement should be limited primarily by the possibility of tripping, rather than some arbitrary and unrealistic speed limit.

Click to expand...

Funny argument, arbitrary and unrealistic is now.
We can tell exactly what speed ranges are realistic and not arbitrary, you can test it yourself, it's been done by others, like here:
http://darkwing.uoregon.edu/~btbates/backward/alan2.htm
"FRmax velocities were significantly faster than BRmax velocities (7.3 m s-1 vs. 5.1 m s-1)."

Ratios significantly different than that are arbitrary and unrealistic.


Whatever, running or jogging in any direction while fighting is bull**** anyway.

UsF said:

People should slow down if they move backwards and press the attack button. People moving backwards that are only blocking, should be unaffected.

Click to expand...

Or even better, they should move backwards more slowly.
Decelerate to zero when attacking regardless the direction would be another nice thing.

UsF said:

Maybe movement inertness could fix this too, when rapid changes in movement are not possible. Red Orchestra had this system. It wasn't felt in normal combat, but it prevented strafe dodging for example.

Click to expand...

There seems to be something like that already, there's a short pause when changing direction.
But that's far from being inertness, going to a stop is still instant.

Jack_Merchantson said:

Yes, the server always knows what your ping is and reports it accurately, so if your ping is above fifty you'll never  have random added block delay...

Click to expand...

Irony?

Somehow, they still cant seem to be able to get the ingame pingometer to work properly.
Of course the server never knows the actual ping, it only has some idea on what it was like in the past.
Ping is the time it takes to send a packet and get a packet back in response, so when it receives a packet with info about your blocking intent, it doesn't have a faint idea on for how long it travelled, therefore turning delays on and off depending on ping is a bad idea.

AoC said:

No. Don't touch the block delay . With this feature, gap between people with good ping and people with bad ping is less pronounced.

Click to expand...

Strange, I didn't notice any significant delay and I was sure it was removed a few versions back.
But if there was any, it would apply regardless of network delay, so it would make things even worse for bad pingers.

Qwertyman said:

We allready have parrying that is based on collision (you can block a right swing with a left block so long as the blades meet) and chamberblock-  which is based on collision

Click to expand...

Not true - in both cases collision is faked, there's no collision test performed.

They were funny, especially the upwards parry, looked like torreadore's gesture. I thought they were some kind of easter egg when I first saw them.
If you did that in real fight you probably wouldn't live long enough to do it more than once.

glustrod said:

manitas, you may be right that the game could get even much better with a "redesign of the whole thing", but even if the redesign based on real parameters you have in mind is really so easy to put into practice it will mean a lot of work, have to be tested, balanced, rebalanced, etc. as well. I think M&B2 is the right place start with a whole new system.

Click to expand...

That was about quite different thing, specificly weapon system.
The idea was to eliminate or shorten the 'balance, rebalance' phase. You have to do this if you have made up arbitrary parameters like 100 'speed' or other 'something', you can't really tell what to do with them and have to adjust by trial and error. If they are relevant and specific like kilograms, meters etc.. you should be able to get it right beforehand without much tinkering.

Jack_Merchantson said:

re-settable-by-stopping-or-moving-forward top speed limit curve.

Click to expand...

Do you mean inertia by any chance?
It's implemented to a degree, not enough, but at least direction change is not instant.

Unfortunately poorly designed elements impact each other, so simply fixing one aspect without serious redesign of the whole thing won't do much good.

Related problems are ability to swing for full damage at hugging distance (absence of radial 'sweet spots'), hitboxes (see Reapy's slomo video, totally missed blows still score), no collision when thrusting (you can sink the side of the weapon through an opponent), thrust-block force field and so on.

Increased backspeed was a ridiculous workaround in hope to make things less ridiculous, but while seemingly fixing some aspects it broke others.

Vornne said:

I have given plenty of specific reasons it's bad, and so have others... turn limits also affect blocking, viewing, and movement

Click to expand...

You call them reasons, they are tautologies at best.
Yeah, limits do affect movement and so on, that's the idea behind them.

Vornne said:

The game's combat speed and fluidity relies on being able to quickly and accurately adjust your position, view, and where you will hit; the correct thing to do is to make the perfect swing deal the most damage

Click to expand...

If you call the ability to turn instantly anytime 'fluid' then we probably have different ideas about the meaning of the word.

Racing games made this leap decades ago. They rely on being able to drive quickly and accurately, yet all of them now implement turn limits, inertia and more. While affecting the 'ability to do anything anytime' it adds depth, makes them challenging and worthwhile.
Yeah, it requires more skill with limits, and WB actually could use somewhat steeper learning curve.

Shik said:

I may be in the minority, but I enjoyed the earlier patches with the so-called "clunky" turn limits. The problems with the patch were not the turn limit itself, but the fact that the turn limit was addressed independently of the general movement system, which also had flaws in it. The turn limit patch exposed the movement system problem - for things to work out, both have to be addressed. The current state with spinning is honestly not an acceptable status quo, IMO.

Click to expand...

Exactly.

glustrod said:

it may be not so important or call it nit-picking, but i'm distressed by your claim that reality is a well documented "system at hand". Reality is still way too complex for anyone and any machine to copy, you must allways approach reality as near as possible with tweaks and assumptions and, well, approaches. This goes also for such a small part of reality like the combat in M&B.

Click to expand...

Sure it is complex, we don't even know everything about it, and probably we'll never do.
But fortunately in this case going down to elementary particles is not required, the relevant part of reality is newtonian mechanics, which is well-known enough, do you agree?

Currently 'as near as possible' criterion is far from being fulfilled.

glustrod said:

Where do you get these real parameters from?

Click to expand...

Regarding weapon in motion, only the basic parameters like mass and shape are required, they are pretty straightforward to determine.

Orion said:

Good thing you'd have to be calculating it every millisecond during the swing animations to alter it based on other factors, such as collisions. If you're just standing there, of course it won't be calculating anything. Once you trigger a swing, it's going to start calculating.

Click to expand...

You insist on arguing stuff you got no idea about.
Calculating every millisecond is pointless, unless you want to display 1000 frames per second for some strange reason.
Equations involved are really trivial arithmetic, no matter how complex you imagine them to be.
Weapon position is calculated already anyway, but it's done wrong, using made up parameters and formulas. Replacing them with real parameters and equations makes no difference performance wise, contrary to your guesses.

It's enough to look around the forums and connect the dots. People are asking for sweet spots, weight based recovery time, balance etc.. Systems based on real parameters handle all this stuff natively and consistently, without the need for workarounds or exceptions.

Orion said:

I seriously doubt it's going to be changed what-so-ever, especially in the manner you're suggesting.

Click to expand...

Yes, I wrote that higher on this page, you'd notice if you read carefully. I've been watching this project for long enough not to have such expectations.

Jack_Merchantson said:

I wonder if it's the same server/client communication phenomenon that causes equestrian rubberbanding...?

Click to expand...

The difference is, rubberbanding cannot be avoided. Any delay makes client and server out of sync inevitably.
But input 'combos' can be reliably interpreted at client, and the final result can be sent to the server, instead of making it try to guess again.

Orion said:

From a game development standpoint, what you're asking for could quickly escalate to become a serious processing load that would skyrocket the minimum requirements for the game. Calculating all of these things every millisecond to generate the next frame is fine if you're dealing with one guy swinging his weapon. If you've got a server of 64 players, you're going to have 64 times as many calculations to make at any given moment.

Click to expand...

Anything 'could escalate and skyrocket', if you do it poorly enough.

No, calculations involved are simple, infrequent compared to other processing, performance impact within measurement error range. System redesign mostly involves replacing redundant, arbitrary and meaningless parameters, with relevant, well defined ones.

"Calculating all of these things every millisecond" - from a game development standpoint yes, calculating anything every millisecond is a silly thing to do. Good thing it's not required anyway