55 replies to this topic

[XphR]

Lokesh, on 12 November 2013 - 03:31 PM, said:

To the original theory - having a weapon somehow 'marked' as being original to the much would require extra code that exists for no reason. It would also needlessly inflate the game's database. Very unlikely.

I once saw a work around described on the forums and can not for the life of me find it. Similar to the method described on the first page, you would save the mech. Then reload it, remove one of the weapons and save the much again. Finally, reload it and add the gun back. I can't remember whether you would remove the gun to be placed in a slot or the one that kept getting in the way. You might experiment with a sequence like this.

My Death Knell optimally (for myself) would wear a MPL over a SL in each gauntlet. I for the most part have to settle with SL over MPL save the times like these... when I fool with it ....and it gets stuck ...with the MPL over SL in the right arm as it should be and the left arm... the one that for the life of me has never had MPL over SL.. and the fury it creates in me powers the darkest sides of the force.

I dont think the code has so much been added for it at all, as it is the way the existing background code is working with what they have layered on top of it.. or vice versa. Its more like we are dealing with a bad spreadsheet parser crossed with bad legacy formatting.

Edited by XphR, 12 November 2013 - 11:17 PM.

[Lokesh]

XphR, on 12 November 2013 - 11:14 PM, said:

I dont think the code has so much been added for it at all, as it is the way the existing background code is working with what they have layered on top of it.. or vice versa. Its more like we are dealing with a bad spreadsheet parser crossed with bad legacy formatting.

No doubt. Which is why messing around with the order of operations/saving/loading etc might sometimes fix the problem. I was referring to the OP's suggestion that the specific weapon that came from the mech would exist in your inventory with some sort of memory as to which mech and slot it had come from.

[Tiamat of the Sea]

Indeed, Lokesh.

However, that post was originally composed when this conversation had not even started (and started that conversation) and was based on the understanding that had at first been passed on to me by another player and then, to all appearances, verified by my own play experiences.

I have every intent of completely replacing the content of that post in the near future (likely sometime this evening or tomorrow morning).

[Goldfish300]

XphR, on 12 November 2013 - 11:14 PM, said:

I dont think the code has so much been added for it at all, as it is the way the existing background code is working with what they have layered on top of it.. or vice versa. Its more like we are dealing with a bad spreadsheet parser crossed with bad legacy formatting.

If that is the case, then maybe the new UI will inadvertently fix this. From what I remember of the dev post made a while ago, they are rewriting the UI system from scratch.

[XphR]

Goldfish300, on 19 November 2013 - 04:28 PM, said:

If that is the case, then maybe the new UI will inadvertently fix this. From what I remember of the dev post made a while ago, they are rewriting the UI system from scratch.

I can only hold a naive hope of that to be true. However, I believe the problem sits much deeper and the UI is just passing along what it sees from layers below. I have the tiniest bit of hope that the file restructuring will be a step towards the right direction (back end mech restructuring) in eventually allowing hard point control down the line.

[Goldfish300]

XphR, on 19 November 2013 - 04:44 PM, said:

I can only hold a naive hope of that to be true. However, I believe the problem sits much deeper and the UI is just passing along what it sees from layers below. I have the tiniest bit of hope that the file restructuring will be a step towards the right direction (back end mech restructuring) in eventually allowing hard point control down the line.

Well, the dev post suggests that changes to backend systems have been made to help support the new (and far better) design of the UI layers.

At the very least, if I were making such radical changes to a part of a program I would revisit the modules/systems it interfaces with to see if they are still compatible. Its also possible that the way the current UI was coded (dev post makes it sound like it was hacked together rather than designed) placed undesirable restrictions on deeper layers, which could be overcome with the new UI.

But yeah, time will tell.

[Geek Verve]

Goldfish300, on 19 November 2013 - 04:28 PM, said:

If that is the case, then maybe the new UI will inadvertently fix this. From what I remember of the dev post made a while ago, they are rewriting the UI system from scratch.

Generally speaking, the UI is merely a visual representation of what is going on in the code. If weapons are fixing to the wrong hard points, my guess is that it's because they are coded to do that. Who knows what the reasoning for it may be, unless it simply has to do with the available art assets for displaying the various combinations. For example, for a side torso on a given mech, perhaps they have graphical representations for an auto cannon on top and laser underneath it, but not the other way around.

Edited by Geek Verve, 20 November 2013 - 12:10 PM.

[XphR]

Geek Verve, on 20 November 2013 - 12:09 PM, said:

Generally speaking, the UI is merely a visual representation of what is going on in the code. If weapons are fixing to the wrong hard points, my guess is that it's because they are coded to do that. Who knows what the reasoning for it may be, unless it simply has to do with the available art assets for displaying the various combinations. For example, for a side torso on a given mech, perhaps they have graphical representations for an auto cannon on top and laser underneath it, but not the other way around.

This however should not effect the identical laser diodes on my DK. It seems to be a lack of forethought followed by running into the issue, sadly ended with sweeping it under the carpet from a "we dont understand how this could possibly be an important customization option so we will not be revisiting it anytime soon if at all.". And that leaves people feeling a bit like the makers of the game dont quite "get it" when it comes to "customization" or the ability to build properly symmetric or asymmetrically by design.

Animals at our zoo? My god no, those things are dangerous.. We do however have a grand selection of feeds available and you are always welcome to go back out to your car and find another Zoo.

[Felio]

Thanks to this information, I was able to get an LRM 20 in the 20-tube hardpoint and an LRM 10 in the 10-tube hardpoint on my Heavy Metal. I did it by storing all my other launchers in other mechs and buying new ones.

Now, instead of firing 20, then 10, I can fire 30 at once.

Thanks, bro!

[XphR]

It didnt work for the lasers. >_<

[Hexenhammer]

Why won't PGI fix this? It won't add value to the game.

[Simbacca]

I too have been frustrated by this issue, most recently placing SRMs on the Wolverine.

[XphR]

Sure would be nice if this was revisited by someone that knows if the new UI back end work goes as deep as mech customization (doubtful) or if they (pgi) understands the reasoning behind pilots needing more control over matching weapons to hardpoints and the feeling of this mech is mine that comes along with it..

[Ainthe]

Problem:

Some weapons retain their hardpoint position priority based on their previous stock location.
Problem is you have no way of knowing this short of equipping the weapon and seeing it shifts its hardpoint position.

Solution:
1> Buying a new weapon.
2> Equipping weapons with undesirable hard point priority in 'Mechs that you do not require hardpoint priority. IE. you have 3 Energy hardpoints, you want 3 Medium Lasers, put 3 Medium lasers with hard point priority as which medium laser is first has no meaningful difference since they are all the same weapon.
3> Equipping weapons with undesirable hard point priority in single hardpoint location. IE. you have a medium laser that always like to be the bottom energy slot; if you only have one energy slot, the matter is moot.
4> Sell the offending weapon, and refer to Solution 1.

No reason for PGI to fix this, it is an inconvenience nothing more.

If you sell all your stock weapon loads and buy new weapons you will never encounter this issue.

[XphR]

Ainthe, on 22 January 2014 - 09:17 PM, said:

Problem:

Some weapons retain their hardpoint position priority based on their previous stock location.
Problem is you have no way of knowing this short of equipping the weapon and seeing it shifts its hardpoint position.

Solution:
1> Buying a new weapon.
2> Equipping weapons with undesirable hard point priority in 'Mechs that you do not require hardpoint priority. IE. you have 3 Energy hardpoints, you want 3 Medium Lasers, put 3 Medium lasers with hard point priority as which medium laser is first has no meaningful difference since they are all the same weapon.
3> Equipping weapons with undesirable hard point priority in single hardpoint location. IE. you have a medium laser that always like to be the bottom energy slot; if you only have one energy slot, the matter is moot.
4> Sell the offending weapon, and refer to Solution 1.

No reason for PGI to fix this, it is an inconvenience nothing more.

If you sell all your stock weapon loads and buy new weapons you will never encounter this issue.

This is simply untrue. Selling off my stock of small and medium pulse lasers did not allow my Death Knells left and right arms to mirror one another (MP over SL). I specifically purchased the DN with this loadout in mind.

Edited by XphR, 22 January 2014 - 09:38 PM.

[XphR]

{24/8/2014}

-

-: On a bit of a lark I entered into the dusty rundown mechbay that had become the final resting place of The Death Knell and primed up the overhaul and strip dock. I can only guess that the overly chard corpse of a machine rat had been shorting the system causing mayhem with weapons placement must have crumbled away.. Indeed I could now remove weapons and re-add them to the stack with each falling into reliable proper placement. I hope to never loose this function again. :-

-