Is the current background just a flash presentation with added steam/ mist?
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!
Yeah, the mechlab definitely looks to be a fully rendered "level" or room. As nice as some extras would be, I would guess it would require more dev time that could better be spent elsewhere at this point. High cost for little benefit.
colors 1+2 are hotrod black.
color 3 is hotrod dark red.
These are Sanguine Tigers colors.
Cimarb, on 16 June 2014 - 04:57 PM, said:
Karl said (many pages back) that he IS looking into the issue. That doesn't mean they necessarily have "plans" to do so, but he is aware of it.
Sorry I got the order mixed up. I really need to work on those reading skeels.
Just to clarify, it was in one of the Ask the Devs threads that a PGI employee stated that there were no plans to address the "Weapon Age" issue.
So Karl has acknowledged that it is, indeed, totally whack and we will be getting some kind of solution (Or at least an on-screen indication as to what age a weapon is)?
Just to clarify, it was in one of the Ask the Devs threads that a PGI employee stated that there were no plans to address the "Weapon Age" issue.
So Karl has acknowledged that it is, indeed, totally whack and we will be getting some kind of solution (Or at least an on-screen indication as to what age a weapon is)?
I found the quote:
Karl Berg, on 06 May 2014 - 08:45 AM, said:
This is a bug. Essentially, at this time, the order in which you equip weapons determines the visual outcome, but that order is not persisted right now. This means, in-game, the order the game falls back on is the sort order the game retrieved equipped inventory in, which is sorted by primary key. That primary key for player inventory is a specially constructed hash with a few special properties. One of those properties is that it monotonically increases for given single player. This effectively makes the equip ordering fall back to inventory purchase order once you leave the mechlab.
The gameplay team has the bug, and is investigating options for resolving this. We've provided them some space for saving extra metadata about equipped inventory.
I reckon the bloke who commented on it before simply didn't understand what we were talking about and so just brushed us off with a "no". I don't see how anyone could have not regarded this as a serious issue.
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?
Those are some beastly specs! I would imagine this machine would play nearly any game just fine; although you would want to buy two sets of those 2 x 4GB sticks. The CPU is quad-channel DDR-3, so having all four channels filled will allow the system to interleave memory writes and achieve much higher throughput rates.
The hex core might be a bit overkill. I'm not sure if users have run any benchmarks between slightly lower clocked hex cores vs a quad core at slightly higher frequencies; so the 4820 might be worth careful consideration as well if you're going to go with a 22nm ivy bridge.
Bad Karma 308, on 14 June 2014 - 04:51 PM, said:
They aren't going to take any instruction sets out of the new processor, if anything then new CPU will run the game's code far more efficiently while at the same time utilizing less resources.
Since you aren't overclocking then your money will get you much further with much better performance by switching to a socket 1150 and a 4770. The K at the end of an INTEL CPU, like 4770K, means that has an unlocked multiplier which is needed for overclocking. So go with a regular one and save yourself some cash.
The RAM speed will make quite a bit of difference to the applications and OS. Even Karl earlier in this post mentioned that MWo favors higher RAM speeds. But he difference between an increment or two, like going from 1333 to 1600, isn't really noticeable to the naked eye. But if you jumped from say 1600 to 2133 or 3300 then yes you can really see the difference between them. Some of the new Z97 1150 board support much greater RAM speeds. (like this one ---> http://www.newegg.co...N82E16813132127 ) DDR3 3300(OC)3200(OC)/3100(OC)/3000(OC)/2933(OC)/2800(OC)/2666(OC)/2600(OC)/2500(OC)/2400(OC)/2200(OC)/2133(OC)/2000(OC)/1866(OC)/1800(OC)/1600/1333
But more seriously though, if MWO introduced "head bobbing" via the reticule, I would ask for an immediate refund, as I would not be able to play this game anymore.
I could understand that, but...
Here's my counter argument.
Have you seen the cockpit itself bob? Watch it on the Jagermech here in first person.
Considering how little that crosshair moves, then compare the cockpit bounce which...looks like its going through an earthquake.
o.O;
Or all the crosshair movement when aiming? Just moving the crosshair by itself with armlock turned off is far more movement than a bouncing crosshair from walking.
Or this bug that has been happening since 2012, has plagued the game since the beginning of time, and occurs to more than 50% of the players even if they are not aware of it. It occurs to every player (or nearly so) that uses "Post AA" as a graphics anti-aliasing.
Late 2012/early 2013.
2 weeks ago.
Many players are playing with this and will never know it until they do a screenshot.
That's a lot more motion sickness inducing than a tiny crosshair movement. And I'm saying this as someone who gets carsick if I ride in one for more than 10 minutes.
You keep ignoring the fact that you already accomodate for reticule shake when running and firing at the same time. Maybe you just do not notice it because you are that 1337, but it is a real skill you have to develop. The mechanic you ask for is already in the game.
You keep ignoring the fact that you already accomodate for reticule shake when running and firing at the same time. Maybe you just do not notice it because you are that 1337, but it is a real skill you have to develop. The mechanic you ask for is already in the game.
Only in third person. You are ignoring that fact.
Try playing in third person.
Then play in first person.
Huge difference.
Also, keep in mind that in TT, the faster you move the more inaccurate you are. It's lore.
But in MWO you're as accurate stationary as you are moving.
Even when your mech does this.
Everything bounces with every step.
But your mech? Perfect aim.
Even at impossible angles, such as this one.
Or this one.
These are possible because of the way the first person crosshair is setup.
But in third?
Now there's a difference.
What I'm asking for is something significantly more skill based and less random chance.
From the videos, since it's CLEAR you haven't watched them, the reticule bob is very subtle and the bob is actually perfectly even whether close or long range. Which is good because if it goes into first person that'd be one aim, one reticule size, perfect pinpoint to where it goes.
And at full run, I had 3 consecutive headshots on a Spider.
It's all in timing; timing that can't be done with macros. Timing that can only be done with skill. And besides, even now with lights and lasers, you need to stop and fire to have maximum effect. It's just that it'll tie into ballistics as well for that perfect aim, unless you're good with perfect timing.
And in the video with the Thunderbolt, even with the bounce, you could keep the lasers perfectly on one side torso. It's possible even with the side to side movements of some mechs like the Stalkers.
What does it all entail? A 100% skill system.
PGI's original solution to the problems this solves?
Delayed convergence, where shots randomly miss from rushing convergence when aiming suddenly at something long range then short range as shown here in this animated 3 second gif.
Spoiler
I find my solution to be much better, and it's already in the game but only in third person. I'd like it in first.
Because right now we have this.
Spoiler
And it's because of this in jump sniping that it became a problem. But here on the ground, it's still a problem.
So long as ballistics exist, it will always be a problem. Even with everything going burst fire.
And in comparison, this solution is even better than delayed convergence. No lag, no latency, the entire thing is client side in a protected file; no one would remove animations as it removes your ability to hit things where you see them. And since your aim would depend on your animations, it's 100% solid. Not to mention perfect pinpoint is never lost. Your shots will always hit exactly where the crosshair is. So it's much better than cone of accuracy too.
Btw, did you know that the M1A1 Abrams on level ground moving at 20 kph has a 0.6% margin of error in its aim? And it increases with speed, and much more with uneven terrain? Even with that perfect computer it can never achieve perfect pinpoint.
That Gyro? It's on an ANCIENT decades to centuries old battlemech. Top this off with we're not supposed to have any convergence at all. None. Of course you could independently aim the arms, climb hills with your hands, and blast through buildings as well as slip on asphalt. But we don't have those either.
Want to know what else? Only 2% of the battlemechs in this era could reach 150 kph as a stock speed. Many can't reach that even with MASC.
I personally respect your opinion and counter-argument Koniving, but in my own personal case of motion sickness, what makes me sick is what I focus on.
In FPS games, I fixate on the reticle and what's behind it. My vision will change focus based on distance of the scene I'm viewing. I'm fully aware of how the cockpit frame bounces when you walk and run, and oddly enough, it doesn't bother me, nor do I really notice it, because that's not what I focus on; it's the reticle.
The only cockpit that really bothers me is the Locust 1V due to all the extra wire framing in the cockpit. I can only play that specific mech for a couple of matches because there is such a small amount of screen space to see through that the cockpit shake in that mech is noticeable.
But to get back to my point of what I focus on, should they implement the reticle to bounce back and forth while walking and running, I would have to stop playing this game. Or I can always turn off the HUD and fire blindly, but that's not a very viable solution to the issue.
As "realistic" as it would be for weapons to miss a little based on how the reticle moves when walking, and for the record, I do agree something needs to be done with the instant convergence, I simply would not be able to play with a constant rocking back and forth of the reticle.
PS. My video card has never done some of the whacky graphics in your posted pictures, so I have no objective opinion on that. But I do agree that if the game did that to me, then yeah I would definitely need to stop playing while they got that fixed.
@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).
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'.
So who is Teh One Problem Thread? I think it's ca_thread0Affinity, but there was a time when I thought it was sys_physics_CPU; Currently, Krinkov is positive it's physics.
Thanks for you replies, Sir …
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.
Any chance you can get somebody to explain to the community how to find out the specs governing hard points on mech locations?
There is clearly a secondary mechanism to hardpoints (There can be more places in a location where weapons will fit than there are hardpoints), but nobody seems to know the rules or how to get at the information.
For example, as you can see on the BNC3-E, there are 3 energy hardpoints, but 4 places that energy weapons can be mounted. Some of them appear to be PPC specific.
Li Song has indicated that she has no idea how to access this information, I dunno about Smurfynet.
It's.. complicated. I had gameplay try to confuse me with this at one point, and I must admit it was a bit overwhelming. They could definitely use a lot of cleanup in this area. There are definitely more concise ways of handling this.
So currently, there is some form of search through the hardpoints.xml, whereby they start searching through the Attachments of one WeaponSlot node until it encounters the "Default" tag, which is apparently some kind of que to start iterating a different WeaponSlot node, with some back and forth messiness that didn't make a great deal of sense to me. In the end they find a free Attachment that matches the weapon type of what you're trying to equip, and it places the weapon on the associated attachment point (AName).
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'.
Karl ... thanks for the info ... this could be a big deal. Any pressure you can apply to get this information out in a Command Chair post would be greatly appreciated. I really like the new Clan Omnipod quirks system, and think it could be very interesting if a similar system was in place to impose penalties as actuators, etc. are destroyed.
Kageru Ikazuchi, on 18 June 2014 - 03:35 PM, said:
Karl ... thanks for the info ... this could be a big deal. Any pressure you can apply to get this information out in a Command Chair post would be greatly appreciated. I really like the new Clan Omnipod quirks system, and think it could be very interesting if a similar system was in place to impose penalties as actuators, etc. are destroyed.
There are several things that could really, really improve the quality of the game, aside from CW.
1. Actuator and engine crits actually doing something - reduced mobility would be the easiest
2. Heat system revamp - lower cap, higher dissipation, and TT penalties working up to shutdown (instead of nothing until shutdown)
3. Manufacturer variants (this is related to CW, true, but not dependent on it)
All of these thinks revolve around the new quirk system the Omnipods have, so I have high hopes that these will be looked at soon!
72
9erRed, on 17 June 2014 - 07:15 AM, said:
