1911 replies to this topic

[Cimarb]

Mawai, on 15 May 2014 - 08:24 AM, said:

Yes. A dynamic matchmaker would need to be able to factor in group composition and make sure they are not stuck in the queue too long. (i.e. A 3 light/1 medium group when lights are the limiting factor) ... dealing with this will mean either more games launched with fewer light mechs for everyone else or somewhat longer queue times.

I really like the dynamic matchmaker idea, and would love if they implemented that, but the problem is they aren't trying to make matchmaker fit the population, but force the population to fit the matchmaker by forcing 3/3/3/3.

Showing us the current weight distribution and/or wait times would be a much easier and successful way to approach that goal.

Another option would be to incentivize under-represented weight classes with bonuses, just like they did with WoW's group finder system, where tanks and/or healers got rewards for queuing and completing the instance. To go along with that, making an actual BV system that "grades" a mech on its loadout instead of base chassis would also be great, as you wouldn't have issues with a DDC being matched up against an Awesome as "equal".

[Jonathan Paine]

Hi Karl.

I understand that fully destructible terrain & buildings would require massive amounts of work. However, would it be possible to have the annoying small stuff be destructible. Nothing ruins a good sim like having an alleged 100 ton mech travelling at 60 kph stop completely because it ran into a slightly larger than human sized statue.

Suggested elements to be either removed from the game, or made destructible:
Statues!
Road signs!
Puny cars!
Puny rocks!
Puny trees!
Puny remnants of dead mechs!

Thanks!

[Nothing Whatsoever]

I was wondering if there are any more elements to how heat builds and dissipates when firing weapons (than what is generally known)?

For example, when we fire a Laser, does the heat generated start to dissipate at the end of the beam duration, or does heat start to dissipate at the start of the beam?

And if we hold down the trigger, do certain weapons build up more heat then known up to a certain limit (for example would a Medium Laser eventually build up to 5 heat from 4, separate from Heat Scale penalties)?

I hope my questions make sense, since I'm not entirely sure how to properly phrase them. My curiosity was recently piqued after thinking about heat again from here.

[DeathlyEyes]

Going back to what Krinkov said. I also have an fx processor, fx 8320. I have been having FPS issues and noticed they go completely away if i disable the hud using F11. So I did some experimentation with some settings relating to scaleform. I set this in my user.cfg

Spoiler

gp_option_ShowCockpitGlass=0
r_DepthOfField=0
r_HDRGrainAmount=0
sys_flash_address_space = 536870912
gfx_ampserver = 1
gfx_loadtimethread =1
sys_flash_allow_reset_mesh_cache = 1
ca_KeepModels = 1
r_TexturesStreamingOnlyVideo =1
gfx_loadtimethread = 1
gfx_inputevents_triggerrepeat = .016
r_MultiThreaded = 1
sys_MaxFPS = 60

I suspect the biggest help came from gfx_inputevents_triggerrepeat = .016 I am not entirely sure what it does but I think it forces scaleform to reuse frames so that a scaleform frame is presented every .016 seconds so it always has something ready for the game. But I am not sure.

I was also wondering if you guys could reduce the rate that UI items update individually. Maybe you could make it so that heat, map and other data not entirely fluid sensitive refresh less often (perhaps every 3 frames) to reduce lag while keeping elements like aiming at real time. I also wonder if any part of the game is waiting on network I/O to get values to complete actionscript commands and if this could be creating a huge bottleneck.

Oh and ca_keepmodels doesn't work. The game intializes it as 0 regardless (evident in omicron.log. I was hoping to run this to prevent models from being unloaded in case reloading models into ram was causing a performance issue. I have 4 gigs of video ram and soon to have 16 gigs of system ram so I figured this wouldn't hurt. The omicron file always reports it being initialized as 0.


edited to be more clear.

Edited by SLDF DeathlyEyes, 17 May 2014 - 06:04 PM.

[Wintersdark]

Praetor Shepard, on 16 May 2014 - 08:46 PM, said:

I was wondering if there are any more elements to how heat builds and dissipates when firing weapons (than what is generally known)?

For example, when we fire a Laser, does the heat generated start to dissipate at the end of the beam duration, or does heat start to dissipate at the start of the beam?

And if we hold down the trigger, do certain weapons build up more heat then known up to a certain limit (for example would a Medium Laser eventually build up to 5 heat from 4, separate from Heat Scale penalties)?

I hope my questions make sense, since I'm not entirely sure how to properly phrase them. My curiosity was recently piqued after thinking about heat again from here.

Well, I can answer this much: heat dissipates constantly, including when firing. Otherwise, if you constantly chain fired medium lasers your heat sinks would be useless.

And no, outside of Ghost Heat, weapons generate their listed heat. This is testable by comparing mathematical models to real world usage, which works out - see online heat simulator and various mechlab reports.

[shellashock]

SLDF DeathlyEyes, on 17 May 2014 - 01:39 AM, said:

Going back to what Krinkov said. I also have an fx processor, fx 8320. I have been having FPS issues and noticed they go completely away if i disable the hud using F11. So I did some experimentation with some settings relating to scaleform. I set this in my user.cfg

Spoiler

gp_option_ShowCockpitGlass=0
r_DepthOfField=0
r_HDRGrainAmount=0
sys_flash_address_space = 536870912
gfx_ampserver = 1
gfx_loadtimethread =1
sys_flash_allow_reset_mesh_cache = 1
ca_KeepModels = 1
r_TexturesStreamingOnlyVideo =1
gfx_loadtimethread = 1
gfx_inputevents_triggerrepeat = .016
r_MultiThreaded = 1
sys_MaxFPS = 60

I suspect the big change was gfx_inputevents_triggerrepeat = .016 I am not entirely sure what it does but I think it forces scaleform to reuse frames so that a scaleform frame is presented every .016 seconds so it always has something ready for the game. But I am not sure. I was wondering if you guys could reduce the rate that UI items update individually. Maybe you could make it so that heat and map and other data not entirely fluid sensitive like aiming reticles refresh less to reduce lag. I also wonder if any part of the game is waiting on network I/O to get values to complete actionscript commands and if this could be creating a huge bottleneck. Oh and ca_keepmodels doesnt work. The game intializes it as 0 regardless. I was hoping to run this to prevent models from being unloaded in case reloading models into ram was causing a performance issue. I have 4 gigs of video ram and soon to have 16 gigs of system ram so I figured this wouldn't hurt. The omicron file always reports it being initialized as 0.

So you are saying that changing this command (gfx_inputevents_triggerrepeat = .016) helped your fps? Or are you saying that this might be a potential bottleneck?

[DeathlyEyes]

shellashock, on 17 May 2014 - 03:12 PM, said:

So you are saying that changing this command (gfx_inputevents_triggerrepeat = .016) helped your fps? Or are you saying that this might be a potential bottleneck?

Helped my fps and possibly circumvented a bottleneck.

[shellashock]

SLDF DeathlyEyes, on 17 May 2014 - 04:20 PM, said:

Helped my fps and possibly circumvented a bottleneck.

Roger. I will test this out and see if it helped me as well.

[Galil Nain]

shellashock, on 10 May 2014 - 08:21 AM, said:

Seriously, I see a dual gauss heavy nearly every other game now. I haven't seen a dual ac20 mech for over a month now. TBH, most people I know (including me) don't like the gauss charge because it makes it difficult to use it as a secondary weapon while barely effecting gauss boats that use it as a primary weapon. The velocity increase that accompanied the charge was a MASSIVE buff to dual gauss builds because it makes it far easier to hit you with a 30 damage pinpoint alpha in any specific component. Maybe dual/triple gauss boats should get a "ghost" reload penalty for alphaing?

NOTE: This is coming from a massive gauss rifle fan that uses a dual/triple gauss heavy every other match.

Hang on a moment... you're piloting a dual/triple gauss heavy every other match and are surprised that you see a dual gauss heavy in every other match??? Of course you do... You're piloting the d***** thing!

[shellashock]

Galil Nain, on 18 May 2014 - 01:03 AM, said:

Hang on a moment... you're piloting a dual/triple gauss heavy every other match and are surprised that you see a dual gauss heavy in every other match??? Of course you do... You're piloting the d***** thing!

Sorry, I should have clarified that I see ANOTHER dual/triple gauss that is NOT ME almost every other match. Sorry about the confusion. To be fair though, I see dual gauss most often when facing another premade lance. I use dual gauss often when I play with my group, so it probably isn't surprising that other premade players would do the same.

[Karl Berg]

Deathlike, on 13 May 2014 - 03:10 PM, said:

Karl, if you could pass this question along to whoever's responsible for the crit system, it would be greatly appreciated.

Edit:
Also, can you or whoever is responsible for the cockpit screens look into WHY they don't work. The Mission Kills screen doesn't work (ever, to my knowledge). The Ammo Info screens rarely work. Most recently (since the mid-April/and pre-April PTS patch) had the Heatsink screen not function properly as it rarely works now.

I'd just to like to know if that's being looked into at all.

Will do.

Cockpit screens are controlled by the UI team, who have been pretty busy with UI 2, launch module, and now mechlab changes for the Clans. We were discussing those screens very recently in fact, since moving portions of the HUD to those screens would be very nice for certain VR headsets.. My hope is that they would get some time to revisit those screens soon, although honestly the whole team will likely move to 100% community warfare work the second they finish Clans.

[zudukai]

Karl Berg, on 18 May 2014 - 12:25 PM, said:

My hope is that they would get some time to revisit those screens soon, although honestly the whole team will likely move to 100% community warfare work the second they finish Clans.

I have mixed feelings about this,

i do really want CW, do not get me wrong, i do also want working main function displays and other art related modifications (catapults get my honorable mention here), i am bias only to the thought that these things are fairly simple and mostly easy to create/modify/implement, and i feel like the impact on CW will be minimized by the portion of time it would take to get the bigger pieces created by the other sections and developers within pgi.

i understand that working MFDs would impact a users FPS, but they are still currently enabled, only broken with (next to) useless data*, in this respect, i could foresee improvement in hud resource consumption rather then a negative hit.

although working MFDs are a large injection of immersion and they definitely do go hand in hand with VR displays particularly if they house or replace important information (maps? waypoints?), but i DO hope they do not overshadow other art aspects currently causing distress or issues.

*note* pilots can preform their duties admirably without any of the current data shown on the MFD, and thus would not be impacted by having them shut off.

[Karl Berg]

Buso Senshi Zelazny, on 13 May 2014 - 06:08 PM, said:

Thank you for the response! Of course, I will still be a bit skeptical until we see it in action on the live servers

Speaking of which, can we assume that the next launch attempt for these features will be the next patch on the 20th?

That is indeed the plan. We've added quite a lot of additional telemetry regarding match output, per weight class queue wait times; as well as several new safety features for this next patch. Obviously a lot of how successful this feature will be depends on how quickly player behaviour adapts to the new per weight class wait queues. So we've put in some first steps based on community feedback here and elsewhere to help make this easier to manage for you guys as well.

[Karl Berg]

Cimarb, on 13 May 2014 - 07:09 PM, said:

Please don't turn the 1-group rule back on. There have been TONS of 3-4 man groups in matches lately, and it has been great. I drop 60-90% solo, and I want multiple groups per team!

As long as the grouped numbers are balanced on both teams, PLEASE don't restrict the number of groups allowed.

It would be very interesting to see what the recent numbers of grouped/solo are recently (say the last month)...

It's the higher-ups that will ultimately make this call. If we do end up having to turn the one-group per team rule off, we've made some additional bug fixes to the group placement algorithm that should result in a more even distribution of groups per team.

[Karl Berg]

Modo44, on 13 May 2014 - 08:07 PM, said:

Well, they better get to it, then. It is understandable that destroying big stuff can incur a major cost due to the strict server authorization keeping us largely cheat-free. But when a simple tree or car survives mech firepower or being stepped on, that breaks immersion in a huge way. All the sense of scale and mass is suddenly not there.

Ahh, I thought you were talking about crumbling buildings and such. For visual collision work, such as trees and other small rigid bodies; there is a bunch of work I need to do first before the artists can add these sorts of assets to the maps.

It's not as simple as the artists simply dropping rigid body assets into the map, due to all the networking changes we've had to make to the engine. I've been proceeding with this work on the side, as time permits, but it's not at the point where I can hand this off to the artists quite yet.

[Karl Berg]

SnagaDance, on 13 May 2014 - 11:08 PM, said:

There are just not enough likes for me to give this post. Could you also make a short comment on this Karl? Because to me this seems like a very important issue.

Yup, we're very much aware that this design is hugely sensitive to player behaviour. We've done a basic implementation of queue status for next patch, based in part on player suggestions from here and elsewhere. We've also added a lot of new analytics and realtime matchmaker tuning capabilities to ensure this next patch is more successful than our last attempts.

[Karl Berg]

Shamous13, on 14 May 2014 - 09:09 AM, said:

is this because software compiled with the Intel compiler or the Intel function libraries has inferior performance on AMD and VIA processors. The reason is that the compiler or library can make multiple versions of a piece of code, each optimized for a certain processor and instruction set, for example SSE2, SSE3, etc. The system includes a function that detects which type of CPU it is running on and chooses the optimal code path for that CPU. This is called a CPU dispatcher. However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string. If the vendor string says "GenuineIntel" then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version. I dont know if intel has changed their compiler after loosing their lawsuit.

We're using the Microsoft 2010 visual studio compiler for the game client. Considering that AMD has been a huge driver in terms of bringing advanced vector instructions to the x86 and amd64 instruction sets, I would hope that they have excellent SSE2 and SSE3 support. In fact, if I'm not mistaken, AMD has used a fused multiply-add architecture for quite some time, while Intel seems to be playing catch-up here to some extent.

I've had very little time for profiling unfortunately, but everything we've seen in terms of CPU profiles so far show that the game is heavily dominated by calls into the D3D API.

[Karl Berg]

Featherwood, on 14 May 2014 - 10:14 AM, said:

Dear Karl,
I hope it's good time to ask questions, if so - here are few from me:
<snip..>

Yup, I can forward those on.

Modo44, on 14 May 2014 - 10:09 PM, said:

Does firing multiple missile launchers together change the spread of individual launchers in any way? For example, is 4xLRM5 fired together going to hit the same locations as those same launchers fired on chain fire? Will firing 4xSSRM2 together spread the missiles differently than chain-firing them? (Assuming stationary mechs for simplicity.)

I think not, but I'm not 100% certain on this. I will ask when I get a chance.

[Featherwood]

Karl Berg, on 18 May 2014 - 01:59 PM, said:

Yup, I can forward those on.



I think not, but I'm not 100% certain on this. I will ask when I get a chance.

Thank you, sir!

[DEN_Ninja]

Karl, more questions are surfacing with the HUD bug coming back.

The paper doll with the missile pods has been shown. Is there any functionality on this that you can tell us about?