169 replies to this topic

[Moku]

Fix something that makes the game more playable and fun. This just ends up costing us more and adds more selection clutter.

[Lord Perversor]

Drunk Canuck, on 19 November 2013 - 05:25 PM, said:

I like the changes being planned, however I would like to see a slight tweaking to how tight the firing is for LRM's. SRM's do need to be fixed though and I think that is a more pressing issue then changing Artemis.

As someone else has claimed on the forums or i discussed with my friends at comms..

Lrm should behave like Streaks but at long range.. Lrm are not to kill but to crush the armor, missiles should fly in a big ball but aim as group of 5 clusters to different sections.

[Sybreed]

Here's my feedback:

WHY AREN'T YOU REWORKING NARC INSTEAD OF ARTEMIS AGAIN, ARGH

SERIOUSLY, WHAT IS WRONG WITH YOU

I feel better now

[Derick Cruisaire]

As long as you are looking at Artemis. What are the chances of making launchers in the center torso utilize an Artemis module in the head? Thus making it possible to have an Artemis capable S.R.M.-6 or L.R.M.-10 in the center torso.

[Deathlike]

Sybreed, on 19 November 2013 - 05:31 PM, said:

Here's my feedback:

WHY AREN'T YOU REWORKING NARC INSTEAD OF ARTEMIS AGAIN, ARGH

SERIOUSLY, WHAT IS WRONG WITH YOU

I feel better now

This change doesn't really do much for me.... improving NARC would be far more useful of everyone's time.

[Eric darkstar Marr]

Okay I gotta be the debbie downer here, will this change finally stop the effect on on streaks lock ons granted I use them all the time it feels cheap to get the .5 second lock on making them way to easy to use.

Yeah hate me for letting the cat out of the bag but if they are doing a pass its time to fix that glitch.

[DragonsFire]

Again folks, while we all know that there are other items to be looked at and corrected, this is a front-end type of change that is being incorporated into UI 2.0. The post was an informational one on a fundamental change to how the system is going to work in UI 2.0 vs how it works now in UI 1.5.

I'm certainly not saying that the gripes are invalid or unwarranted, but before getting upset/annoyed about this information, also put some perspective on what the focus of this particular change is and that it does not encompass in-game work and mechanics.

Edit:

Eric darkstar Marr, on 19 November 2013 - 05:46 PM, said:

Okay I gotta be the debbie downer here, will this change finally stop the effect on on streaks lock ons granted I use them all the time it feels cheap to get the .5 second lock on making them way to easy to use.

Yeah hate me for letting the cat out of the bag but if they are doing a pass its time to fix that glitch.

I wouldn't be surprised if we see the lock benefit streaks get removed as a direct result of this or not long thereafter.

Edited by DragonsFire, 19 November 2013 - 05:51 PM.

[Xenon Codex]

QUICK QUESTION: What about all the launchers currently in inventory and not equipped, will they stay as regular non-Artemis after the patch that implements this change?

So if we want a mixed-bag of launchers, we need to make sure and equip them on the Artemis-upgraded mechs BEFORE installing the patch right?

I like the change. I just want everyone to be clear how current inventory will be handled so we can capitalize on the change-over.

Also, I really like the idea of mixing launchers. I was building a mech the other day that only had 1 missile slot in the head and couldn't use it because it had Artemis enabled. Now I'd be able to throw a LRM5 in that slot.

[ShinVector]

Hmmmm....

Took mean a while to under where the heck Paul could go with this.

Paul,

• Make it this way this wasn't the intention already:
  
• The upgrade on the BattleMech ? Stop calling it Artemis. Call it Artemis FCS (Fire Control System).
  
• During upgrade to Artemis FCS. Give the users the one time option to upgrade their equipped launchers and ammo to Artemis type. Else User has to purchase them separately.

*Mechs with Artemis FCS + Artemis Launchers + Ammo - Get full Artemis Benefits.
*Mechs with Artemis FCS + Can equip Standard Launchers + Ammo - No Artemis Benefits.

How you are going to deal with Streaks, I will leave that up to you.
It could just be as per normal, Artemis FCS means faster lock-on for all guided weaponry or you go selective.
It guess it would too complicated if a BattleMech has both Artemis System and Streaks at the same time.

*I realise many people will start going Artemis FCS + Standard LRMs for faster lock-ons without the extra weight and crit.
This can of worms is all up to you Paul !

[Galil Nain]

Warning... there is a LOT of text behind the spoiler tag. Bear with me, i tend to slip into verbose mode when my caffeine levels are low!

TL;DR:

• I doubt it will fix the unintentional SSRM lock-on time buff when Artemis is installed (and here's why!)
  
• Expecting it to fix the unintentional SSRM lock-on time buff is wrong (and here's why!)
  
• Fixing the Artemis MechLab costing and inventory issues as part of the UI2.0 project is the right thing to do (and here's why!)
  
• Cut the devs some slack on the time UI2.0 is taking, it's a bigger project than you probably think it is (and here's why!)
  
• The devs are improving on communication, but still do have the odd slip-up in allowing us to perceive promised release dates for things where no such promises were intended

Spoiler

CYBRN4CR, on 19 November 2013 - 04:36 PM, said:

Thanks for the info. Hopefully this means Streaks will no longer get any bonuses to lock on speed as they were never intended to benefit from it in the first place, or do so for 'free' compared to other missiles that had to pay the 1t/1c tax.

I may be entirely wrong here, but my understanding of how the bug occurred is this:

• Artemis includes a reduction in lock-on time.
  
• Mechs only have a single lock-on reticle for ALL equipped missiles, be they SRMs, LRMs or SSRMs.
  
• Even though there is no SSRM+A, SSRMs use this same reticle, so if it has its lock-on time reduced for equipped LRMs, that lock-on time will be reduced for SSRMs too.

As a result, unless they implement a second lock-on reticle with a new shape (Predator-style triangular shape would be what I'd like to see, just because it's sufficiently different and would probably look cool) to differentiate SSRM locks from other Artemis-equip-able missile types, complete with separate lock-on countdown timers, (probably a lot of work, and definitely in a separate part of the code-base) this MechLab fix detailed in Paul's post isn't going to do anything to fix it (and isn't intended to!).

The fix for the SSRM lock-on unintentional buff is an in-game code-base fix, not a UI code-base fix, so expecting that fixing the UI issue will fix the other is likely to be the product of a lack of understanding of the issues. The two issues, whilst they may appear related, are not and the implementation of fixes for them will involve work in two entirely separate areas of the code-base.

And to counter what others have said, whilst it was probably a fair bit of code for what was a comparatively minor issue to most of us (I, for example, don't use Artemis on anything at present, so this won't affect me), fixing this whilst they were cleaning up the UI code as part of the UI2.0 rewrite is definitely the right time to be doing it, rather than hacking it in post-UI2.0-release (remember that hacking the code is a large part of how UI1.5 got into the mess the devs have, surprisingly, had the honesty to admit it to be).

The way I read it, the way the MechLab handles Artemis at the moment is not only not working as currently intended, but is not even working how they had thought it should in the first place (and there is a chance that, due to the complexity of the code, they hadn't even noticed that this was the case until they got to that part of the UI2.0 project. It's certainly not something discussed with excessive prominence in the forums, so there's probably a very sizable part of the player-base who hadn't realised this, either!). Rewriting the module(s) of code handling the Artemis upgrades in the way it was supposed to work, rather than writing it to do what it does now, then having to patch it is what's called "doing it right". Remember folks, the alternative is what got the current UI into its current frankencode state. My guess is that the team working on UI2.0 are not the same folks working on the live game, so this wasn't taking time away from what are rightly considered more pressing things.

I would also guess that the whole point of Paul's original post wasn't so much to brag about the fact they're fixing the issue, but to highlight that as part of rewriting UI2.0 from the ground up, they noticed this issue and have fixed it and are publishing this update to:

• give another example of how the code in UI1.5 was borked
  
• show UI2.0 is being worked on and not some fabled myth trotted out to keep the player-base salivating for it's eventual arrival
  
• show that, whilst it is taking its time to arrive, the reason is that they are taking the time to get it right
  
• be part of a continuing effort to keep those of us who are hungry for communication from the devs happy
  
• serve as a partial early announcement of what's coming in the next PTS round

I know that Paul has become a target for the scorn of many forumites hereabouts, but on this one, it is, for me at least, a welcome update that, whilst showing that UI2.0 is still far from finished (Boo!!!), it's because they are taking the time to do it right (YAY!!!!). And whilst there is a degree of truth in saying that that's how it should have been done in the first place, such griping is of no help to either the player-base or the long-term prospects of the game.

We are where we are and, however painful and expensive in developer time and player-base goodwill, the devs have taken the right decision to throw out the bad and re-code from the ground up. It's going to take longer (never something us players like to hear) but it'll lead to a more stable, faster, easier to update interface that will allow future changes to be quicker and (I would expect) smaller to download.

Part of the problem around a lot of the discussions I've seen on the forums around UI2.0 and the changes that are reliant upon it seem to be predicated on the belief that "it's just a UI, a few pretty pictures and menus. How hard can it be?" Well... the UI is only part of it. In most games the UI sits on top of a heck of a lot of code that does the actual work. UI1.5 didn't sit on top of this code, the code was combined into it making a complex behemoth to debug and update. As part of UI2.0, the devs are doing what many (correctly) said should have been done from day one and separating these two elements (and, if they have REALLY learned their lesson, heavily modularising the code that sits under the UI doing the work). Essentially, as I understand it, they are re-writing pretty much the entire game bar in-match assets.

The public announcement of this work and what it entailed was only back in September, and yet everyone seems to expect a game that has taken 2+ years to get to where it is now to be rewritten from the ground up, by only a subset of the overall team, in 2 months. If the player-base want to accuse the devs of an epic failure to deliver, they should perhaps look in the mirror to see a prime example of an epic failure to have reasonable expectations. This being said, the devs could have done a better job in managing these expectations, as they have implied (yes, implied, NOT promised) release dates for UI2.0 on several occasions and have, it seems, still not learned that wording in their communications such as that chosen by PGI will only lead to elevated expectations on the part of the player-base. To be fair, however, when you are getting bombarded with some of the vitriol that appears on these forums, I can't say I really blame them for not always fully thinking through how their communications will be taken as promises and excuses for yet more vitriol.

Caveat: This is all just my understanding of the situation, and may be entirely wrong. I am not a programmer, but have worked with several over the years and have picked up some of the lingo and theory by osmosis, apologies if I have misused (or mis-spelled) any programming terms.

[Kashaar]

Okay, I have one question... why? What is the point of this? It creates management overhead for the user, and doesn't create more interesting gameplay decisions. It makes the mechlab game more grindy. Nothing else. Seriously, what's the thinking behind this?

[FupDup]

Kashaar, on 19 November 2013 - 06:17 PM, said:

Okay, I have one question... why? What is the point of this? It creates management overhead for the user, and doesn't create more interesting gameplay decisions. It makes the mechlab game more grindy. Nothing else. Seriously, what's the thinking behind this?

Because reasons.

[DirePhoenix]

Niko Snow, on 19 November 2013 - 03:37 PM, said:

SPECIAL NOTE:[color=#959595] The current UI2.0 build being made for Public Test contains this new Artemis functionality if you’d like to see how it works.[/color]

Does this mean the Public Test Shard is going to be back up... for the public (as opposed to the 'internal' testers)?

[ShinVector]

FupDup, on 19 November 2013 - 06:29 PM, said:

Because reasons.

Need stuff to break so, people have a valid reason not to work on CW.

[A Man In A Can]

Galil Nain, on 19 November 2013 - 06:16 PM, said:

*snip*

You're right. After re-reading it, it's basically just going to be business as usual just cheaper for long-term Artemis upgrades, complete with current non mix and match ability, but you're going to need separate stockpiles of Artemis and Standard launchers soon.

So start putting those launchers on your spare Artemis-capable mechs just in case.

[rageagainstthedyingofthelight]

In other news, anything PGI posts will be met with QQ.

However, our OP to QQ time is increasing, which is good.

That is all.

[HydroSqueegee]

Kashaar, on 19 November 2013 - 06:17 PM, said:

Okay, I have one question... why? What is the point of this? It creates management overhead for the user, and doesn't create more interesting gameplay decisions. It makes the mechlab game more grindy. Nothing else. Seriously, what's the thinking behind this?

Hush your mouth, boy! I dont care what the reason, this is a good change and provides more options in deciding what loadout to bring. "Do i need to bring artemis, or will the couple extra tons let me mount more/other equipment."

Being able to swap between regular missiles and artemis enabled racks without being charged 750k whenever you want to swap is a NICE change.

[slide]

Any chance of getting the spiralling LRM launch pattern back for Artemis equipped launchers?

It was an excellent way of telling if you had line of sight lock on or not. And it looked great.

[Threat Doc]

Whatever. I don't use SRMs and LRMs on the same 'Mech. In fact, I don't use SRMs, in general, so this really means nothing to me. I hope is has some sort of positive effect in UI 2.0. Now, to go see if I can get into testing for that.

[cSand]

Is there a stat somewhere that says that reading-comprehension is at an all time low these days?
Cause reading some of the responses here... it's gotta be