1911 replies to this topic

[ShinVector]

Karl Berg, on 26 December 2014 - 11:32 AM, said:

And now the server view for this fire trace recreates the client state as seen by P2 when he took the shot locally on his machine.

Hopefully that clears up how things work a bit.

Just a simple question is the position of the shoot not be rewound the reason why shooting lasers on the move (especially at high speed) is generally bad for high latency players ?

Is this issue being address in the upcoming new year patches ?

Edited by ShinVector, 26 December 2014 - 12:10 PM.

[Karl Berg]

Bad Karma 308, on 04 December 2014 - 05:42 AM, said:

Karl a question on your processing routines;

Before I sold my company and retired, we were heavily involved in what is known as "Distributed simulation". Disseperate systems all cross-feeding data in real-time. When we were trying to handle large quantities of mathematical computations in real time we would wind up turning more and more to reliance on CUDA and GPGPU offloading. We were able to feed the majority of the simulation's computations out to GPGU servers and then re-ingest the returns with little to no impact on performance. Our data relies very heavily on angle detection/ray-trace/triangulation and clutter mapping. Very similar, if not identical, to many of the calculations your teams is experiencing.

I've been following several threads both here and in the normal forums discussing your rewind servers and particularly in relation to hit detection and registration . I wanted to ask if your teams had looked at the possibility of offloading the rewind state to a GPGPU machine. Our case is a bit extreme in both scale and funding, but I believe that even a single unit could benefit you greatly at very little cost. Most datacenters do have theses machine available and will co-locate them with your main servers.

A bit of our work: http://www.nvidia.co...study-final.pdf

Some other uses: http://www.nvidia.co...ons-domain.html

Very Respectively,


edited for spelling...

Exceedingly cool! Thank you very much for the links sir! I will definitely be reading through them in detail.

I've followed GPGPU work at a high level for some time, as it really seems to be the closest one can achieve to Cell / SPU style programming on a PC. I'm really excited to one day see that first GPU vendor really nail down an SPU style interface, with full application level control over DMA channels, a working C/C++ compiler for program binaries, and full intrinsics for assembler support, as well as 128-bit or better SIMD vector support. I initially thought AMD might provide such an interface when I first read about their new APU tech, but they seem to have taken a different direction. Regardless, once someone opens raw metal access with a decent API, I think the sheer number of FLOPs those GPU chips are capable of will simply explode in terms of high profile applications.

For us on the server side specifically, since our code is so integrated with CryEngine and CryPhysics, it would be a significant challenge to re-implement our HSR systems to use GPGPU algorithms. Being able to write external helper programs with explicit DMA control, as described above would mitigate that pain a great deal, since there would be potential for sharing code and potentially even reusing some of the PS3 job scheduling logic already built into the engine.

Client side, there are some super easy wins with GPU based particle simulation. Our version of CryEngine doesn't support GPU based particle simulation; and we haven't had the resources to attempt this rewrite ourselves yet.

Jman5, on 06 December 2014 - 10:16 AM, said:

Do you guys have Elo Decay so that players who have been absent for a year aren't suddenly treated like they never left? I imagine it would behoove you to ease returning players back into the game instead of kicking their butt for 50 games until their Elo falls out of the sky.

Nope, we don't. We simply rely on the Elo algorithm to perform the required adjustments once the user resumes playing.

[Karl Berg]

Void Angel, on 06 December 2014 - 07:14 PM, said:

Hey, Karl, I was thinking... and before the pain became too great, it occurred to me to ask about weapon hardpoints in relation to weapon balance and the quirk system.

Hardpoint placement is a big part of 'Mech balance - one of the Stalker's several advantages is its very high (above the head) energy hardpoints for its arms. This allows a stalker pilot who knows what he's doing to fire over a hilltop at a target that is completely concealded from his cockpit; he only pokes the tips of his arms up over the horizon and smacks someone. For a while, this fact was in the background of 'mech design; if you had high hardpoints, you used them; if you didn't have them, you chalked it up to the 'mech.

Until the advent of the Battlemaster 1G. The Battlemaster 1G has three hardpoints for energy weapons in each side torso - and while the top hardpoint is at head level, the lower two originate from below the 'mech's "clavicle." The higher mounts were nearly ideal for long-range sniping over hill crests, where they could hit targets that the lower weapons couldn't reach. The problem was, players had no control over where in those locations weapons were actually loaded into the game. You could, by adding weapons in a certain order, get the Large Lasers/PPCs/Whatevers on the top points in the Mechlab, but the game would load them in according to some preset order - with the long-range weapons on the bottom, unless you only filled the top two hardpoints! This was very frustrating to those of us trying to get the most out of our biggest Phoenix Variant (with the c-bill bonus, you understand,) and the response we got from PGI at the time was, "We never intended to allow players to choose which hardpoints a weapon goes in."

So, after all that, my question is: With the balance team now fine-tuning 'mechs on an individual basis, would the order a game loads weapons into hardpoints be something they'd consider, and - far more importantly - is it something they're considering when designing new 'Mechs?

Hey Void Angel,

As far as I am concerned, this is simply a bug with the way we handle weapon placement and hardpoints in the UI as well as the gameplay code. It's something that I would really like to see addressed as soon as we can, but there are complications with the way mechs are constructed at the data layer as well as in code. Gameplay has proposed a quick fix that would at least see ordering in the UI preserved in game, but this fix would force you to always fill hardpoints in the same order, potentially forcing you to spend tonnage in order to get a specific weapon in a specific hardpoint. Unfortunately there are no immediate plans to address this specific issue that I am aware of. We'll have to wait for the high priority CW work to taper off a bit first; and most likely this work would be coupled with the upcoming mechlab redesign.

[Karl Berg]

Mawai, on 08 December 2014 - 08:37 AM, said:

Hi Karl,

Hopefully you are still reading these comments. I had some questions about whether PGI has considered anti-griefing code for CW. Here are several situations that could be a concern ... and there are groups out there (in MWO and EVE) who have been known to execute such plans to intentionally disrupt the community.

1) Disruption of CW by having alts play intentionally badly on the opposing faction. Depending on what restrictions are in place, a group planning this could simply create new trial accounts, drop into CW with the opposing faction and intentionally lose matches. Most obviously by team-killing and less obviously by playing badly ... getting in the way of their team mates shots, doing some damage to team mates and perhaps issuing contradictory instructions or just causing confusion.

The most obvious methods of griefing involve placing "spies" or "sleepers" in the opposing faction ... and as long as your side already has enough or more players this is probably a winning strategy. This is perhaps less of a concern with organized merc corps but can be leveraged if lone wolves are allowed to participate in CW (which is probably a requirement to make CW accessible to a large enough fraction of the playerbase).

One extreme would be a player dropping using two clients ... they drop on their main in their actual faction and play the "derp" toon in the opposing faction by being mostly afk. It will be very hard to tell this situation from one where two friends happen to be playing from the same house.


2) At the present time there does not appear to be ammo re-supply implemented. Paul's November update mentioned ammo as a logistical resource. So what happens when players run out of ammo?

a ) They suicide by running at the other team. However, a smart opponent will realize that their weapons are disabled and will refuse to kill them.

b ) Their team mates TK them to get them into a more useful mech.

This situation argues for implementation of an eject functionality to allow players to abandon mechs that are damaged/out of ammo or otherwise don't fit the tactical situation ... since otherwise folks will ASK their team mates to kill them off so that they can get into a useful mech.

(Edit: 2 is covered by planned eject functionality)

I am sure there are other disruptive actions that can be taken ... PGI needs to come up with ways to address these first before they become problems. None of these are an issue with the current game because each match has no meaning or significance ... when large scale winning matters (at least to some folks) ... I can see some nasty behaviours potentially developing.

Edit: Just thought of another aspect.

3) In CW it makes more tactical sense to eliminate ONE player 4 times than to eliminate 4 players once. In the first case, the opponents will be permanently down one mech. So what will likely happen on the good teams? Vendettas. The team will be told that "Xname" is primary ... if you see them shoot them, if possible, kill them. In addition, if one of the opponents is known to be particularly good it is more likely that they will be chosen as the primary target on a regular basis. This just makes sense if you want to win a CW match.

Will this constitute "harassment" based on the game's TOS?

"Engaging in ongoing intimidation or aggravation of other individual or groups."

Calling someone primary repeatedly could well be interpreted as "intimidation". On the other hand, the limited respawn mechanic intrinsically favours this mode of play. This is much less of an issue in a game where a player has only one life or unlimited respawns.With limited respawns, getting that particular player eliminated can be very beneficial.

Good concerns,

We tried to address as many griefing mechanics as we could think of prior to beta launch, but ultimately we're going to have to address issues as they arise. The whole auto-win for no opposing team is one such mechanic that seems to be fairly unpopular, but addresses a very large variety of issues relating to queue movement and worst case wait times, population imbalances, and griefing by refusing to play.

There is little we can do about spies other than attempt to ban players running alt accounts, or accounts that don't show at least minimum levels of activity in CW matches. Luckily we haven't really had an issue with this yet, but that's not to say we won't have to address this in future.

Focusing a specific player to remove them completely from the game seems like a fairly sound strategy. I don't know that there are any rules against this behaviour, but due to drop timers alone, it would take several minutes for the team in question to accomplish this goal.

[Karl Berg]

Goose, on 10 December 2014 - 10:26 AM, said:

Say, Karl, do y'all Devs have any sense on how the Elo distribution shifts around with the into of new units?

Not really at such a low level as a new unit forming over time, no. Hypothetically we could data-mine this for a specific unit; certainly sounds like an interesting question.

[Karl Berg]

Deathlike, on 21 December 2014 - 09:45 AM, said:

I would like to know what determines when a launch is an actual Attack (when attacking) instead of Holding (when attacking). Same application goes for Defending (when the game decides it should be a "Counter Attack").

I'm hoping it's not just a "die roll" (RNG), because I've always felt when running Attack contracts, that most of the matches tend to be for "defense"/holding and playing a severely high number of them in a row (this has been the general theme among people I've asked).

Hey Deathlike,

Lots of confusion stemming from this it seems. Throughout the entire design, CW is designed as a very roleplaying like territory conquest meta-game. Each planet in the inner sphere is divided into a set of states or territories, each territory has an ownership state (defender or invader), and each territory can only field a single match at a time.

Given this setup, here is how CW works:

All territories start as owned by the defenders. Defenders can queue up to defend this planet, but no matches will ever kick off, as there is simply no objective for the defenders to accomplish on that planet at that time. Once a 12-man invasion team forms, they will lock down a specific territory to invade, and a match will form.

To add some flavour, say territory 1 on Trell I was actually Sarghad. Your 12-man invasion strike team would be dropping to take Sarghad for CJF. Fortunately for you, GDL left Trellwan some 30 years prior for more lucrative contracts, and took the best anti-mech personnel the planet had to offer with them; so you only have to deal with the 12th Donegal, and Victor runs away. You drop, destroy the 12th Donegal Guards, take out the automated defenses, and Sarghad, along with it's spaceport, is now yours.

We have the ability to customize map and game mutators per territory, so every time you drop on Sarghad on Trell I, you will always see the same map and mutators. As we add more maps and time of day, hopefully this will become a more relevant feature.

Alright, so invaders now own one territory on Trell I, defenders still own 14. Until that first match ends and victory is awarded to CJF, Sarghad is still considered owned by Steiner. We only support 24 players in a single match, so no more players can drop on Sarghad, but there are 14 other territories open on Trell I for battles to form. All of them are currently owned by the defending faction, so no more matches will kick off until an invading strike team forms up. Defenders can queue and form 12-man teams, but you're going to wait in a pre-lobby state indefinitely for that attacking team to form up first, or for that first game to end so you can initiate a counter attack.

To fall back on my diagramming skills:


At the input side, there are queues of groups per planet, per faction. Those quickly form up into pending strike teams of 12 players. That pending strike team queue is a FIFO queue that needs to wait for a pending lobby. Only one pending lobby is allowed per planet at a time, and it is at this time that the territory and game rules are selected for a match. If the territory is owned by defense, the invaders will be attacking and the defenders will be holding. If the territory is owned by the invaders, then the invaders will be holding, and the defenders will be attempting to reclaim that territory by counter attacking.

To answer your specific question, the backend attempts to alternate between attack and counter attack games to give equal chance to both defenders and invaders. It does this by blocking specific match types from forming for a small amount of time, currently set to 5 seconds. For example, if the last match was an attack, the backend will refuse to initiate another attack game for about 5 seconds, only allowing a counter attack game to form. If no defending 12-man is available to initiate a counter attack for those 5 seconds, that lockout will expire, and the backend will allow another attack game to form for a different territory instead.

Again, the whole system is designed from the ground up to operate in a persistent manner. Territory 1 on Trell I represents a specific region in space for us that has ownership properties, and associated map and mutator data. To keep things consistent, we simply don't allow multiple games to take place in the same area at the same time.

[Karl Berg]

p4r4g0n, on 26 December 2014 - 11:40 AM, said:

btw Karl,

Merry Christmas and a Happy New Year

Thanks p4r4g0n! Happy holidays to you and your family, and to everyone else as well! If you did log in, hopefully you enjoyed our festive innersphere map yesterday.

[Karl Berg]

ShinVector, on 26 December 2014 - 12:08 PM, said:

Just a simple question is the position of the shoot not be rewound the reason why shooting lasers on the move (especially at high speed) is generally bad for high latency players ?

Is this issue being address in the upcoming new year patches ?

There are a few issues in play for lasers. Now that I've given a basic description of how things work, due to legacy code issues and a couple algorithmic gotchas, lasers are currently the only system that rewind based on your computed ping, instead of rewinding to a specific server timestamp. This means the more asymmetric your connection quality, or the more variable your latency, the worse laser HSR performs. This is most definitely on our list of things to address in the new year.

[Cimarb]

Karl Berg, on 26 December 2014 - 12:45 PM, said:

Not really at such a low level as a new unit forming over time, no. Hypothetically we could data-mine this for a specific unit; certainly sounds like an interesting question.

Not 100% sure, but I think he meant "unit" as in new mechs. So, when the Timber Wolf was released, how did that affect the Elo distribution? (correct me if I am wrong, Goose)

[Rebas Kradd]

Karl,

How is morale in the PGI offices? You guys have had a hell of a comeback this fall and I hope you know how much we appreciate everything you've accomplished.

[Void Angel]

Jody Von Jedi, on 26 December 2014 - 11:11 AM, said:

He lives!

I thought this thread was dead.

JK, I know you all have been really busy with CW. Thanks for keeping the thread alive, Karl.

Jody

I always assume people are dead if I haven't heard from them for a while. It saves me a bundle on Christmas cards.

Karl Berg, on 26 December 2014 - 11:55 AM, said:

The tick rate issue was caused by an OS update that adjusted the default resolution of the windows scheduler, so that any blocking system call would cause that thread to sleep far longer than prior to the update. From what I can tell, Microsoft made this change to improve battery usage on Windows tablet devices, and decided it would be great to propagate that change to their server OS.

It's so nice to know that Microsoft is punishing other people than PC owners for not having a tablet.

Karl Berg, on 26 December 2014 - 12:32 PM, said:

Hey Void Angel,

As far as I am concerned, this is simply a bug with the way we handle weapon placement and hardpoints in the UI as well as the gameplay code. It's something that I would really like to see addressed as soon as we can, but there are complications with the way mechs are constructed at the data layer as well as in code. Gameplay has proposed a quick fix that would at least see ordering in the UI preserved in game, but this fix would force you to always fill hardpoints in the same order, potentially forcing you to spend tonnage in order to get a specific weapon in a specific hardpoint. Unfortunately there are no immediate plans to address this specific issue that I am aware of. We'll have to wait for the high priority CW work to taper off a bit first; and most likely this work would be coupled with the upcoming mechlab redesign.

Sweet! I know it's way down on the list of Things To Do - after all, it only affects a handful of chassis - but in those chassis, I'd almost be happy spending an extra ton or two on small lasers in order to get my top hardpoints filled like I want them to be. Thanks for the response.

PS: Tell everyone we said Merry Christmas and Happy New Year and/or Holiday of Your Choice.

[Alaskan Nobody]

Rebas Kradd, on 26 December 2014 - 03:06 PM, said:

How is morale in the PGI offices? You guys have had a hell of a comeback this fall and I hope you know how much we appreciate everything you've accomplished.

This would be one of my biggest concerns.

[Wintersdark]

Rebas Kradd, on 26 December 2014 - 03:06 PM, said:

Karl,

How is morale in the PGI offices? You guys have had a hell of a comeback this fall and I hope you know how much we appreciate everything you've accomplished.

I'm going to second this.

Post IGP PGI has been amazing. I don't know if this is because of IGP, or just because PGI has turned over a new leaf, but you guys have been consistently hitting it out of the park since then.

I don't know if you're really aware of it or not, but yeah... We're all really happy to see it, and we're very grateful for it too. The second half of 2014 has been amazing for MWO, and I can't wait to see how the new year goes!

[Modo44]

Thing is, I get randomly bad hit registration despite <1 ping jitter and a high-speed connection (90 Mbps both ways). One match goes great, another has half my shots disappear into thin air. Be straight now. Is the system hurting on communication latency issues? Are there too many CryServer instances per physical server? Or maybe buggy CryServers crapping out? Something else?

[Sereglach]

Dear Mr. Berg,

For one, I have to agree with the sentiments that PGI has been doing amazing things since the separation from IGP. I greatly look forward to seeing what the new year has to bring. With that said, it ties into my question:

First, a little backstory. Long ago (back in January of 2014) we were told that the Flamer would be receiving a rework that was going to tie in with the release of the Firestarter. In February we received word that it was in engineering's hands and that they were making progress on it, here: Paul Inouye's Feb 24th Quick Update. Then, in September, we were told here, by Russ, that nothing would be happening until they've finished frying the big fish (CW Phase 2 release).

Now that CW Phase 2 has released, do you know if Flamers are back on the table yet? or when they will be addressed again? Any ideas what they're planning on doing to them?

Trust me, as my signature and stats show, I've got plenty of experience with them (currently sitting on over 74k flamer damage between current and archived stats), and plenty of ideas to help. I'll be happy to do whatever I can to assist in it. They're my babies and I hope you forgive me making the direct prod to see if there's anything being done to help them out.

Thank you for your time and consideration.

[p4r4g0n]

Modo44, on 26 December 2014 - 10:38 PM, said:

Thing is, I get randomly bad hit registration despite <1 ping jitter and a high-speed connection (90 Mbps both ways). One match goes great, another has half my shots disappear into thin air. Be straight now. Is the system hurting on communication latency issues? Are there too many CryServer instances per physical server? Or maybe buggy CryServers crapping out? Something else?

Or might the massive and repeated DDoS attacks that took out several gaming networks and other sites since late November be causing dropped packets leading to the recent increase in dodgy hit registration?

[ArchSight]

Karl Berg, on 26 December 2014 - 02:01 PM, said:

To fall back on my diagramming skills:

Ah ha, I was right that a premade will only be able to affect a single zone. This means to take a planet with only our unit we'll need 8 premades or 15 premades. 8x12=96 players,15x12=180 players.

[Wintersdark]

ArchSight, on 27 December 2014 - 03:45 AM, said:

Ah ha, I was right that a premade will only be able to affect a single zone. This means to take a planet with only our unit we'll need 8 premades or 15 premades. 8x12=96 players,15x12=180 players.

One zone at a time. One group can absolutely capture all the zones. Have done it a few times.

[Void Angel]

Ditto.

[Goose]

Karl Berg, on 26 December 2014 - 12:45 PM, said:

Not really at such a low level as a new unit forming over time, no. Hypothetically we could data-mine this for a specific unit; certainly sounds like an interesting question.

Cimarb, on 26 December 2014 - 03:00 PM, said:

Not 100% sure, but I think he meant "unit" as in new mechs. So, when the Timber Wolf was released, how did that affect the Elo distribution? (correct me if I am wrong, Goose)

The later was where I was going ("intro" was to have been the phrase,) but Karl's version sounds like great fun: Do Teams learn/ adapt meta faster then PuGs?

It's part of my quest to get Elo-per-'Mech, in which I didn't hear a "no" in that one Podcast, the way the reporting on the Podcast said it had …

While I'm here: We've gotten a couple of statements along the lines of "this loads the GPU, while that loads the CPU," and as time has gone one, I find this less and less adequate. I just had one small test where I'd turned up everything 'cept Object Detail and Damage Glow, and gotten good results. In retrospect, it seems obvious a hexacore like me could'a done something like that, and even then I'm assuming Teh Object Slider effects the ca_thread0Affinity the most above the others.

I've got this half-formed list of things like "Shaders moves GPU Load 10 percentage points at a time" that I still need to test out, but it'd be nice if we could get something from Y'all Devs on the subject; Something concise …