1911 replies to this topic

[Mawai]

Kageru Ikazuchi, on 16 September 2014 - 06:25 AM, said:

Now, please understand, this is based on my experience (~200 ping), but ever since server-authenticated hit effects went live, it has taken me about a quarter to a half a second to see the reticule go red even when I score a solid hit point blank.

While it may be "working intended" it is also very frustrating, and potentially very dangerous when you're waiting for the laser burn to stop before twisting.

I don't think there is any way to fix this ...

Your client sends the aim and fire information to the server ... 200ms
The server processes your line of fire and target locations ...
The server send back to your client whether you hit or not ... 200ms

A minimum of 400ms or 0.4 seconds to receive information about whether your hit was effective or not.

The problem is that the location where the target is drawn on your screen may not be where the target is on the server when you fire. Host state rewind fixes some of the lag induced issues on mech position but may not compensate for all of them since the target mech may have changed course between updates and won't be properly drawn on your client until later.

You do NOT want client authoritative hit detection. When hit detection is on the client ... it is possible to hack the client so it won't miss ... the client sends only perfect hits to the server ... and so does everyone else's client who has it hacked. Server authoritative decisions reduce the amount of cheating at the expense of situations like the one you have encountered.

The old system turned the reticle red when you appeared to hit on the client ... but this did not mean your fire actually hit on the server. Most people preferred to know whether you were actually hitting rather than whatever the client believed.

Edited by Mawai, 16 September 2014 - 07:58 AM.

[TheCaptainJZ]

Mawai, on 16 September 2014 - 07:57 AM, said:

The old system turned the reticle red when you appeared to hit on the client ... but this did not mean your fire actually hit on the server. Most people preferred to know whether you were actually hitting rather than whatever the client believed.

What old system? The red reticle was always a confirmation from the server for a real hit, but before, the graphics were completely client rendered. Your client might have shown an impact explosion when in fact you totally missed. But the red crosshair was true. Unless you are thinking of a time back in Beta when it was different. I remember a dev saying this is how it worked. Might even have been Karl himself.

[EoRaptor]

I have a question about the matchmaker. If it's been answered before, please say so, and I will hunt further through this thread.

The group selection screen is currently set up to allow the following:

1-10 players have a restriction of 3/3/3/3.

This leads to matches where I see lances of 3 direwolves and a timberwolf, or 3 timberwolves and a direwolf, often on the same team.

Would not a more layered selection screen provide better matching?

1-4 players get 1/1/1/1
5-7 players get 2/2/2/2
8-10 players get 3/3/3/3

I know people want to play with their friends in mechs they think are their favourites, but that leads to 'their favourite mechs' being 'the best mechs possible within the 3/3/3/3 restriction so I can win most often'.

Long term, if I mentally play out the consequences of tighter balancing, it's better balanced matches with less matchmaker tonnage balance failures, which I think would lead to a better playstyle (more mech variety, more teamwork).

I'm sure PGI has considered this, it seems too obvious not to. Can you provide any info on the reasoning behind the current choice within the restrictions of company confidentiality, etc. The short term pain of tighter restrictions before the matchmaker takes over seems to be worth the long term gain, even if there is much objection to it.


A follow-up idea to such a layered queue is to give the server authority to override this restriction if the game queue is starved of a weight class. A selection of random groups who are yet to launch would be a given a 'token' that would bump up one of the tonnage restriction numbers for that group. If the token is redeemed, it stays until the person who redeemed it changes mech weight.

e.g. A group of 3 has 1/1/1/0 selected, but the server is starved for lights. The 1/1/1/1 at the top changes to 2/1/1/1 and visibly flashes the change. If one of the pilots switches mechs to a light (it doesn't time out, so they have no rush to do this, but the token expires if the group launches without redeeming it), the token is redeemed and the group can now drop 2/1/0/0 until the person who switched switches again.

The server has a limit on the tokens it can hand out, to prevent positive feedback loops or other weirdness.

(Editing to clarify group queue word usage confusion)

Edited by EoRaptor, 16 September 2014 - 12:35 PM.

[Cimarb]

EoRaptor, on 16 September 2014 - 10:35 AM, said:

Spoiler

I have a question about the matchmaker. If it's been answered before, please say so, and I will hunt further through this thread.

The group queue is currently set up to allow the following:

1-10 players have a restriction of 3/3/3/3.

This leads to matches where I see lances of 3 direwolves and a timberwolf, or 3 timberwolves and a direwolf, often on the same team.

Would not a more layered group queue provide better matching?

1-4 players get 1/1/1/1
5-7 players get 2/2/2/2
8-10 players get 3/3/3/3

Spoiler

I know people want to play with their friends in mechs they think are their favourites, but that leads to 'their favourite mechs' being 'the best mechs possible within the 3/3/3/3 restriction so I can win most often'.

Long term, if I mentally play out the consequences of tighter balancing, it's better balanced matches with less matchmaker tonnage balance failures, which I think would lead to a better playstyle (more mech variety, more teamwork).

I'm sure PGI has considered this, it seems too obvious not to. Can you provide any info on the reasoning behind the current choice within the restrictions of company confidentiality, etc. The short term pain of tighter restrictions before the matchmaker takes over seems to be worth the long term gain, even if there is much objection to it.

A follow-up idea to such a layered queue is to give the server authority to override this restriction if the game queue is starved of a weight class. A selection of random group queues would be a given a 'token' that would bump up one of the tonnage restriction numbers for that group. If the token is redeemed, it stays until the person who redeemed it changes mech weight.

Spoiler

e.g. A group of 3 has 1/1/1/0, but the server is starved for lights. The 1/1/1/1 at the top changes to 2/1/1/1 and visibly flashes the change. If one of the pilots switches mechs to a light (it doesn't time out, so they have no rush to do this, but the token expires if they drop without redeeming it), the token is redeemed and the group can now drop 2/1/0/0 until the person who switched switches again.

The server has a limit on the tokens it can hand out, to prevent positive feedback loops or other weirdness.

I think the tiered approach is a very good one, but not the token system, as that is a large addition to the existing system's complexity, as well as the process itself, as you then have to effectively kick the group out of the queue so they can use the token or not, re select mechs and re queue.

(Edited for brevity spoilers)

Edited by Cimarb, 16 September 2014 - 11:10 AM.

[EoRaptor]

Cimarb, on 16 September 2014 - 11:08 AM, said:

I think the tiered approach is a very good one, but not the token system, as that is a large addition to the existing system's complexity, as well as the process itself, as you then have to effectively kick the group out of the queue so they can use the token or not, re select mechs and re queue.

(Edited for brevity spoilers)

Ah, sorry. I think I used terms in a way that is confusing. Edited the post.

When I said group queue, I meant the group mech selection and readiness screen, not the actual matchmaker powered queueing system. My apologies.

This does mean the server has to 'sniff ahead' at what people are selecting before hitting launch, but this should be happening anyway, to make sure the mech percentages are sort of correct. (If the mech percentages are based on on what is currently playing, then they are meaningless in relation to what might soon be playing, as those figures are not connected)

Edited by EoRaptor, 16 September 2014 - 12:37 PM.

[Cimarb]

EoRaptor, on 16 September 2014 - 12:33 PM, said:

Ah, sorry. I think I used terms in a way that is confusing. Edited the post.

When I said group queue, I meant the group mech selection and readiness screen, not the actual matchmaker powered queueing system. My apologies.

This does mean the server has to 'sniff ahead' at what people are selecting before hitting launch, but this should be happening anyway, to make sure the mech percentages are sort of correct. (If the mech percentages are based on on what is currently playing, then they are meaningless in relation to what might soon be playing, as those figures are not connected)

The mech percentages are based off of who is in the queue currently, not who is already in drops. Karl answered that a while back.

Edited by Cimarb, 16 September 2014 - 01:21 PM.

[Kageru Ikazuchi]

Mawai, on 16 September 2014 - 07:57 AM, said:

(stuff)

Concur ... and I think I mis-spoke (typed) at least once in my original post ... where those of us with moderate ping have always had to wait for the reticule flash, the graphic hit result was instant (and may have given some people a false sense of gratification).

While everyone wants perfect hit reg and instant ping, I'd also like for everyone to be able to have a constructive disagreement without slinging names and mud at each other ... but this is the internet ... perfect hit reg and instant ping are not reasonable expectations, anymore than the other stuff.

[Lordred]

Karl Berg, on 15 September 2014 - 11:22 PM, said:

That's an impressive document! I am not aware of any plans, but that doesn't mean none are in place. I'm guessing each of those resolutions was chosen by an artist as being the 'best' tradeoff between patch size and visual quality. That said, Dennis surprised many of us with the HPG hitbox fixes recently.

Thanks for the response again Karl, and thanks for the compliment. Keep up the fantastic work.

[Kyrie]

This thread continues to be amazingly awesome. I love checking in here for hidden gems every few weeks, the info here is priceless. Thanks once again Karl!

[Chronojam]

Ask the Karl is way better than Ask the Devs.

[Bad Karma 308]

Karl,

1.) Several patches back the SLI option made an appearance but was DOA, and removed a couple of hours later in a hot fix. Is there any update from your guys on when it might return?

2.) Also, Lately I've noticed some strange occurrences with weapons on weird "Ghost" trajectories.

Often it is with PPCs. What I'll see is that when someone else fires a PPC, A PPC bolt will occur, but it will originate from where there isn't any mechs. Most times it will originate from a very high altitude from where there is no terrain or mechs even possible. And no it isn't from a Jump jetting mech. The bolt will often originate and terminate just like the bolt from the mech who fires it. But again its origin and termination are way off axis and do not correlate to the actual shot in anything but maybe its trajectory.

If this isn't something you guys know of let me know and I'll try to get some screen captures/videos of it happening.

Very Respectively

Edited by Bad Karma 308, 17 September 2014 - 11:24 AM.

[Kyrie]

Bad Karma 308, on 17 September 2014 - 11:23 AM, said:

Karl,

1.) Several patches back the SLI option made an appearance but was DOA, and removed a couple of hours later in a hot fix. Is there any update from your guys on when it might return?

2.) Also, Lately I've noticed some strange occurrences with weapons on weird "Ghost" trajectories.

Often it is with PPCs. What I'll see is that when someone else fires a PPC, A PPC bolt will occur, but it will originate from where there isn't any mechs. Most times it will originate from a very high altitude from where there is no terrain or mechs even possible. And no it isn't from a Jump jetting mech. The bolt will often originate and terminate just like the bolt from the mech who fires it. But again its origin and termination are way off axis and do not correlate to the actual shot in anything but maybe its trajectory.

If this isn't something you guys know of let me know and I'll try to get some screen captures/videos of it happening.

Very Respectively

SLI was discussed by Russ in the Town Hall. The bottom-line summary is that ultimately we should not expect much out of it given the nature of CryEngine being more of a CPU hog. It will be making it back into the game at some point though from what I understood.

[Jonathan Paine]

Dear Karl Berg.

First of all, I thoroughly enjoy your participation on the forums and your insightful comments. Furthermore, I loved what you did to the match maker. The single player queue tends to produce close and interesting games. The group queue was amazing for roughly one week, and has been going down hills ever since. Is there any chance you will look over the data and the code and try to figure out why we are back to rolls in one direction or the other as the modal type of game? And yes, I do have some screenshots to back this up.

[Goose]

Sir:

How where the Anti-Alising options chosen? I keep wondering if SMAA 2xT might not have been handy to have around …

[Jman5]

Karl Berg, on 15 September 2014 - 11:32 PM, said:

No, I don't have those figures on hand myself. That's a very interesting question though, so I'm going to ask it myself tomorrow. It all hinges on whether or not gameplay has been tracking time spent on a per-game mode basis.

There is definitely a major difference in earning for Conquest game mode. Last I checked, this was the breakdown in cbill earnings:



One of the problems with Conquest is that you get doubly punished for losing, so over several dozen games it really adds up. In Skirmish and Assault, the only cbill hit you take for losing is the loss of salvage. In Conquest, the loser gets zero salvage and reduced resource bonus awards. Then you have to take into account that most players will play it like Team Death Match regardless of mode and ignore resource nodes. In Conquest the awards for normal team deathmatch stuff is basically halved.

Personally, I earn on average about 20% fewer cbills per match in Conquest than Skirmish even though my W/L ratio is slightly higher in Conquest. Unless I can play 20% more matches per week of conquest than skirmish, it doesn't make much economic sense to play Conquest.

If you want cbill parity between the game modes it probably would make sense to either make the resource rewards equal for both winners and losers, or add some alternative reward that's unique to Conquest. Maybe a team-wide reward for being the first to capture a point. Or perhaps make it less cut-throat and it could be rewarded the first time your team caps that point regardless of whether or not the other team got there first.

Edited by Jman5, 22 September 2014 - 08:46 AM.

[Modo44]

Jman5, on 22 September 2014 - 08:20 AM, said:

Then you have to take into account that most players will play it like Team Death Match regardless of mode and ignore resource nodes.

That is incorrect. Only very high Elo matches on small maps end up with no/limited caps. Most of the time, 2 caps running for each team is the minimum -- for the entire match.

[Mawai]

On the topic of conquest earnings ...

If you pilot a light mech and cap as you might be expected to do ... to help win ... you get very little rewards since most of the rewards are combat related and standing on a cap point for long periods of time involves little combat. Your team may win the match as a result ... but you personally lose. As a result, I almost never play conquest any more.

[Wintersdark]

Modo44, on 22 September 2014 - 08:53 AM, said:

That is incorrect. Only very high Elo matches on small maps end up with no/limited caps. Most of the time, 2 caps running for each team is the minimum -- for the entire match.

This is definitely my experience. I find the majority (though not a huge majority) of my conquest matches end via kills, but almost all of the matches feature scores of at least 350-400 per team. Only in extreme rolls does a team ever lose before then, really, and it's extremely rare for me to see a team not grab at least two points immediately.

With that said, overall Conquest earnings are definitely lower, and need a look. I'd argue that the best way to go is to just increase the point based awards overall to bring them up to parity. Lower rewards for a loss is fine, though it should be better than 25%; say 60%.

This is fair enough, because generally speaking on a loss in Assault or Skirmish, where rewards are based on kills, assists, component destruction and damage done, you're also "doubly punished" in that most of the time, the losing team is also not getting a lot of that done (that being why they lost).

[Shlkt]

Jman5, on 22 September 2014 - 08:20 AM, said:

Or perhaps make it less cut-throat and it could be rewarded the first time your team caps that point regardless of whether or not the other team got there first.

I really like that idea. I think it would encourage a lot more dynamic action on small maps in particular. Might be a bit boring on Terra Therma... but frankly the only way to fix that map is to move the cap points closer.

[Void Angel]

The problem is that the best PuG tactic is usually to go smash the nearest enemy forces rather than focus on the objectives immediately, because winning that first fight then gives you the advantage in winning via combat or via capping. That's why so many people play Conquest like it's a Skirmish map. Of course, splitting off lights to cap (Inner Sphere lights, at least) is a good tactic, but as Mawai points out...

Mawai, on 22 September 2014 - 08:54 AM, said:

On the topic of conquest earnings ... If you pilot a light mech and cap as you might be expected to do ... to help win ... you get very little rewards since most of the rewards are combat related and standing on a cap point for long periods of time involves little combat. Your team may win the match as a result ... but you personally lose.

...that causes you to forgo even the cut-down combat rewards in Conquest. Ditto for winning via killing the enemy team, though - if you do it too well, you end up not gathering many resources, unless you literally stop killing to cap.

Conquest feels like it punishes you for doing the things it takes to win, especially if you do them significantly better than the other team. The only way to maximize Conquest earnings is to get both combat and resource rewards - and that requires either a close match (difficult with cumulative focus fire) or stopping short of killing the last guy or two in order to game the system for resource points. There are interesting interactions where a fast survivor or group can work the cap points to compete, or even win, against the winners of the main body engagement, but those didn't seem that common for me - and the c-bills/time was still suspect. We'll have to wait for Karl to get back to us with demographics on that score before we know for sure, however.

Edited by Void Angel, 22 September 2014 - 10:13 AM.