1911 replies to this topic

[Gizmoh]

Honestly, I'm not so sure about stuff like damaged actuators, and heat scale for that matter, (speaking about the TT heat penalty, not "ghost heat"). They sound like penalties ¿? for brawlers and other short range/high heat builds compared to poptarts, just saying.

[Omid Kiarostami]

Li Song, on 14 June 2014 - 01:08 AM, said:

@Karl Berg
According to analysis performed here: http://mwomercs.com/...-a-brief-guide/
Internals (actuators, gyros, life support etc) do not take part in the resolution of critical rolls. I.e. a roll that hit an internal is a re-roll. This was reinforced by the fact that internals had 0 HP.

In the Clam PTS data files, internals now have a HP value. Does this mean that internals do take part in the crit roll resolution and can infact be destroyed? In other words, do internals act as a built-in crit buffer? (I'm not asking if destroying an actuator has any actual effect on your mech, which would be cool but doesn't really affect my mechlab).

Also in response to PTS clam:

• Missing description for Clan Standard Structure in TheRealLoc.xml.
  
• Accepting lobby invite while in lobby fails silently.

Hey Li Song,

I can confirm that internals (actuators, gyros, sensors, etc) are supposed to be accounted for in the critical hit distributions. They are great crit-buffers!

Prior to clans, the default health value of internals was a constant in the code base. When we moved internals to the xml game data, we didn't need that anymore and started specifying hit points on them like every other item. This doesn't represent a change in functionality, though - everything should still be the same as it was before.

In lieu of a formal post going over crits, here's an image of a CN9-YLW with the debug crit table showing: http://imgur.com/G6EmMky

The percentage next to each item in the image above is the likelihood the game uses when determining what item is hit by a crit. Internals factor into the crit distribution (at least until they are destroyed), so having internals in a component definitely improves the survivability of items you slot there.

Hope that clarifies!

[Karl Berg]

Imperius, on 17 June 2014 - 07:13 PM, said:

Ok after taking in feedback and searching though Newegg and doing more research this is the new build. Ignore the SSD that is a maybe later thing
http://secure.newegg.com/WishList/PublicWishDetail.aspx?WishListNumber=22489151

Going down to LGA 1150, you now have dual channel memory. This means what I said earlier about having to install RAM in sets of 4 no longer applies. Otherwise, this is a pretty solid system for the budget. That specific Asus board is fairly pricey for an 1150 socket*; but as a whole it should be plenty fast.

* Comparing prices to here:
http://www.ncix.com/...ff-107-1632.htm

Heffay, on 17 June 2014 - 07:32 AM, said:

I'm pretty sure it's a rendered scene in Cryengine. All the assets in the mechlab are actually in the game files, and since the mech loadout changes as you change the mech, it probably is dynamic as well.

Some light animation in the background would be nice. Spinning fans, warning lights (maybe timed with the loadout warning/error indicator to let you know there is a problem), stuff like that. People especially for scale, as you said!

I believe it's a heavily modified version of the asset we used for the dropship trailer. Dennis is the best guy to ask about this.

[Karl Berg]

Li Song, on 17 June 2014 - 11:37 AM, said:

@Karl Berg Another question, since the introduction of pilot modules and possibly quirks in the future that affect the heat output of weapons. Will the base heat used for ghost heat calculation be affected by modules and quirks, or will that always be the unmodified base heat of the weapon?

Hrm.. That's an excellent question. Currently no pilot module or quirk affects base weapon heat generation that I know of; although there are some quirks for cooldown rates and such.

When design asks us to implement something that affects the base heat generation of weapons, then I'll be able to answer you.

[evilC]

I am not sure it needs changing apart from allowing users to set the ID order of a weapon.

The only real "bug" is that the build UI does not observe the same rules as the save routine. The build UI observes the order users dragged weapons onto mech, while the save UI uses weapon ID.

I think the "attach point" rules for a given location are maybe pretty simple to define, if put into sensible terms.

From what I can tell, there are some rules that always apply:

• Each Attach Point (AP) in a given location for a given weapon class is designated a number by the devs.
  
• Weapons attach in order of AP low to high.
  
• Some APs are "preferred" for a weapon subclass
  
• If a preferred weapon type is added, it grabs the next available Preferred AP that is not occupied by a preferred weapon. ie it will skip the lowest numbered AP to grab the next preferred AP.
  
• Preferred weapon rules have an order, a lowered number rule will override a higher number rule.

For example, with the BNC-3E RT Energy slots, the preferred AP rules are:

1) Slots 1+2: PPC preferred. (Remember: rules are executed in order - this rule #1 overrides Laser rule #2)
2) Slots 1,3,4: Laser preferred.

This is the AP order.



So when trying to convey the rules that govern this location to the user, you could convey all this info with a simple string such as:

[1,2: P / 1,3,4: L]

This could be inserted into the header of the equipped section for a given location, where the icon indicating number of hardpoints for each weapon type resides.

This sounds to me like solely a UI job, as there is no logic, just display of new info. Could be parsed, could just be a manually inserted string. Hell, in the short term you could even append some XML to convey this information to each mech, but not actually wire it up to do anything - it's sole purpose would be to be parsed by mechlab authors such as Smurfy or Li Song.
This would give you time to get the UI alterations through QA etc, but get the information out there ASAP.

That would remove ambiguity over the "attach point" side of the equation, which would leave just the "ID" situation to solve.

Here, there is one obvious solution: Make the Save routine follow the same rules as the Build UI.

That is, given that you want to keep the current global rule of "lowest number slots first".
In some cases i agree with this, in others not. For example, mounting missiles on a GRF-1N mounts them to the shoulder pod (which can "not exist") before it mounts missiles internally (ie the shoulder pod is "Slot 1" for missiles). Now this is a double-edged sword - increased ability to poke over cover vs increasing profile.

I can see reasons for having ordering rules (balance) and attach point rules (modeling and balance) - Would it be healthy to allow players to make this choice? I don't know. One one hand it promotes build design skill as a part of the game, but on the other, could make the meta more meta.

TL/DR:
The ID issue is clearly a bug and a royal pain in it's own right so that is the priority.
The Attach Point / Weapon Preference issue is a lack of providing sufficient information to the user, but layered on top of the ID issue makes things even more confusing. With the ID issue removed though, it would not be such a big deal.

Fix those two ASAP, then think about enhancing the system.

Edited by evilC, 18 June 2014 - 06:12 PM.

[Goose]

Karl Berg, on 18 June 2014 - 03:25 PM, said:

It's been some time since I did any detailed profiling. That has mostly fallen on some other engineers for this project, but the last time I did detailed profiling, the game was heavily render thread bound. The physics thread is hot on the dedicated server, due to all the rewind logic it performs, but on client machines it's not a dominating cost.

=)

This leads to questions about ca_thread1Affinity, and how it could be talked into doing moar, to unload ca_thread0Affinity, and/ or get r_WaterUpdateThread out of 0Affinity's way.

Then, there's how setting ca_thread and e_ParticlesThread to zero seems to help dual-cores (r_MultiThreaded might belong on this list).

Oh:

sys_job_system_max_worker
e_AutoPrecacheCgfMaxTasks
r_ShadersAsyncMaxThreads
p_num_threads; requires sys_limit_phys_thread_count = 0

all seem to also talk about threads, but now that the AMD FX-thing has come out, I guess we need to know if these threads would be integer or floating point.

And also if sys_job_system is the same as sys_TaskThreadX_CPU.

And if we should short these four strings one point, to account for the core 0Affinity keeps busy …

… And if p_num_theads has anything to do with the SPU-whatzit found on PS3s - er, is it a useful variable for PCs? (s_NumLoadingThreadsToUse might be in the same boat, what with it's funny max of 5.)

I'd like to point out I suspect sys_budget_soundCPU = 15 is too high, reserving 15% of a core, all the cores, to run them RealTek chips: I see a framerate boost by dropping this number down to 10, or zero, but I oddly only see 0Affinity get up to 90% with any change …

I'll stop pestering, now; Thanks again.

Edited by Goose, 18 June 2014 - 09:53 PM.

[Rebas Kradd]

Karl, I know this isn't your field, but do you happen to know off the top of your pretty head whether there are plans for bigger maps than what we currently have? And how much bigger?

Edited by Rebas Kradd, 18 June 2014 - 10:24 PM.

[Li Song]

Karl Berg, on 18 June 2014 - 03:06 PM, said:

Hey Li Song,

So I've asked Gameplay about this, and it turns out that internals did soak crits prior to the Clan release yesterday. All internal components were given a hardcoded 10 health. I'm bugging gameplay / design about putting up a more formal post with additional details about how the crit system works, but I'm told it is very 'Tabletop'.

That would be lovely. And thanks for your help. While on the subject, I'm under the impression that C.A.S.E. is not crittable and neither is dynamic/fixed structure/armor slots?

[Imperius]

Karl Berg, on 18 June 2014 - 05:48 PM, said:

Going down to LGA 1150, you now have dual channel memory. This means what I said earlier about having to install RAM in sets of 4 no longer applies. Otherwise, this is a pretty solid system for the budget. That specific Asus board is fairly pricey for an 1150 socket*; but as a whole it should be plenty fast.

* Comparing prices to here:
http://www.ncix.com/...ff-107-1632.htm



I believe it's a heavily modified version of the asset we used for the dropship trailer. Dennis is the best guy to ask about this.

Yeah it's a bit on the high side, but I can OC ram and CPU and the CPU I'm getting comes out 6/25/14 code name Devil's Canyon stock 4.0GHz Turbo Boost 4.4GHz and overclockers claim 5GHz on air cooling (but I won't OC unless I go water cooling in the future)

Thanks for all your help and time I will post benchmarks here of it's performance of MWO and general benchmarks after I build the PC.

[Cimarb]

Gizmoh, on 18 June 2014 - 04:44 PM, said:

Honestly, I'm not so sure about stuff like damaged actuators, and heat scale for that matter, (speaking about the TT heat penalty, not "ghost heat"). They sound like penalties ¿? for brawlers and other short range/high heat builds compared to poptarts, just saying.

It is all about making heat matter, instead of the "alpha until you meltdown" mentality we currently have. The heat system should be gradual, with small things happening first and a shutdown being the most severe thing possible. Currently, shutting down while pop tarting is actually a valid and encouraged tactic, and that should never be preferable. Instead, the hotter you get, the more wear and tear you put on your mech. If you want to keep pushing the envelope, that is on you, but there should be penalties for it.

TL;DR you should build a mech to be heat neutral as much as possible, not cram as many weapons as you can into the mech so you can get the biggest alpha as you overheat around the corner.

Omid Kiarostami, on 18 June 2014 - 05:46 PM, said:

In lieu of a formal post going over crits, here's an image of a CN9-YLW with the debug crit table showing: http://imgur.com/G6EmMky

The percentage next to each item in the image above is the likelihood the game uses when determining what item is hit by a crit. Internals factor into the crit distribution (at least until they are destroyed), so having internals in a component definitely improves the survivability of items you slot there.

Hope that clarifies!

That is awesome info, Omid! I just really, really wish actuator/gyro/engine crits DID something. Any chance that will happen soon?

[Omid Kiarostami]

Li Song, on 19 June 2014 - 03:00 AM, said:

That would be lovely. And thanks for your help. While on the subject, I'm under the impression that C.A.S.E. is not crittable and neither is dynamic/fixed structure/armor slots?

That's correct. CASE and structure/armor slots aren't critable.

[Modo44]

Goose, on 18 June 2014 - 09:51 PM, said:

I'll stop pestering, now; Thanks again.

Actually, keep pestering. I think we need a full list of active user.cfg values, otherwise it is a crapshoot -- experimenting in the dark on a half documented feature. The same issues are there with other randomly enabled/disabled values, e.g. the ones regarding AA ghosting (magically reappearing motion blur).

Edited by Modo44, 19 June 2014 - 09:50 AM.

[Deathlike]

Omid Kiarostami, on 18 June 2014 - 05:46 PM, said:

Hey Li Song,

I can confirm that internals (actuators, gyros, sensors, etc) are supposed to be accounted for in the critical hit distributions. They are great crit-buffers!

Prior to clans, the default health value of internals was a constant in the code base. When we moved internals to the xml game data, we didn't need that anymore and started specifying hit points on them like every other item. This doesn't represent a change in functionality, though - everything should still be the same as it was before.

In lieu of a formal post going over crits, here's an image of a CN9-YLW with the debug crit table showing: http://imgur.com/G6EmMky

The percentage next to each item in the image above is the likelihood the game uses when determining what item is hit by a crit. Internals factor into the crit distribution (at least until they are destroyed), so having internals in a component definitely improves the survivability of items you slot there.

Hope that clarifies!

Hi Omid, that's very helpful.

How do XL engines and SHS/DHS added to the engine (275+ engines) work into that formula?

Edited by Deathlike, 19 June 2014 - 10:48 AM.

[Cimarb]

Deathlike, on 19 June 2014 - 10:46 AM, said:

Hi Omid, that's very helpful.

How do XL engines and SHS/DHS added to the engine (275+ engines) work into that formula?

Every critical slot equates to an equal percentage of the section. So divide the number of used critical slots for that section into 100 and you have the percent chance that any single critical slot gets hit.

So, for the Center Torso, which has 12 total slots when fully loaded, each individual critical slot is 8.33% (100/12=8.3333), or 8% due to rounding. So the engine, with six crit slots, has a 50% chance of getting critted. If the two "optional" slots aren't filled with anything, the engine would have a 60% chance, instead (100/10=10; x6=60). An IS XL engine has a 25% chance if the torso is fully loaded (100/12=8.33; x3=24.99), or if it is empty otherwise, the chance jumps up to 100% (100/3=33.33; x3=100). A Clan XL engine only has two crit slots per side, but the same "per crit" chance (so 8.333% per slot if fully loaded, or 33% per slot if the torso is empty).

[Deathlike]

Cimarb, on 19 June 2014 - 11:45 AM, said:

Every critical slot equates to an equal percentage of the section. So divide the number of used critical slots for that section into 100 and you have the percent chance that any single critical slot gets hit.

So, for the Center Torso, which has 12 total slots when fully loaded, each individual critical slot is 8.33% (100/12=8.3333), or 8% due to rounding. So the engine, with six crit slots, has a 50% chance of getting critted. If the two "optional" slots aren't filled with anything, the engine would have a 60% chance, instead (100/10=10; x6=60). An IS XL engine has a 25% chance if the torso is fully loaded (100/12=8.33; x3=24.99), or if it is empty otherwise, the chance jumps up to 100% (100/3=33.33; x3=100). A Clan XL engine only has two crit slots per side, but the same "per crit" chance (so 8.333% per slot if fully loaded, or 33% per slot if the torso is empty).

Although I already knew this, I was talking whether or not health is shared between the sections (which I believe this is the case) and specifically how SHS/DHS goes into that equation... as in "is it a buffer" and whether it is added to the crit table or just "increases" the overall health of the engine. I know it does increase the overall health through the testing (before they added internal damage to crits translating into internal armor) but it's unclear how that it is determined or calculated.

For example, it is theoretically possible to lose all of the additional 6 SHS/DHS on a 400 engine (although that's usually not the case) but often times I've lost 1 or 2 DHS in the CT of a mech with a 300 STD/XL engine, so it's one of those things that needs some actual clarification.

Edited by Deathlike, 19 June 2014 - 02:09 PM.

[DarkonFullPower]

I've got a tricky one.

Is it possible, coding wise, to have a "r" button lock onto a mech, but disallow missile lock?

I have an idea I want to pitch, but first I need to know if it's physically possible.

EDIT: I will word Deathlike's question a little better for him:

How do extra heat sinks equipped in the 275+ engines effect the crit roll?

Edited by DarkonFullPower, 19 June 2014 - 02:58 PM.

[Cimarb]

Deathlike, on 19 June 2014 - 02:08 PM, said:

Although I already knew this, I was talking whether or not health is shared between the sections (which I believe this is the case) and specifically how SHS/DHS goes into that equation... as in "is it a buffer" and whether it is added to the crit table or just "increases" the overall health of the engine. I know it does increase the overall health through the testing (before they added internal damage to crits translating into internal armor) but it's unclear how that it is determined or calculated.

For example, it is theoretically possible to lose all of the additional 6 SHS/DHS on a 400 engine (although that's usually not the case) but often times I've lost 1 or 2 DHS in the CT of a mech with a 300 STD/XL engine, so it's one of those things that needs some actual clarification.

Yeah, sorry, I totally read your question wrong. It's a good one now that I know what you meant!

[Goose]

Deathlike, on 19 June 2014 - 02:08 PM, said:

Although I already knew this, I was talking whether or not health is shared between the sections (which I believe this is the case) and specifically how SHS/DHS goes into that equation... as in "is it a buffer" and whether it is added to the crit table or just "increases" the overall health of the engine. I know it does increase the overall health through the testing (before they added internal damage to crits translating into internal armor) but it's unclear how that it is determined or calculated.

For example, it is theoretically possible to lose all of the additional 6 SHS/DHS on a 400 engine (although that's usually not the case) but often times I've lost 1 or 2 DHS in the CT of a mech with a 300 STD/XL engine, so it's one of those things that needs some actual clarification.

None of that should be happening: HSs hidden in an engine don't change the engines' crits in any way, nor could the HS be crit; Thus HSs shouldn't be changing the HPs of an engine …

[Deathlike]

Goose, on 19 June 2014 - 05:27 PM, said:

None of that should be happening: HSs hidden in an engine don't change the engines' crits in any way, nor could the HS be crit; Thus HSs shouldn't be changing the HPs of an engine …

Well, it is somehow factored in the crit tables, because SHS/DHS destruction in a 275+ engine DOES happen (Betty doesn't lie about that, despite telling me my right arm is destroyed when it is actually the left arm).

The best display of this effect is the classic Centurion build with a 275 STD engine. I use the DHS as a "crit buffer" for the 2 CT med lasers (increased protection for the engine to reduce the probability of a laser being removed).

Edited by Deathlike, 19 June 2014 - 06:04 PM.

[Wintersdark]

Deathlike is correct, heat sinks added to the engine absolutely are being critted and destroyed. I've noticed it happening many times - particularly when _all_ my heat sinks are internal. And noted the measurable lack of cooling after.