20 replies to this topic

[Dimento Graven]

I'll probably end up using a LOT of curse words that get filtered on this. I'm quite frustrated, frustrated to the point that if I had a programmer within reach, well... He'd better run, that's all I have to say.

I've posted about this before, basically how if a fast moving 'mech just happens to touch a terrain object (cliff, rocks, buildings, etc.) or happens to inadvertantly turn flat into one, how movement gets all sorts of screwed up. Basically I was told PGI had implemented some sort of predictive movement code as kludge to handle some of the issues being experienced with high speed 'mechs and server keeping accurate track as to their locations.

Now that you guys have addressed quite a bit of the netcode issues, you need to revisit and TONE DOWN your predictive movement code.

Something about how you guys handle 'collissions' and the 'predictive movement code' is basically casing a 'fly paper' affect when a fast moving 'mech runs full on into a large terrain object.

Now, normally what I see with slower moving 'mechs or a 'mech that happens to be moving slowly at the time of colliding with a terrain object, the mech can 'roll' off the surface by simply turning. However a fast moving 'mech pretty much has to stop, backup, THEN turn and begin moving forward again before it's even remotely possible to get away from the terrain object.

With the netcode fixes a fast moving 'mech will pretty much be dead by the time they get off the terrain object, no matter how they try.

On maps such as River City, Frozen City, certain areas of Caustic and Forest Colony, there's a lot of large terrain objects fast moving 'mechs can get stuck on. This can be especially bad in Forest Colony though since the 'polarization affect' of explosions tends to blind for such a long duration...

I can't say for sure, but the problem seems to be worse when there's a lot of fast moving 'mechs and/or objects on the map, say both teams are running LRM boats, and you have a two fast lights on each side, well when there's a lot of missles in the air, the fast moving 'mechs don't even have to run full on into a large terrain object, no as a matter of fact, all they have to do is graze it, and suddenly they're rubber banding all over the place.

I've had this happen in all the light and medium 'mechs and one or two of the heavies. The critical speed that this is most apparent seems to be somewhere around 80kph, and the faster you go the more prone to suffering this you become.

I've also seen similiar issues when one 'mech gets on top of another. For example, I was spectating a team member in a Spider hopping around and he's gotten rather good and jumping and landing on top of 'mechs. There were certain times where he'd land on top of another 'mech and 'ride around', and about half the time, both he and the 'mech he's riding start rubber banding.

I'm sure we'll see lots of trolling on this issue from the light and speedy 'mech haters out there, and some people who hate the heavier 'cheese' builds of the Catapault and Dragon variety, but I do believe there's a real issue here, that may get incredibly worse once 12v12 is activated.

So please, quickly look into it and address it.

Edited by Dimento Graven, 05 February 2013 - 10:18 PM.

[Errant Variable]

I noticed this start when they put in the big netcode fix (2 patches back?) and as a part-time Jenner driver, I like it. "Sliding" off a building seems cheesy, especially with tiny/fast moving mechs. If you prefer, think of it as having just made a cartoon-style Raven shaped crater in the side of a building and having to back out of it before you can get anywhere. There are occasional times where I get well and truly stuck in a major environmental object but those are usually piloting fails that should turn the mech into a burning wreck once such is implemented (140 KPH into a corner that you can't bounce out of will glitch you.)

It's a good problem.

Edited by Errant Variable, 05 February 2013 - 10:32 PM.

[Brilig]

I have run into this before. (No pun intended.)

You either have to stop and allow your mech to turn, or back up and turn away from what you are running into. If you are still throttling forwards you seem to be stuck, because you are still pushing your mech into the object. Honestly I am not sure there is anything wrong with this. If you slam up against a building you should have to stop, and back off to turn away.

I kind of expect that once they are done with collisions mechs will start knocking themselves over when they plow into large objects. It is probably best to start practicing not running into things.

If that is not how it is going to work, then maybe they could implement something that turns your throttle down to 0 when you hit a large solid object. Then you wouldn't have to slow down as if you were still moving at top speed before you can back up and turn.

Edited by Brilig, 05 February 2013 - 10:42 PM.

[Mild Monkey]

Ok, try to drive head on into a building with your car at a speed of, say, 30 mph. your car weighs but a fraction of what a light mech puts on the scales. if the car is still functional, you will need to shift in reverse and back off before turning and accelerating again. I even don't like it much that big assault mechs can glance off of obstacles at speeds as "low" as 50-60 kph. Your are right though when you say that the damage taken by light mechs upon collsion is too dang high. I mean, those are walking tanks, built to resist extreme damage, but the armour just peels off of them when the pilot is incompetent enough to bump into a brick wall?

[Voidsinger]

Welcome to the world we high latency players experience on a regular basis.

In fact, it was a collision extender field back when collisions were in.

There really is no way around it, other than to learn your mech's tolerances. There needs to be some predictive movement. That field extends as your mech speed and network latency rise.

Call it the downside of the lagshield effect.

[Bloody Moon]

And this is what happens when someone who barely knows anything about programming encounter words like "predictive algorithm".

There are a series of unavoidable issues this kind of algorithm can cause, what you explained shouldn't be one of them if the code works properly. It is more likely related to the movement code changes in general. So hold your horses.

[Dimento Graven]

Voidsinger, on 05 February 2013 - 11:16 PM, said:

Welcome to the world we high latency players experience on a regular basis.

In fact, it was a collision extender field back when collisions were in.

There really is no way around it, other than to learn your mech's tolerances. There needs to be some predictive movement. That field extends as your mech speed and network latency rise.

Call it the downside of the lagshield effect.

With no lag shield, or at the very least it SIGNIFICANTLY curtailed, why does there need to be such a severe predictive movement f'up tendancy now?

Also, I know my 'mech's tolerances, however '**** happens' and the fact that a 'mech moving below 80kph can easily 'roll' off a flat surface while a 'mech moving faster than that has to, stop, back up, turn, THEN move forward to do essentially the same thing a slower 'mech can, seems kind of silly.

I should still have directional control of my 'mech, and while my forward velocity is zero, while pushing against the building, my angle of movement should change until eventually I'm perpendicular to the surface I'm stuck on and at that point continue forward, ie: roll off the surface.

[Dimento Graven]

Mild Monkey, on 05 February 2013 - 11:00 PM, said:

Ok, try to drive head on into a building with your car at a speed of, say, 30 mph. your car weighs but a fraction of what a light mech puts on the scales. if the car is still functional, you will need to shift in reverse and back off before turning and accelerating again. I even don't like it much that big assault mechs can glance off of obstacles at speeds as "low" as 50-60 kph. Your are right though when you say that the damage taken by light mechs upon collsion is too dang high. I mean, those are walking tanks, built to resist extreme damage, but the armour just peels off of them when the pilot is incompetent enough to bump into a brick wall?

Not even going to deal with this response other than:

1. This is not a car.
2. This 'mech I'm driving has 2 legs, not 4 wheels, there's a significant difference in capacities for dealing with objects in front of you in this situation.
3. If this game were more complete, I'd crash THROUGH the damn building, as in original TT and we wouldn't even be having this discussion.
4. Incompetant is a strong word, especially in this game, where conditions of not being able to see past your 'mech's view screen are actually quite common, or where 'night' versions of maps have nigh invisible 'cold' terrain objects when using thermal, and you can't use night vision because your red-green color blindness makes differentiating friend and foe an extreme hassle.

Errant Variable, on 05 February 2013 - 10:31 PM, said:

I noticed this start when they put in the big netcode fix (2 patches back?) and as a part-time Jenner driver, I like it. "Sliding" off a building seems cheesy, especially with tiny/fast moving mechs. If you prefer, think of it as having just made a cartoon-style Raven shaped crater in the side of a building and having to back out of it before you can get anywhere. There are occasional times where I get well and truly stuck in a major environmental object but those are usually piloting fails that should turn the mech into a burning wreck once such is implemented (140 KPH into a corner that you can't bounce out of will glitch you.)

It's a good problem.

Any less cheesy than an 80 ton mech moving at 70kph 'rolling' off the same building with little to no problem?

[Mild Monkey]

Dimento Graven, on 05 February 2013 - 11:54 PM, said:

Not even going to deal with this response other than:

1. This is not a car.
2. This 'mech I'm driving has 2 legs, not 4 wheels, there's a significant difference in capacities for dealing with objects in front of you in this situation.
3. If this game were more complete, I'd crash THROUGH the damn building, as in original TT and we wouldn't even be having this discussion.
4. Incompetant is a strong word, especially in this game, where conditions of not being able to see past your 'mech's view screen are actually quite common, or where 'night' versions of maps have nigh invisible 'cold' terrain objects when using thermal, and you can't use night vision because your red-green color blindness makes differentiating friend and foe an extreme hassle.


Any less cheesy than an 80 ton mech moving at 70kph 'rolling' off the same building with little to no problem?

No offense intended, just slight traces of irony and sarcasm. Many's a time when I myself crashed into a building like that.
"If this game were more complete, I'd crash THROUGH the damn building, as in original TT and we wouldn't even be having this discussion." That I would like to see. Maybe we will see it.
As for the wheel/leg issue: OK, use your own body, the bipedal one. If you hit a wall at 90°, you will stop if you aren't Marvel's Juggernaut or the Hulk (you aren't, are you?). Other than that, yes, you would "glance off" of the wall and take some "damage". So while I have to agree that my image was a bit faulty, you have to agree that the physics implemented do not represent real life by any means.

[Errant Variable]

Considering that the 80 ton mech moving at 70kPH carries an identical amount of kinetic energy but spreads it over a much greater area, and given that it has double the momentum of the 20 ton mech... yes, I do consider it more plausible for an assault mech to keep going than the light mech. That I consider it most plausible that the assault mech would simply go *through* the building is irrelevant - we don't get that currently.

It's still a minor problem that only seems to crop up in cases that should at best land a mech flat on it's face, and more likely than not somewhat damaged, neither of which currently happen.

[Dimento Graven]

Mild Monkey, on 06 February 2013 - 12:09 AM, said:

No offense intended, just slight traces of irony and sarcasm. Many's a time when I myself crashed into a building like that.
"If this game were more complete, I'd crash THROUGH the damn building, as in original TT and we wouldn't even be having this discussion." That I would like to see. Maybe we will see it.
As for the wheel/leg issue: OK, use your own body, the bipedal one. If you hit a wall at 90°, you will stop if you aren't Marvel's Juggernaut or the Hulk (you aren't, are you?). Other than that, yes, you would "glance off" of the wall and take some "damage". So while I have to agree that my image was a bit faulty, you have to agree that the physics implemented do not represent real life by any means.

Yes, you're right I would stop, that part I expect, but while still driving myself forward I can still shift my weight and 'roll' from a perpendicular position to a more parallel position and move off the wall in that manner much in the same way heaver, slower 'mechs do in the game.

Oh yeah and for consistancy's sake:

1. My 'mech is not a human body.
2. My human body is only 240lbs, my 'mech's is at least 25 tons. The affects on walls at 'speed' will be signficantly different.

Errant Variable, on 06 February 2013 - 12:21 AM, said:

Considering that the 80 ton mech moving at 70kPH carries an identical amount of kinetic energy but spreads it over a much greater area, and given that it has double the momentum of the 20 ton mech... yes, I do consider it more plausible for an assault mech to keep going than the light mech. That I consider it most plausible that the assault mech would simply go *through* the building is irrelevant - we don't get that currently.

It's still a minor problem that only seems to crop up in cases that should at best land a mech flat on it's face, and more likely than not somewhat damaged, neither of which currently happen.

Actually in most circumstances, the light 'mech is taking damage to its legs.

What the difference is when, in those rare circumstances, it doesn't take damage, vs when it does, I haven't isolated yet. I "think" it might be due to some slight elevation difference right before the terrain object that you're bouncing up and down on as the predictive movement code holds you hostage to the terrain object.

[Apoc1138]

Dimento Graven, on 05 February 2013 - 10:18 PM, said:

Basically I was told PGI had implemented some sort of predictive movement code as kludge to handle some of the issues being experienced with high speed 'mechs and server keeping accurate track as to their locations.

The predictive bit of the movement code has always been in from the very beginning, they've recently improved movement code in general to make movement more accurate between clients and server, so if anything they HAVE toned down the predictiveness of the code.

Rubber banding is a whole 'nuther problem related to collisions code that hasn't even started being worked on / implemented yet.

The state rewinding code that you are probably thinking of is involved in SHOOTING not movement, in that it will rewind to the point you fired and then declare a hit or miss, instead of there being a big delay between you pressing fire and the server registering a fire event

Edited by Apoc1138, 06 February 2013 - 07:57 AM.

[Dimento Graven]

Apoc1138, on 06 February 2013 - 07:55 AM, said:

The predictive bit of the movement code has always been in from the very beginning, they've recently improved movement code in general to make movement more accurate between clients and server, so if anything they HAVE toned down the predictiveness of the code.

Rubber banding is a whole 'nuther problem related to collisions code that hasn't even started being worked on / implemented yet.

The state rewinding code that you are probably thinking of is involved in SHOOTING not movement, in that it will rewind to the point you fired and then declare a hit or miss, instead of there being a big delay between you pressing fire and the server registering a fire event

No, this is 100% movement at speeds greater than 80kph vs terrain objects.

It makes ZERO difference if anyone is actually firing at me.

Mucking around in Frozen City one time in a Spider I was near no one and decided to see if I could jump completely out of the back trench and found myself being smudged into a glacier wall that the game would NOT let me roll off of until I stopped, backed up, then turned around. Later, still being miffed by it, I took my Muromets and went to where I thought I'd gotten stuck, my Muromets weighing more than double the Spider was able to run 50kph, and just 'rolled' off the glacier wall in the manner I described.

If nothing else, make it so that NO 'mech can roll off solid surfaces to be consistant. Considering the lack of speed and acceleration heavies and assaults have, it will be quite painfull for them to have to go through the same process, even in pitched battle, and I know for dang sure those pilots are smacking into terrain objects all the time.

Edited by Dimento Graven, 06 February 2013 - 08:12 AM.

[Apoc1138]

Dimento Graven, on 06 February 2013 - 08:11 AM, said:

No, this is 100% movement at speeds greater than 80kph vs terrain objects.

It makes ZERO difference if anyone is actually firing at me.

Mucking around in Frozen City one time in a Spider I was near no one and decided to see if I could jump completely out of the back trench and found myself being smudged into a glacier wall that the game would NOT let me roll off of until I stopped, backed up, then turned around. Later, still being miffed by it, I took my Muromets and went to where I thought I'd gotten stuck, my Muromets weighing more than double the Spider was able to run 50kph, and just 'rolled' off the glacier wall in the manner I described.

If nothing else, make it so that NO 'mech can roll off solid surfaces to be consistant. Considering the lack of speed and acceleration heavies and assaults have, it will be quite painfull for them to have to go through the same process, even in pitched battle, and I know for dang sure those pilots are smacking into terrain objects all the time.

you've misunderstood the purpose of my post

you said in your OP that they RECENTLY ADDED predictive movement code, and that you want it toned down

I was pointing out that the movement code has ALWAYS been predictive and they recently DID tone it down (hence why lag shield is now reduced and movement is more accurate between clients and server)

when you say that you have been told that they RECENTLY ADDED predictive movement code, you might have been alluding to state rewinding, which a: hasn't been added yet and b: is nothing to do with movement

collisions, which is what you are talking about, are a 3rd known problem which haven't even been really started on... they did basic movement code first, now they are working on shooting (with state rewinding), THEN they are going to work on collisions... the problem you are experiencing is to do with collisions, which is a known issue and will be worked on next

Edited by Apoc1138, 06 February 2013 - 08:30 AM.

[Cybermech]

collisions are on the list of things to do
you won't see a decent fix for your problem until then.
expect melee to come into the game too.
think 12v12's and a few other things will be done before this.

I pilot lights too and it does get annoying.
But I got lag on my side

Edit: got their first Tice

Edited by Cybermech, 06 February 2013 - 08:28 AM.

[Tice Daurus]

Again, this problem that is being mentioned is KNOWN by the developers. I submitted this months ago in closed beta that the mech has to interact with the environment. This would include trees, rocks, water AND BUILDINGS. And that they would have to incorporate that when you interact with the environment certain things would happen:

1) You would slow down. You can't maintain a constant speed while interacting with the environment because something's have to give and slow you down.
2) Physics have to be involved. Glance off of a particular area at a certain speed, and then factor in a toughness rating for that certain piece of environment. Trees would be of a lower rating unless its one huge *** tree or a heavily wooded area. Buildings would be a a higher toughness rating with things to consider like ferrocrete, steel, glass, wood, etc. and depending on how you impact on the builing (did you glance the corner or go straight at the building?), how fast you hit the building (was it slow like 30 kph or 140 kph?) and how heavy you are (are you 20 tons or 100 tons?) plus a possible factor of how much engine power you have (is it a crappy 150 XL engine or are you putting out a ton of energy with a standard 400 engine?)
3) Depending on what you hit and how you hit it, do you take damage or just plow through it with no damage? It could be moving through deep water. It could be running through a heavy wooded area or trying to walk through a glass and steel building. Do you take damage and how much? According to TT rules, if you walked a mech slowly through an undamaged building you would take little to no damage as opposed to running into one.
4) How much damage does one take? Can the TT formula be transferred into the game with ease or do the developers have to come up with their own formula to properly reflect the right damage?

There are a TON of things to consider in this. Stuff that will take time. Stuff that will take to code out properly. Craploads of code. Then they would have to test it. Probably for at least a couple months of work before they can properly say it's at the right level. Then you have to BETA test it and allow the players to put in their imput if the damage is too much or not enough. Then debug it in case a certain area gives off an unusual amount of damage more than it should.

Personally I say this...

LET THE DEV'S DO THEIR JOB. And let them take their time doing it. Because there's no need to rush it. I'd rather settle for it being unrealistic NOW for several months down the road before they finally get the right formula and incorporate it into the game the right way instead of a crappy rushed job because we complained about it.

[RacerX]

I've also noticed my mechs sticking to buildings. My throttle acts sluggishly and my torso doesn't twist so well away from the object. It's almost like I crashed through the object without all of the fancy graphics and damage models that go along with such a collision.

I've also noticed walking through another mechs makes movement laggy as all heck. Not that anyone should be able to move through another mech. But it does happen and I suspect it is a symptom of the same issue described above.

[Taizan]

Can you somehow post a video? I have no clue what you are talking about. Is it because of the base velocity of the mech that gets carried on, although the mech came to a halt?
I tend to decelerate before walking towards a large structure.Never got stuck in buildings, only on some terrain details like the statues in river city etc.

[Dimento Graven]

Apoc1138, on 06 February 2013 - 08:19 AM, said:

you've misunderstood the purpose of my post

you said in your OP that they RECENTLY ADDED predictive movement code, and that you want it toned down

I was pointing out that the movement code has ALWAYS been predictive and they recently DID tone it down (hence why lag shield is now reduced and movement is more accurate between clients and server)

when you say that you have been told that they RECENTLY ADDED predictive movement code, you might have been alluding to state rewinding, which a: hasn't been added yet and b: is nothing to do with movement

Ah I see, just a bit of misunderstanding, here's what I actually wrote on that:

Quote

I've posted about this before, basically how if a fast moving 'mech just happens to touch a terrain object (cliff, rocks, buildings, etc.) or happens to inadvertantly turn flat into one, how movement gets all sorts of screwed up. Basically I was told PGI had implemented some sort of predictive movement code as kludge to handle some of the issues being experienced with high speed 'mechs and server keeping accurate track as to their locations.

Now that you guys have addressed quite a bit of the netcode issues, you need to revisit and TONE DOWN your predictive movement code.

There's no use of the word 'recent' there and in fact, in none of my posts on this thread have I even used the word 'recent' until this actual posting. Apoc used it in this sentance:

Quote

The predictive bit of the movement code has always been in from the very beginning, they've recently improved movement code in general to make movement more accurate between clients and server, so if anything they HAVE toned down the predictiveness of the code.

So that's probably where the confusion comes in.

Besides, I had thought the netcode fixes were completely seperate to the predictive movement coding which is what I thought was part of what the server was using to track position verses terrain and stuff, but since I've got no eyes on code, I admit I could be absolutely horribly wrong on that.

[Dimento Graven]

Tice Daurus, on 06 February 2013 - 08:27 AM, said:

LET THE DEV'S DO THEIR JOB. And let them take their time doing it. Because there's no need to rush it. I'd rather settle for it being unrealistic NOW for several months down the road before they finally get the right formula and incorporate it into the game the right way instead of a crappy rushed job because we complained about it.

I am letting them do their job, but personal experience says it's a bad idea to let developers do their job in a vacuum, locking them in a room and sliding pizza under the door every so often.

God only knows what you'll end up with...

Taizan, on 06 February 2013 - 08:29 AM, said:

Can you somehow post a video? I have no clue what you are talking about. Is it because of the base velocity of the mech that gets carried on, although the mech came to a halt?
I tend to decelerate before walking towards a large structure.Never got stuck in buildings, only on some terrain details like the statues in river city etc.

I'll see if I can't capture some. It's worse for me in River City Night where terrain objects are cold and thermal vision can't do a good job of 'seeing' them, or in either Frozen City, especially when the terrain skins don't completely load and all you have are a lot of flat gray blobs out there. Come at a building or wall at the right angle and it's invisible because it fades 100% in to the giant gray glacial wall that's 800 meters behind it...