Orange gear not viable for endgame?

[Chocbo]

Ok based on what I've heard here's my idea.

 

First, for the vanity system we could use something similar to the companion customizations

 

Second, for the core argument of this thread (bear in mind I'm parroting some people here) take the mod (which is removable) from the raid gear and put the set bonus on it. Then attach a (body, head, legs, etc.) marker ONLY TO THE RAID MODS. That way we won't have the D&C LT MH of adding tags to everything, but still allow full gear customization

 

May the force be with you

[_Flin_]

Not to mention the totally INSANE amount of tries you might need to crit a full set of orange armor and weapons. Have you looked at the materials those level 50 recipe require?

 

But isn't that the point? You don't NEED Level 50! You need whatever looks best in your personal opinion!

[Vilda]

Well, currently it looks like orange schematics that come "premoded" can certainly crit. Sadly, no such proof for armors yet. I remember one claim of exceptional chest piece, but didn't saw a screenshot

[MareLooke]

There was no insult there. Just valid observation based on your (limited) post which suggest, you don't know how object programming works. Mods are different objects then gear that are included in. They don't share information which character slot they are in because they dont need it. Also, all use the same model, therefore you CAN NOT make differences between PvP/PvE/raid mods. It contradicts very basis of object programming.

 

Disclaimer: All assumptions made in general on basis and generals of OOP, not actual TOR code as I respect professional courtesy and EULA.

 

And as I am moving to OT of my own topic, I stop here.

 

There are many ways to implement this, the static way would make extending this hard I guess we can agree on that. It would also be rather inefficient for such a dynamic system as a MMO imho so I highly doubt it's implemented like this (one never knows though).

 

I don't get what you mean by "all use the same model", if your model is this rigid you have a serious design issue.

 

Personally I think the entire thing is highly dynamic, the huge amount of (big) changes they already made to the mod system during the betas only strengthens my belief in this and as such I believe that implementing this wouldn't be too hard.

 

Either way we can discuss this ad infinitum without proper background information on how it is actually implemented. In my mind if it's designed properly adding this attribute should be relatively easy, if it's not done properly they will have serious issues later on anyway.

 

Disclaimer: I've been coding and designing OO applications for the past umpteen or so years starting with Java 1.2 (aka Java 2 which was just released then) but I've also learned that pure OO isn't exactly the answer to all problems (far from it) and have been branching out into other design/programming methodologies (currently mainly looking into functional programming again fwiw).

[Dayn]

The bottom line is, BioWare could restrict the mods found in "purple" items to that type of item, IE. chest/legs/feet/hands/head, and tie set bonuses to those mods. Not only could they do that (it's actually not that many items when you think about it, since purple items only make an appearance at end-game) but it would give the players almost exactly what they want (it would be exactly what the players want, if BioWare also increased the total number of modifiable items in the game, so we had more options as we leveled, specifically more modifiable legs/hands/feet/head options.)

 

But then, people suggested this back in beta and it was basically ignored. They just did whatever they wanted with the mod system, seemingly without paying much attention to the feedback of the testers.

 

-Macheath.

 

Here's an alternative suggestion that achieves the same result. No restriction on what equipment the mod is placed in. Instead have an identifier like a number for each mod, i.e. champ armor mod1, champ armor mod2, ..., champ armor mod 4.

 

Now you could put the mod in any piece of armor but having two mods with the same identifier woudn't add to the set bonus. A Champ armor mod1 and another Champ armor mod1 wouldn't give you the 2 item set bonus, but a Champ armor mod1 and a Champ armor mod3(or any number besides 1) would.

 

I think this would be an easier implementation.

 

Leveling up, the whole modable orange gear feature was awsome and now that I just hit 50 it's really upsetting to know that I am not able to make my char look the way I want him to and still be viable endgame. This is really a game killer and I hope bioware fixes it soon.

[TaishoD]

Personally, I don't see the point for the craftable lvl 50 orange gear.

 

Through a combination of PvP, normal class quests, light / dark side merchants, flashpoint drops, there's plenty enough of orange gear that we can get. And, once you get orange gear, there's no real reason to replace it with another set of orange gear unless you don't like the look of the one you have.

 

So ... we get options from a vanity perspective. As something that you can actually use in the end game progression however, they don't make much sense. You can just get the mods that you want elsewhere and slot it in to your current orange gear, and voila.

 

What I said has probably been said before in this thread. I guess I just needed to let it off my chest as well, since I just turned 400 artifice and found that the recipes I get are with the possible exception of the relics, crap. Why in heck would I need a craftable lightsaber with blue mods in it, when I would (at lvl 49) most likely have unlocked the last batch of purple hilts and enhancements?

 

Here's my thought: DON'T MAKE THE LVL 50 CRAFTABLE ITEMS ORANGE GEAR! Or if so, provide an option to craft an orange moddable version, as well as providing an ordinary blue recipe that we CAN RE to unlock T1 and then T2 purples.

 

Doing it that way, there's a reason for crafters to stick past 400. We'll keep at the system until we've unlocked the specific T2 purple that we want. Also, that kind of gear would fetch an ok price at the market and provide motivation to those who would want to stick the crafting system past 400.

[MareLooke]

Here's an alternative suggestion that achieves the same result. No restriction on what equipment the mod is placed in. Instead have an identifier like a number for each mod, i.e. champ armor mod1, champ armor mod2, ..., champ armor mod 4.

 

Now you could put the mod in any piece of armor but having two mods with the same identifier woudn't add to the set bonus. A Champ armor mod1 and another Champ armor mod1 wouldn't give you the 2 item set bonus, but a Champ armor mod1 and a Champ armor mod3(or any number besides 1) would.

 

I think this would be an easier implementation.

 

Leveling up, the whole modable orange gear feature was awsome and now that I just hit 50 it's really upsetting to know that I am not able to make my char look the way I want him to and still be viable endgame. This is really a game killer and I hope bioware fixes it soon.

 

This wouldn't work as being able to farm the first boss in an Operation to get raid quality mods for every gear piece (irregardless of the set bonus) was the main reason for them changing it to how it is now...

[djvapid]

The problem, to me, isn't whether or not specific gear is viable. The problem is that NOTHING is viable unless you grinded Warzones or Raids to get it. I think the root problem here is the lack of crafting as a viable/equal alternative to Raiding or PvP.

[Agathonikus]

http://www.swtor.com/de/community/showthread.php?p=1411465#edit1411465

 

Google translation, cause I have no time to find the english vison of this text

 

 

"The current state of affairs regarding endgame objects and modifications is not final, and I've seen some comments from community members who correctly guess what our plans are.

Once the topic Itemisierung many players at heart, I will come out with a few more details about our plans for purple items and modifications:

All purple items which are currently only partly modifiable, are again fully modifiable and allow removal of armor, legs and handles.

The set bonuses from purple Endgame sets (both PvE and PvP) will be transferable to custom items.

Some modifications are limited to certain types of objects. It is thus, for example, mods that can only be used for helmets, while others are applicable only for chest pieces etc.

 

 

Of course, here as always, all reservations apply with respect to game systems are still developing, but you should still have to get a good overview of what is our plan. It is our very serious that we want to make custom objects into a real alternative to endgame objects, and it is important that players play the entire time (to enter into the endgame) have the opportunity to customize their appearance to their wishes."

Edited January 10, 2012 by Agathonikus

[Chocbo]

http://www.swtor.com/de/community/showthread.php?p=1411465#edit1411465

 

Google translation, cause I have no time to find the english vison of this text

 

 

"The current state of affairs regarding endgame objects and modifications is not final, and I've seen some comments from community members who correctly guess what our plans are.

Once the topic Itemisierung many players at heart, I will come out with a few more details about our plans for purple items and modifications:

All purple items which are currently only partly modifiable, are again fully modifiable and allow removal of armor, legs and handles.

The set bonuses from purple Endgame sets (both PvE and PvP) will be transferable to custom items.

Some modifications are limited to certain types of objects. It is thus, for example, mods that can only be used for helmets, while others are applicable only for chest pieces etc.

 

 

Of course, here as always, all reservations apply with respect to game systems are still developing, but you should still have to get a good overview of what is our plan. It is our very serious that we want to make custom objects into a real alternative to endgame objects, and it is important that players play the entire time (to enter into the endgame) have the opportunity to customize their appearance to their wishes."

 

Many thanks for clearing this up but do you always read the german forums?

[Glarsaahl]

http://www.swtor.com/de/community/showthread.php?p=1411465#edit1411465

 

Google translation, cause I have no time to find the english vison of this text

 

 

"The current state of affairs regarding endgame objects and modifications is not final, and I've seen some comments from community members who correctly guess what our plans are.

Once the topic Itemisierung many players at heart, I will come out with a few more details about our plans for purple items and modifications:

All purple items which are currently only partly modifiable, are again fully modifiable and allow removal of armor, legs and handles.

The set bonuses from purple Endgame sets (both PvE and PvP) will be transferable to custom items.

Some modifications are limited to certain types of objects. It is thus, for example, mods that can only be used for helmets, while others are applicable only for chest pieces etc.

 

 

Of course, here as always, all reservations apply with respect to game systems are still developing, but you should still have to get a good overview of what is our plan. It is our very serious that we want to make custom objects into a real alternative to endgame objects, and it is important that players play the entire time (to enter into the endgame) have the opportunity to customize their appearance to their wishes."

 

if that is translated correctly, that is amazing news and i can only hope it wont take to long before it is ingame *fingers crossed*

[MareLooke]

if that is translated correctly, that is amazing news and i can only hope it wont take to long before it is ingame *fingers crossed*

 

If that's correct not having communicated this weeks ago to the entire community is a pretty epic fail since we've been asking about this since beta.

 

Other than that it's very welcome news (assuming it's correct...)

[Krowwe]

More about coding in general, it would seem. Lets use Enhancement as an example. Any enhancement can now be used in any place. With your proposed change every enhancement would have to in addition store information which piece of gear it can be insert into (and also affect ALL enhancement currently ingame), checking this variable during every modification attempt, creating confusion on market place and to players in general.

 

Actually, from a databasing side, you are most likely completely wrong.

 

As gear (helmets, legs, boots, etc) already has a positional restriction coding, it is HIGHLY likely that mods do as well.

 

Something like:

Mod A

Position=HEAD/CHEST/LEGS/BOOTS

 

or it could say ALL

 

or something to that effect.

 

The point is, the code is there for helms , its probably already being checked for mods as well.

 

The workload change would likely be mimimal.

[Bartes]

Because orange gear has ALL slots open, other items have armoring slot locked.

 

Not true! You can still put armor mod in them as you please. It will just not show on the item.

Dunno if it's intended or bug. If it's bug it may be fixed in some time.

 

 

Now I would like to see orange gear with augment slot. I've made like 30 orange lvl 50 pants in one session and nothing critted.

[Vilda]

Actually, from a databasing side, you are most likely completely wrong.

 

As gear (helmets, legs, boots, etc) already has a positional restriction coding, it is HIGHLY likely that mods do as well. .

I am still mortal, so I can be certainly wrong. But why would any mod need that information as it is now?. Data structure for mod doesn't need more than

{ // pseudocode of java mixed c++

int lvl_requirement

enum position_in_item

enum type_of_bind

class effects

}

nothing more. Data structure is well designed, when you run off the things to delete from it.

[Vilda]

Not true! You can still put armor mod in them as you please. It will just not show on the item.

Dunno if it's intended or bug. If it's bug it may be fixed in some time.

Can be, haven't met such item personally.

 

Now I would like to see orange gear with augment slot. I've made like 30 orange lvl 50 pants in one session and nothing critted.

page or two back, there are screens of critted weapons. But they are kinda special, because they are allready created filled with mods. So far no confirmation on armors and I fear that they truly cannot crit.

[sixthousand]

Yep. Orange gear is sadly only viable up to the point where you stop levelling and start end game.

 

4 piece sets + critted purple drop schematic craft for select pieces are the way to go for the rest.

 

I've ranted enough about how both pvp and pve sets look like UTTER GARBAGE, but I suppose I'll say that once again.

 

They look like utter garbage.

 

And the only way to be effective endgame, one must disregard any sense of aethetics and subscribe to one designer's questionable artistic vision. =(.

 

I realize that I will sound childish when I'll say this, but I will not be resuming my subscription if the situation is not remedied. I refuse to pay to play the game where my character is forced to be ugly in order to enjoy post story content.

 

of all the inane drivel Ive read on this forum this has to be the winner

[Vilda]

...

I don't get what you mean by "all use the same model", if your model is this rigid you have a serious design issue.

...

When I read my post again, it appears my non-native english took better of me. It lost a bit in translation.

What I meant, was you certainly can make two different types of mods in data model, but it does not make sense for you to do so in current state of game. All mods have the same function, therefore is logical conclusion that all come from the same object (class). When you introduce mod bound to character slot, you are branching that model. Call me old-fashioned, but the simpler and cleaner data model is, the better.

[MareLooke]

I am still mortal, so I can be certainly wrong. But why would any mod need that information as it is now?. Data structure for mod doesn't need more than

{ // pseudocode of java mixed c++

int lvl_requirement

enum position_in_item

enum type_of_bind

class effects

}

nothing more. Data structure is well designed, when you run off the things to delete from it.

 

Because mods more than likely are stored in the same tables as other items (it's what they are after all) and thus (can) have the same properties from a strictly database point of view.

 

When I read my post again, it appears my non-native english took better of me. It lost a bit in translation.

What I meant, was you certainly can make two different types of mods in data model, but it does not make sense for you to do so in current state of game. All mods have the same function, therefore is logical conclusion that all come from the same object (class). When you introduce mod bound to character slot, you are branching that model. Call me old-fashioned, but the simpler and cleaner data model is, the better.

 

You're looking at the data layer through an OO lens, it's more likely that these properties that are common to multiple objects are implemented through database joins than by putting them in the object itself (as columns, which would be a violation of Codd's rules really). In other words instead of using inheritance to decide which restrictions are present on an object they are implemented as properties of said object (which is also how an ORM tool would translate such a link). Inheritance doesn't really translate well to a relational model.

 

I'm not saying this is how it was done, but that seems, to me, the more likely scenario and also the one that makes changing/extending the "gear model" the easiest. In such a scenario adding an additional restriction to an item would be almost trivial.

 

Another fact that points in the direction of an easily extensible/modifiable data model is the fact that they entirely redid the entire mod system in a few weeks during beta greatly reducing the amount of different mod types (which had additional restrictions, so the functionality to do it is definitely already there), if it was so hard to modify that wouldn't have been possible.

 

Either way, we're going way beyond the subject of this thread (and board I guess), I'm also kind of reaching my limit of how much further I can take this discussion without having to resort to drawing diagrams and stuff and I'm not really prepared to take it that far, so I'll just be leaving it at this...

 

Suffice to say that as customers we shouldn't be giving a damn about how it is or can be implemented but only that it gets implemented. Preferably by yesterday! (Hey, that's what customers usually demand )

[bazutti]

Because mods more than likely are stored in the same tables as other items (it's what they are after all) and thus (can) have the same properties from a strictly database point of view.

 

 

 

You're looking at the data layer through an OO lens, it's more likely that these properties that are common to multiple objects are implemented through database joins than by putting them in the object itself (as columns, which would be a violation of Codd's rules really). In other words instead of using inheritance to decide which restrictions are present on an object they are implemented as properties of said object (which is also how an ORM tool would translate such a link). Inheritance doesn't really translate well to a relational model.

 

I'm not saying this is how it was done, but that seems, to me, the more likely scenario and also the one that makes changing/extending the "gear model" the easiest. In such a scenario adding an additional restriction to an item would be almost trivial.

 

Another fact that points in the direction of an easily extensible/modifiable data model is the fact that they entirely redid the entire mod system in a few weeks during beta greatly reducing the amount of different mod types (which had additional restrictions, so the functionality to do it is definitely already there), if it was so hard to modify that wouldn't have been possible.

 

Either way, we're going way beyond the subject of this thread (and board I guess), I'm also kind of reaching my limit of how much further I can take this discussion without having to resort to drawing diagrams and stuff and I'm not really prepared to take it that far, so I'll just be leaving it at this...

 

Suffice to say that as customers we shouldn't be giving a damn about how it is or can be implemented but only that it gets implemented. Preferably by yesterday! (Hey, that's what customers usually demand )

 

Just thought I'd point out that you guys are talking about ways to implement features via code, which there exists a large number of possibilities, and final decisions are either technically decided, or made by coder's preference.

 

Basically, I have a feeling you guys could go in circles for hours.

[Vilda]

You're looking at the data layer through an OO lens, it's more likely that these properties that are common to multiple objects are implemented through database joins than by putting them in the object itself (as columns, which would be a violation of Codd's rules really). ...

I see your point, we are crashing at different views of implementation. I understand the validity of database point of view, but my inner "code purist" screams in rage at those gaping holes in that damn big table

 

 

Suffice to say that as customers we shouldn't be giving a damn about how it is or can be implemented but only that it gets implemented. Preferably by yesterday! (Hey, that's what customers usually demand )

Basically, I have a feeling you guys could go in circles for hours.

 

Yeah, let's go back to playing and trying to craft that orange crit. Or hey, lets write our own MMO.

[MareLooke]

Just thought I'd point out that you guys are talking about ways to implement features via code, which there exists a large number of possibilities, and final decisions are either technically decided, or made by coder's preference.

 

Basically, I have a feeling you guys could go in circles for hours.

 

Yeah we could, there are many ways to implement this. I guess the basic point that started this discussion is that adding the feature I proposed (and which was proposed many times before by me and others) would not necessarily be hard from a technical perspective. Things got a tad out of hand from there, geeks eh

 

At least it didn't degenerate into a flamewar

[Vestras]

If accurate and well produced, I will be one happy player

[RpTheHotrod]

I say this whole mess is just that, a mess.

 

1. Allow custom look slots (but the custom look must match the type that you actually have equipped. For example, if you have a heavy armor piece on, the custom look piece must also be heavy).

 

2. Do away with the orange item system

 

3. Remove armoring/barrel slots. End result are good and usable items that have a benefit to be enhanced further as a bonus.

 

4. Compensate armortech by making viable recipes available to them.

 

5. Compensate armstech and cyber tech to make up for remove of armoring/barrel mods

[Vilda]

Also, found the original of said post about planned changes:

Some bit of interesting info:

The current situation with end game gear and item modifications isn’t final and, in fact, many community members like yourself have correctly guessed at what our plans to correct the current design are.

 

Since this is a fairly important issue to many players, let me disclose more details about what is currently in the work regarding purple items and mods:

 

- All partially moddable purple items will be made fully moddable again, allowing the removal of the armoring, hilt and barrel.

 

- The set bonus of end gear purples (PVP and PVE) will be transferable to custom items.

 

- Some item modifications will be restricted to a certain item type. For example, some item modifications will only fit on helmets, while other will only fit on chests, etc.

 

As usual, the caveats about unfinished work apply, but this should give you and the community a very good idea of our intentions. We are serious about making custom gear an entirely valid alternative to end game gear and we support the players’ ability to customize their appearance all the way to (and including) end game.