54 replies to this topic

[Dino Might]

How would this be difficult to implement?

Have a file that has the loadouts saved by name that you recall from the mechlab loadout screen. Once you pick a loadout, it strips the entire mech of parts and adds parts from the inventory to build that loadout. It is EXACTLY what we are doing manually everytime we do it. It is pretty much the same as making a macro for putting together a loadout, but would be much easier to do on PGIs end as a general mod to the UI because they already have the UI for putting parts on mechs.

If a particular part doesn't exist in your inventory, it pops up an error and reverts back to pre-loadout selection. If it costs money to change, that shows up before you save the changes to the mech, just like it is in the mech lab currently.

I don't know why we'd need a completely separate loadout system apart from the mechlab, unless you want the ability to change loadouts in a private lobby, but it's not worth making an entirely separate database management system for that. Also, it's lore friendly to say that you can't change your mech loadout while in the dropship. You're stuck with what you have until you're at the planetside mech repair facility. Dun dun dun, [almost] everyone is happy.

[Dino Might]

xImmortalx, on 09 November 2015 - 05:44 AM, said:

First off, you're greatly oversimplifying the way loadouts currently work. I'm not familiar with the game codebase at all but it's safe to assume that, in addition to what you mentioned, they at the very least have code in place to prevent invalid (hacked) loadouts and to ensure that each loadout is identical to when it was saved (identical item location). This adds up to a lot more data than "strings and item identifiers". Then there is armor allocation which requires 11 bits of info (HP at each location on the mech). Then you have camos and colors, cockpit items and modules. I can only imagine how much of a pain in the rear quirks were to implement.

This data is already going back and forth all the time when you modify things in the mechlab. No performance degradation with the suggested feature.

xImmortalx, on 09 November 2015 - 05:44 AM, said:

Second off, how do you treat upgrades? Are they chassis-specific or loadout-specific? Do you just throw out loadouts that are built using different sets of upgrades than the ones currently equipped? Or you do make people pay tons of cash to switch between loadouts made using different sets of upgrades? Or do you find a way for a user to own every possible upgrade/downgrade for any given chassis?

Upgrades are specific to the loadout, and to change from one loadout to another, you are changing the upgrades on the mech and have to pay, just like when you do it manually in the mechlab. All we want is a quick one-touch button to do what we already do in the mechlab, exactly the way the mechlab does it.

xImmortalx, on 09 November 2015 - 05:44 AM, said:

Thirdly, how exactly do you implement the loadout system? The easy way would be to use the current chassis system and just treat duplicate chassis as loadouts but lots of users have dupes on purpose and might not want to part with them. You would at the very least have to disable purchasing of duplicates and then run a script on the database beforehand that pays users back for their dupes before converting them to loadouts. And I'm sure even then there would be complaints. The hard (and right) way would be to do away with the chassis = config mechanism entirely and separate the data structure into chassis info (type identifier, owner identifier) and loadout so that multiple loadouts can be assigned to a single chassis. This can be problematic both in the quantity of data (current quantity of data * average number of loadouts per chassis) and possible speed penalties when fetching/saving + validating data, not to mention the programming effort involved in rewriting a core system of the game and the massive testing required to validate said rewrite.

No - you can still have duplicates and make it simple. Each chassis variant (e.g., Raven 2X) has a list of user saved loadouts. The user can select any duplicate of that chassis and load one of his saved loadouts for that variant, paying whatever costs and pulling items from inventory just as if he were manually putting together that loadout on that duplicate chassis. Again, keep it just like how the mech lab currently works, but reduce the number of clicks and drag'n'drops required to a click, scroll, and click, done.

xImmortalx, on 09 November 2015 - 05:44 AM, said:

I don't know your background or your occupation but this is not nearly as simple as you make it sound. Treating it as trivial when it isn't anything resembling that is at the very least inconsiderate and only shows your ignorance of the field you're so casually passing judgement on.

I think you are making this more complicated than it is - we don't need an entirely new data structure for this. All we need is some additional metadata in the current structure and a small UI option to call on that data and then use the already coded UI assets to make the user-desired changes.

xImmortalx, on 09 November 2015 - 05:44 AM, said:

You and others like you act like spoiled brats who think that they don't get the things they want from their parents because said parents (a.k.a. the developers) are mean and not because there are objective facts which you may not be aware of that don't allow then to give you what you want at the moment.

There has been no good argument as to why this isn't done already (after years of asking) except for the possibility that it increases PGI revenue. If that's the case, say it and we'll gripe about money, but it's a reality that we have to accept.

xImmortalx, on 09 November 2015 - 05:44 AM, said:

It's no wonder PGI barely reads these forums. If I was on that team and someone talked about my work the way you do I'd want to smack you upside the head too.

This I agree with - the incessant name-calling and berating is pretty terrible, sometimes.

[xImmortalx]

Dino Might, on 09 November 2015 - 09:25 AM, said:

This data is already going back and forth all the time when you modify things in the mechlab. No performance degradation with the suggested feature.



Upgrades are specific to the loadout, and to change from one loadout to another, you are changing the upgrades on the mech and have to pay, just like when you do it manually in the mechlab. All we want is a quick one-touch button to do what we already do in the mechlab, exactly the way the mechlab does it.



No - you can still have duplicates and make it simple. Each chassis variant (e.g., Raven 2X) has a list of user saved loadouts. The user can select any duplicate of that chassis and load one of his saved loadouts for that variant, paying whatever costs and pulling items from inventory just as if he were manually putting together that loadout on that duplicate chassis. Again, keep it just like how the mech lab currently works, but reduce the number of clicks and drag'n'drops required to a click, scroll, and click, done.



I think you are making this more complicated than it is - we don't need an entirely new data structure for this. All we need is some additional metadata in the current structure and a small UI option to call on that data and then use the already coded UI assets to make the user-desired changes.


There has been no good argument as to why this isn't done already (after years of asking) except for the possibility that it increases PGI revenue. If that's the case, say it and we'll gripe about money, but it's a reality that we have to accept.



This I agree with - the incessant name-calling and berating is pretty terrible, sometimes.

The only legitimate point here is that PGI hasn't been very communicative here, which I agree with. But can you blame them, given armchair developers like you that trivialize their efforts by constantly second guessing them and giving mostly uneducated opinions about how easy some things should be? Have you considered the fact that maybe their explanation would make no sense to 99% of the community and would thus cause even more noise? Because, as we all know, when people don't understand things they tend to get aggressive to cover up for their own ignorance.

Just because something seems simple to you doesn't mean it actually is simple. How do you think a surgeon would feel if people were constantly running into the operating theater and yelling at him that his 4 hour operation should take 30 minutes without actually knowing the first thing about surgery? Mind you, I'm not comparing the two disciplines, but I'm sure that the average citizen's knowledge about medicine is a lot better than his knowledge about software development.

As for your suggestions, keep in mind that all "loadouts" have to be synced with PGI servers as well as saved locally, and they have to be validated by the client and by servers when selecting or saving a config and when dropping into a game with it. You don't want to lose hundreds of configs because you forgot to back them up, the mechlab still has to work the same way (showing you what mechs are valid and what mechs aren't; stopping you from dropping with a engine-less mech) and you don't want malicious individuals abusing this new mechanic because it wasn't fully thought out.

[Almond Brown]

Quote

Yeah, I like the Mechlab. It's fun to tinker, it's fun to build. It's fun to optimize, etc. Fun.

Quote

I am just sick and tired of wasting so much time in the Mechlab.

I am sensing some conflicting information here somewhere...

[Dino Might]

xImmortalx, on 09 November 2015 - 09:50 AM, said:

The only legitimate point here is that PGI hasn't been very communicative here, which I agree with. But can you blame them, given armchair developers like you that trivialize their efforts by constantly second guessing them and giving mostly uneducated opinions about how easy some things should be? Have you considered the fact that maybe their explanation would make no sense to 99% of the community and would thus cause even more noise? Because, as we all know, when people don't understand things they tend to get aggressive to cover up for their own ignorance.

Just because something seems simple to you doesn't mean it actually is simple. How do you think a surgeon would feel if people were constantly running into the operating theater and yelling at him that his 4 hour operation should take 30 minutes without actually knowing the first thing about surgery? Mind you, I'm not comparing the two disciplines, but I'm sure that the average citizen's knowledge about medicine is a lot better than his knowledge about software development.

As for your suggestions, keep in mind that all "loadouts" have to be synced with PGI servers as well as saved locally, and they have to be validated by the client and by servers when selecting or saving a config and when dropping into a game with it. You don't want to lose hundreds of configs because you forgot to back them up, the mechlab still has to work the same way (showing you what mechs are valid and what mechs aren't; stopping you from dropping with a engine-less mech) and you don't want malicious individuals abusing this new mechanic because it wasn't fully thought out.

I understand your sentiment, but nobody has given a compelling reason other than "coding magic" as to why what we asked is so difficult. Your answer does provide a potential problem, but recognize that the game has already solved this problem with the current iteration of the mechlab - it saves a mechs loadout, backs it up, prevents malicious attempts to circumvent the game design, etc. Given that the proposed solution does nothing to change how the game does this, and given that I could program a macro to do exactly what we're talking about (press alt+2 and the mouse moves to the strip mech button, then goes to the weapons and drags this weapon onto that slot, etc. etc.), which would be unable to mess up any of the game's data structures, then how is there some coding bogeyman that's going to make this take years and potentially open up severe weaknesses in the existing architecture? The reason why it needs to happen on PGI's side is because the only macro I could think of would involve absolute positioning of the cursor and require about 50,000,000 steps for the different iterations, and it would all be ruined by one change to the weapons list, if it grew or shrank by a row; however, PGI can call these elements from the database. Give me the database access and I'd just make the macros myself and not need them to create this functionality.

Is it really that impossible to take what we are doing manually and automate it with one more set of data? You save all these loadouts, but the game only checks whether the current loadout of the mech is legal. It already does that. So we're not making it run checks on every loadout for everything so the spinning circle of doom lasts for 30 minutes.

Is it really impossible to create the database that ties mech x with loadout y? The game already does that for current loadout. Why is it difficult for the game to do it with other loadouts without overwriting?

[Pjwned]

TheStrider, on 09 November 2015 - 07:42 AM, said:

I've been saving my load outs for 3 years now.

http://mwo.smurfy-net.de/mechlab

Yeh... There are many other features I'd rather them work on first.

Would just like to point out that to anybody with a brain this is clearly not "saving" a loadout in the game itself, rather smurfy's is simply a tool for planning a loadout.

Can you take that smurfy link, plug it into the game, and then happily play with that mech/build no fuss no muss? No? Then it's not saving the loadout, and you can get bent until you stop missing the point of the thread entirely.

[Pjwned]

Almond Brown, on 09 November 2015 - 10:15 AM, said:

I am sensing some conflicting information here somewhere...

That's because while it is fun to tinker around in the mech lab, it's a pointless waste of time to have to put every mech back together again for the dozenth+ time in the same way.

It's not conflicting info, you just miss the point.

[Impyrium]

General rule with being a player, playing a game and then discussing a new feature... never assume it's going to be easy, regardless of how easy it sounds like it would be.

I guarantee, unless you have experience with the actual codebase of the game itself, it's going to have complications and be more complicated than your thought. Or it might be simple, maybe you're right. But the general rule is, don't assume.

[Felicitatem Parco]

Dingo Red, on 09 November 2015 - 03:39 PM, said:

General rule with being a player, playing a game and then discussing a new feature... never assume it's going to be easy, regardless of how easy it sounds like it would be.

I guarantee, unless you have experience with the actual codebase of the game itself, it's going to have complications and be more complicated than your thought. Or it might be simple, maybe you're right. But the general rule is, don't assume.

Assumption can be a powerful tool.

What do you Assume will happen when this launches on Steam, and players cannot save their loadouts? You'll have droves of ticked-off kids who think (rightly) that they should not have to spend time rebuilding old loadouts when you could just load them from a save file. It's nuts. This should have been addressed prior to Steam.

[ColdPsyker1]

TexAce, on 07 November 2015 - 07:11 AM, said:

First someone has to plan it, then someone has to code it, then someone has to make the UI for it and then someone has to QA it. And then they have to hotfix it and change it because all the whiners QQ because reasons.

wait... PGI does QA?

*trips over another root in the bog*

*gets stuck on a lampost in the city*

*stubs toe on a rock*

*the statues... my god the statues are out to get me!!!*

[Impyrium]

Prosperity Park, on 09 November 2015 - 03:53 PM, said:

Assumption can be a powerful tool.

What do you Assume will happen when this launches on Steam, and players cannot save their loadouts? You'll have droves of ticked-off kids who think (rightly) that they should not have to spend time rebuilding old loadouts when you could just load them from a save file. It's nuts. This should have been addressed prior to Steam.

I think you'll find that discussing whether it's a good/necessary idea, and discussing the relative simplicity of adding such a feature, are two very different discussions. I've already stated it would be a good idea and good to have.

[Rushin Roulette]

ColdPsyker1, on 09 November 2015 - 05:27 PM, said:

wait... PGI does QA?

*trips over another root in the bog* - Actually part of that map... but yes... hoping they fix this like trees in the new maps

*gets stuck on a lampost in the city* - Fixed, they are destroyable

*stubs toe on a rock* - granted.... maybe they should add more of them so that single ones dont annoy you any more... like in Cuastic

*the statues... my god the statues are out to get me!!!* - Fixed, they were removed ages ago (not sure if they ar eback and destroyable or not though)

Corrected that for you. They may do very little QA in advance, but bit by bit they do actually fix some things if enough people politely request it for long enough. So maybe this issue (plus togleable TAG) can be done sometime (very) soon.

P. S. you forgot about the permanent (non-destroyable) sight blocking trees on Emerald Taiga which i would have personally added as point #1 .

[ColdPsyker1]

Rushin Roulette, on 10 November 2015 - 05:29 AM, said:

Corrected that for you. They may do very little QA in advance, but bit by bit they do actually fix some things if enough people politely request it for long enough. So maybe this issue (plus togleable TAG) can be done sometime (very) soon.

P. S. you forgot about the permanent (non-destroyable) sight blocking trees on Emerald Taiga which i would have personally added as point #1 .

It's not so much that the issues got fixed; its the amount of TIME it took to fix the problems.

The statues on River City (old) got removed like a year ago? And were there since closed beta?

The lamppost I referenced were the ones of Crimson Straight... which stayed there for like a year...
They just completely blocked a mech's movement; it was extremely aggravating, and never should have been on there more than a week, let alone a year.

Point being; these issues are so obvious that they never should have gone onto public release in the first place, let alone sit there for a year/year[s].

[EgoSlayer]

Shatara, on 07 November 2015 - 04:55 PM, said:

Err, what? How would being able to save configs eliminate the need to have the parts that make them? As far as the server--and by extension the game's economy--is concerned, there is no difference between loading a config from a file and building it by hand. You'd still need the parts, and if you don't have them, you'd have to buy them. The only difference is how long it takes the player to do it.

The only thing it removes is the 'need' to buy multiple chassis and mechbays to hold them, and how many people actually do that (not counting the 'put multiple metamechs in clamwars deck' crowd, since saving wouldn't change that)?

Because as I said, you don't need several multiples of each piece of the equipment. If it only takes a few seconds to save/load a config you can strip your mechs at all times. Then you don't need 6 XL300 engines, you need one or two. Less if you never play CW and don't need to field 4 fully configured mechs. Same for modules, weapons (don't need 40 MLs, etc), and so on. The solution to that would be to lock the equipment into each configuration so that it still forces the multiple redundant equipment inventory, such as LostDragon mentioned.

[adamts01]

I buy multiples of many mechs that I like to play, including engines and all modules. I understand there needs to always be something to grind for in a f2p game so I don't blame them one bit for making it inconvenient to swap/find modules and whatever else. I own something like 15 radar deps and probably twice as many seismic sensors. I've never paid cash of a duplicate mech though, that price point is stupid high. All that said, I wish they would start offering subscriptions and eventually turn it in to a "first 6 months is free" game. That way they could focus on building a lasting game instead of cranking out new mechs.