192 replies to this topic

[focuspark]

NRP, on 06 November 2013 - 12:07 PM, said:

Pariah Devalis, on 09 November 2013 - 11:47 AM, said:

Odog4ever, on 09 November 2013 - 03:39 PM, said:

Fix to the crash issue was approved and made available by Microsoft today. The patch can be downloaded immediately. You may not get prompted to update for a few days, but if you search the store for Skunkworks you'll see the app has an option to update.

Other fixes: Command 2D engine size bug.

New feature: added alpha heat computation to the stats screen

NRP, on 12 November 2013 - 01:25 PM, said:

I found another anomaly - each of the Victor model templates shows an energy slot in the head. There is no energy slot in the Victor's head.

Now that the queue is empty, I'll push an update with a fix for the Victor chassis ASAP. As usual, I'll update this thread when that is available for download.

[Vimeous]

Update works a treat.
Gone from free to purchased.
Pleased as punch.
Top stuff!

[PictishWolf]

In an earlier post, it sounded like you set all DHS at 1.4x standard HS. I've been out of the loop so maybe they've changed it and I didn't hear about it, but last I heard, engine double heat sinks are worth 2 standard heat sinks. Please correct me if I'm wrong about that.

[focuspark]

PictishWolf, on 14 November 2013 - 09:04 AM, said:

In an earlier post, it sounded like you set all DHS at 1.4x standard HS. I've been out of the loop so maybe they've changed it and I didn't hear about it, but last I heard, engine double heat sinks are worth 2 standard heat sinks. Please correct me if I'm wrong about that.

Kind of. It's confusing.

In normal "single heat sink mode" the engine is worth 10 heat sinks (aka 10 EHS) and each additional heat sink added is worth 1 more (1 EHS).

In "double heat sink mode" the engine is worth 20 EHS and each additional heat sink is worth 1.4.

The engine value can change based the number of integral heat sinks it has. Most engines (rating of 250 or higher) dissipate the 10 or 20 value. However, this is different for engines with a rating below 250. An engine's rating divided by 25 is the number of integral heat sinks it has. These are the ones people discuss as being "true double heat sinks". So an engine with a rating of 200 has eight (200 / 25 = 8) integral heat sinks. If you are in "standard heat sink mode" these are worth 8 EHS, if you are in "double heat sink mode" they're worth 16 EHS.

Personally, I think this mechanic is completely broken but then again so much about MWO balance efforts looks like critical fumbles to me that I've given up on hoping they get fixed and just shoot stuff in my giant stompy robot tank.

[NRP]

To add a user's perspective, the whole "XX DPS @ YYY Equivalent Heat Sinks" doesn't really mean a lot to me. I guess it is meant to give an indication of a build's heat performance, but it's not intuitive and does not facilitate an "at a glance" comparison of the heat performance/impact of different builds, which is ultimately what I need. I would rather see a simpler heat performance metric, for example a build's overall heat dissipation rate relative to its overall heat generation rate, expressed as a percentage. This would facilitate better "at a glance" comparisons of the heat performance between different builds.

Edited by NRP, 14 November 2013 - 10:05 AM.

[focuspark]

NRP, on 14 November 2013 - 10:04 AM, said:

To add a user's perspective, the whole "XX DPS @ YYY Equivalent Heat Sinks" doesn't really mean a lot to me. I guess it is meant to give an indication of a build's heat performance, but it's not intuitive and does not facilitate an "at a glance" comparison of the heat performance/impact of different builds, which is ultimately what I need. I would rather see a simpler heat performance metric, for example a build's overall heat dissipation rate relative to its overall heat generation rate, expressed as a percentage. This would facilitate better "at a glance" comparisons of the heat performance between different builds.

Interesting. I'll see what I can do to better represent the impact heat has on your designs.

For now, there's the DPS @ EHS line as well as an EHS line. So you can compare how peak DPS and the EHS required to maintain it vs the amount of EHS available.

Vimeous, on 14 November 2013 - 08:38 AM, said:

Update works a treat.
Gone from free to purchased.
Pleased as punch.
Top stuff!

Thanks!

[Odog4ever]

After the latest update I can finally use the app without it crashing! Gonna lose a lot of productivity at work now

[focuspark]

Just posted a new update (should appear in a few days).

• Fixed hard point issues with Victors
  
• Fixed hard point issues with Quickdraws
  
• Reduced the size of the app package from (38MB WP7 / 16MB WP8) to 1.5MB

[focuspark]

Similar update was just pushed for the Windows Modern (aka Windows 8) version.

[NRP]

I think I found another issue. Build a new Highlander 733C with the following loadout:

STD300
AC/20 (3T ammo)
2 LLs
2 SRM6s (2T ammo)
3 JJs
15 DHS, Endo, max armor

Skunkworks says this is a valid build, but Smurfy's says it is not. I think the problem is in the weight of the jump jets. Skunkworks correctly lists the weight of each JJ as 2 tons in the Utility menu, but it appears to use a weight of only 1 ton in the calculations.

[focuspark]

NRP, on 18 November 2013 - 03:45 PM, said:

I think I found another issue. Build a new Highlander 733C with the following loadout:

STD300
AC/20 (3T ammo)
2 LLs
2 SRM6s (2T ammo)
3 JJs
15 DHS, Endo, max armor

Skunkworks says this is a valid build, but Smurfy's says it is not. I think the problem is in the weight of the jump jets. Skunkworks correctly lists the weight of each JJ as 2 tons in the Utility menu, but it appears to use a weight of only 1 ton in the calculations.

Yup. Looks like the bug. I'll see how quickly I can get this patched.

Thanks for reporting it.

Edited by focuspark, 18 November 2013 - 03:54 PM.

[NRP]

Have you finished implementing alpha heat? I ask because I noticed a peculiarity.

Equip 2 PPCs: alpha heat = 20
Equip 3 PPCs: alpha heat = 42.6 (I guess this number is correct. It should be higher than 30)

Equip 2 PPCs + ERPPC: doesn't seem like there is an alpha heat number for this combo, so the app just implies 20+15. However, I believe PGI applies a ghost heat penalty based on the ERPPC base heat, which would result in an alpha heat number greater than 42.6, certainly higher than 35 anyway.

It would be nice if the ghost heat effects could be reflected in that overall heat performance number I talked about earlier. You could have one % number just based on heat dissipated/heat generated without ghost heat effects, and another % number that includes the ghost heat penalty (if there is one). This would tell us how badly a build would suffer from alpha striking. Not a big deal though, just some food for thought.

[focuspark]

NRP, on 19 November 2013 - 01:21 PM, said:

Have you finished implementing alpha heat? I ask because I noticed a peculiarity.

Equip 2 PPCs: alpha heat = 20
Equip 3 PPCs: alpha heat = 42.6 (I guess this number is correct. It should be higher than 30)

Equip 2 PPCs + ERPPC: doesn't seem like there is an alpha heat number for this combo, so the app just implies 20+15. However, I believe PGI applies a ghost heat penalty based on the ERPPC base heat, which would result in an alpha heat number greater than 42.6, certainly higher than 35 anyway.

It would be nice if the ghost heat effects could be reflected in that overall heat performance number I talked about earlier. You could have one % number just based on heat dissipated/heat generated without ghost heat effects, and another % number that includes the ghost heat penalty (if there is one). This would tell us how badly a build would suffer from alpha striking. Not a big deal though, just some food for thought.

The first pass of alpha heat was completed. I did it on a per weapon type (not heat group) methodology.

If that's not working for you, I could do it on the entire mech instead and/or addition.

[Galil Nain]

Gremlich Johns, on 10 November 2013 - 07:53 AM, said:

More for those who do not own a windows phone. If you've never used a windows phone, don't be hatin'.

A fair point when used to counter most peoples derision of Windows Phone. When someone is deriding WP because it is WP, I too have issues with it.

In my case, however, my dislike of Windows phones isn't the WP OS, it's the hardware (I used to be staunchly pro-Nokia, but they have lost my support due to phones that I just don't like the look or feel of, and the non-Nokia options for WP in my area are very limited at present and not particularly appealing either.).

For the record, prior to my current Android phone (Sony Xperia T), I have used various iterations of Windows Mobile / Windows Phone for the last 10+ years on handsets from Compaq and, post merger HP (although in the case of the penultimate one I owned, I believe it was really a re-badged HTC). Got to be honest, I've never been as impressed with a smartphone as I was with those. 'tis a shame HP got out of the phone business. HP + WP would have been a good match, if they kept to the standards they had back then!

My step-daughter (22) has inherited my old HP Data Messenger with WP6.1 and, while it took her a couple of days to figure it out, she is now dreading having to adapt to a new phone OS when it eventually dies (Probably not that far off... it is over 5 years old and her daughter does have a habit of spilling drinks on it! Even getting a replacement battery for it is probably too much to hope for these days!). She was initially VERY reluctant to take it on, but had little choice due to her old phone dying and no funds for repair/replacement. Now, however, her opinion is that they just don't make 'em like they used to!

The real problem WP has, from what I can see, is a lack of "street cred". Apple and Android have been seen, almost from the outset, as personal phones that can be useful in a business setting. Apple, because they got there first, and Android possibly due to the boost from open-source fans touting it as the saviour of personal choice, especially in the early days of iPhone jail-breaks. BlackBerry were the opposite, a business phone that managed to break out into the mainstream. Windows Phone, however, despite all of the marketing that has been, and continues to be, done, still hasn't managed to be seen as more than an expensive business tool. This is probably, in part, due to MS dropping the ball in losing focus on handheld computing in the post-vista, pre-Win8 era. It's a shame, really, as the OS, especially with its far slicker cross-platform integration compared to the competition, makes it ideal. It's probably also this poor market penetration that is limiting the available hardware options due to companies not wanting to take an expensive gamble on what many consider (wrongly) to be the newcomer to the smartphone market.

Edited by Galil Nain, 19 November 2013 - 03:19 PM.

[focuspark]

Galil Nain, on 19 November 2013 - 03:00 PM, said:

...

While we're on the topic of sharing, I have some "insider" background info on the success/failure of Windows Phone from conversations with people at Microsoft while I was a lead on the NVIDIA Tegra project. Effectively, Microsoft made two mistakes. The first was assuming that they could leverage corporate IT departments to force the use of Windows Mobile (the old version of Windows Phone) thus insuring adoption among home users in the same way that IT forced Windows usage lead to Windows 90%+ domination on the PC desktop. Strong efforts by Apple and Google to encourage third-part BYOD (bring-your-own-device) integrator undermined Microsoft's assumptions and lead to users choosing the most appealing device and corporate IT departments supporting them.

Microsoft second mistake was, when the released Windows Phone 7, to be too customer focused; to the point where basic corporate IT department requirements (which Apple and Google had now met) were absent. Unfortunately, Microsoft's new phone OS (while a hit with reviewers) never gained the traction or mind share that iOS and Android did. Corporate IT departments were hopeful with a Microsoft customer-centric phone they could return to the days of limiting choice (thus making their lives easier) but with required features absent the IT departments couldn't standardize on Windows Phone.

Now we have the situation where IT departments are long past the time when they could have forced Windows Phone adoption, even though Windows Phone now supports all the necessary features for IT department adoption; and on the consumer front Apple and Google have the mind share thus insuring their dominance in the future. Last number I saw were something like Android @ 55%, iOS @ 35%, WP @ 5%, everyone else together @ 5% with Android outselling everyone else (including Apple and Microsoft) combined.

This would lead one to assume that Google (via Android) will soon completely dominate the phone market in the way Microsoft dominated the PC market. However, there are a few things to consider. First, Android is not a unified platform like iOS or Windows Phone; every handset manufacturer has source code and modifies as they see fit (certain restrictions prevent them from doing stuff like breaking compatibility with Google's app or removing Google ads).Second, the leader who drove Android to where it is today, has been replaced as the head of Android (inside people tell me it was because he "wasn't focused on the money") and while the impact is unknown, my guess is that it'll deflate of the magic that made Android so successful. Finally, Apple still makes the lion's share of the profits; besides Samsung none of the other Android handset makers are reliably profitable from Android handset sales. This means eventually the market will consolidate around Samsung and Motorola (aka Google); and since Motorola is a joke, Samsung will dictate the future of Android and personally I do not believe Samsung will be a good Shepard.

Anyways, there you have it. Android dominates by pure numbers. Apple makes all the money. Microsoft is very slowing regaining market share but since they were doubly late to the game nobody is holding their breath.

[NRP]

One other request (although it's a small matter): I would like the mech's total weight number to be represented with one decimal place (e.g. 79.8 tons). It seems that right now, the total weight is only represented in 0.5 ton increments. Sometimes, you really have to tweak armor counts in minute amounts in order to shoehorn in all the stuff you want, and it would be helpful to know more precisely the effect of armor value changes on the mech's total weight.

[focuspark]

NRP, on 20 November 2013 - 11:58 AM, said:

One other request (although it's a small matter): I would like the mech's total weight number to be represented with one decimal place (e.g. 79.8 tons). It seems that right now, the total weight is only represented in 0.5 ton increments. Sometimes, you really have to tweak armor counts in minute amounts in order to shoehorn in all the stuff you want, and it would be helpful to know more precisely the effect of armor value changes on the mech's total weight.

I'll consider it. The decision to do 0.5 ton increments (for IS and 0.25 for Clan) was based on TT rules which specify that parts are allocated in those allotments. There's meter at the top right of the app showing how many excess armor points are have. Raise that number to 16 and 0.5 tons will be removed from the 'mech.

I understand why Smurfy's and MWO mech lab use the 0.01 ton mechanism, but it's kind of invalid because none of the components you can purchase are less than 0.5 tons.

I'd rather come up with a better UI element and not rely on the tons value. I'll see what I can do.

[NRP]

There is an issue (similar to that for the Phoenix mechs) with creating a build for the Stalker Misery. Upon naming the build, the app crashes to desktop and all subsequent attempts to re-launch it fail. Actually, it fails for any Stalker.

Edit:
Also, is there a way to save the builds I've already created when the app crashes and must be reinstalled? I had quite a few builds that all got nuked when I reinstalled the app after the Stalker "incident".

Edit2:
The app also crashes when naming an Ilya Muromets build.

Edited by NRP, 25 November 2013 - 12:22 PM.

[focuspark]

NRP, on 25 November 2013 - 11:49 AM, said:

There is an issue (similar to that for the Phoenix mechs) with creating a build for the Stalker Misery. Upon naming the build, the app crashes to desktop and all subsequent attempts to re-launch it fail. Actually, it fails for any Stalker.

Edit:
Also, is there a way to save the builds I've already created when the app crashes and must be reinstalled? I had quite a few builds that all got nuked when I reinstalled the app after the Stalker "incident".

I can reproduce the problem. Thanks. Seems Stalkers weren't in the my set of "test" mechs. Not sure how I missed adding any. I have an internal vnext build on my phone currently (as well as the production versions) which has the issue resolved (happy coincidence). I'll get the patch pushed to the Phone Marketplace ASAP.

As for saving off builds. Yes, it's possible but I'd need a place to save them. Windows Phone doesn't have a document store or similar. Best idea I've had is using SkyDrive but the method of working with SkyDrive has difficult enough to dissuade me from continuing my early attempts.

Now that we've been seeing issue which require a reinstall, I might revisit allowing users to cache their designs via Skydrive.

[NRP]

Further testing reveals the problem also occurs with the following mechs:

Cataphracts
Blackjacks
Hunchbacks
Kintaros
Cicadas
Centurions

This is all I tried, so there could be problems with other mechs. I suggest you test each and every mech before submitting an update.