When can we expect to see a MechLab?

[Jaso the Sniper]

Or make the mech's cost ingame to spawn dependent on weapons and mech chassis cost. Say you have a atlas with a base cost of say, 70,000. You put 4 Large beam lasers with a cost of 3,000 each, putting it up 82,000 to spawn the mech ingame. Including heat sinks which could be like 2000 each and you put 10 that brings it up to 102,000. Maybe increasing armor of specific sections might cost per tenth of a ton.

mme likey

[phobeste]

Or make the mech's cost ingame to spawn dependent on weapons and mech chassis cost. Say you have a atlas with a base cost of say, 70,000. You put 4 Large beam lasers with a cost of 3,000 each, putting it up 82,000 to spawn the mech ingame. Including heat sinks which could be like 2000 each and you put 10 that brings it up to 102,000. Maybe increasing armor of specific sections might cost per tenth of a ton.

Yeah, this is how I'd like it. I suspect that the devs internally are basing mech cost on a formula depending on the loadout of the mech - so just make a separate program accessible from the MWLL launcher that generates an xml file or something, just with names of weapos. When the game itself loads the file it does its own (serverside) check of whether the loadout is overweight and generates the cost, preventing cheating.

I definitely agree with HAARP that this should be a separate program though because it would suck to see a server that's completely full... but with four people fighting and the rest trying to decide on the proper ratio of cgauss to ermbl on their favorite shadowcat lol.

[Rally]

I definitely agree with HAARP that this should be a separate program though because it would suck to see a server that's completely full... but with four people fighting and the rest trying to decide on the proper ratio of cgauss to ermbl on their favorite shadowcat lol.

No way. Make it in-game. Having to quit the game and start it up again just to make a quick but desirable little modification to your mech would suck more.

[HAARP]

I definitely agree with HAARP that this should be a separate program though because it would suck to see a server that's completely full... but with four people fighting and the rest trying to decide on the proper ratio of cgauss to ermbl on their favorite shadowcat lol.

No way. Make it in-game. Having to quit the game and start it up again just to make a quick but desirable little modification to your mech would suck more.

alt+tab?

[Pytak]

I definitely agree with HAARP that this should be a separate program though because it would suck to see a server that's completely full... but with four people fighting and the rest trying to decide on the proper ratio of cgauss to ermbl on their favorite shadowcat lol.

No way. Make it in-game. Having to quit the game and start it up again just to make a quick but desirable little modification to your mech would suck more.

alt+tab?

Crysis doesn't reflect vehicle modification changes made on the fly; you need to restart the application for them to take any effect.

[Rally]

I definitely agree with HAARP that this should be a separate program though because it would suck to see a server that's completely full... but with four people fighting and the rest trying to decide on the proper ratio of cgauss to ermbl on their favorite shadowcat lol.

No way. Make it in-game. Having to quit the game and start it up again just to make a quick but desirable little modification to your mech would suck more.

alt+tab?

If changes made in said external application would reflect in the game in real time then yes, alt+tab is acceptable. But what's the point of having an external application then?

[HAARP]

alt+tab?

If changes made in said external application would reflect in the game in real time then yes, alt+tab is acceptable. But what's the point of having an external application then?

I can make variants conveniently at any time without starting the game and joining a server, even from within a virtual machine and without any unneeded bloat.

[phobeste]

A compromise: like someone was suggesting earlier, any change made in-game will cost CBills. But, any mech made in the out-of-game editor just has its formulaic price.

I.E., I make a shadowcat variant with, say, a CUAC20 and flamers in the mechlab. It costs whatever the cost of the chassis+systems+armor+weaps is. But, after a few deaths, I decide that some SPLs would be a better choice for those slots. If I change it in-game, when I change it it costs me (price of SPLs + price of whatever else I change) * 1.5 or something, at the instant I make the change.

[darkrei9n]

Well how about this, if you change it ingame you get charged a onsite technician fee for the sudden change in mech layout.  A portion of the price of the weapons you took off is subtracted from the price and whatever you add is added to the price plus the onsite technician fee. Which could be like 5,000 to 20,000 depending on the mech.

[Jaso the Sniper]

A compromise: like someone was suggesting earlier, any change made in-game will cost CBills. But, any mech made in the out-of-game editor just has its formulaic price.

I.E., I make a shadowcat variant with, say, a CUAC20 and flamers in the mechlab. It costs whatever the cost of the chassis+systems+armor+weaps is. But, after a few deaths, I decide that some SPLs would be a better choice for those slots. If I change it in-game, when I change it it costs me (price of SPLs + price of whatever else I change) * 1.5 or something, at the instant I make the change.

+1 love it exactly what I was thinking

[=CJW=YalK]

+2 like it as well

[Virt]

That would just lead to a multiplier effect...

Very good players would use their early CBill haul to create even more effective killer vehicles, which would in turn further accelerate their domination of the game.

You can argue that good players should be rewarded more than average ones.   But if those rewards effectively make them  indominatable on the battlefield, then it will drive new and average players away.

[Aidan]

That would just lead to a multiplier effect...

Very good players would use their early CBill haul to create even more effective killer vehicles, which would in turn further accelerate their domination of the game.

You can argue that good players should be rewarded more than average ones.   But if those rewards effectively make them  indominatable on the battlefield, then it will drive new and average players away.

Hence the need for a Mech Lab that can be enabled/disabled at the server level.

[KingLeerUK]

We are still determining the functionality and requirements for the MechLab.  Due to the way that asset variants are stored, it may not be feasible/possible to have dynamic, user-customised variants introduced during runtime, thus necessitating an "offline" MechLab application only.
 
Assuming that both an offline and an integrated "online" MechLab option were possible, the development team will choose one path.  Doing otherwise would require that the codebase for the MechLab be maintained in two separate locations, with two separate storage methods, which would derive no real benefit.
 
I still will be pushing for any MechLab generated design to have an overhead cost for doing so, and this regardless of the "level" of customisation.  Trying to differentiate between different "amounts of tweaking" would add unnecessary complexity to the interface and introduce points of failure and/or possible exploits.

[Jaso the Sniper]

That would just lead to a multiplier effect...

Very good players would use their early CBill haul to create even more effective killer vehicles, which would in turn further accelerate their domination of the game.

You can argue that good players should be rewarded more than average ones.   But if those rewards effectively make them  indominatable on the battlefield, then it will drive new and average players away.

Hence the need for a Mech Lab that can be enabled/disabled at the server level.

and

We are still determining the functionality and requirements for the MechLab.  Due to the way that asset variants are stored, it may not be feasible/possible to have dynamic, user-customised variants introduced during runtime, thus necessitating an "offline" MechLab application only.
 
Assuming that both an offline and an integrated "online" MechLab option were possible, the development team will choose one path.  Doing otherwise would require that the codebase for the MechLab be maintained in two separate locations, with two separate storage methods, which would derive no real benefit.
 
I still will be pushing for any MechLab generated design to have an overhead cost for doing so, and this regardless of the "level" of customisation.  Trying to differentiate between different "amounts of tweaking" would add unnecessary complexity to the interface and introduce points of failure and/or possible exploits.

Great minds think alike.