Well, one one hand, you're not wrong. On the other... I don't think any of us know what's really going on under the hood, and it is possible there's factors they haven't explained.

But, yeah, even just giving us a much more limited dye set would at least mean we wouldn't be staring at bright red swords everywhere.

phaneub17_ESO wrote: »

Well if you look at weapons of Endurance, Agility, and Willpower they have the weapon color of Iron or Steel regardless of what level you have them, even the 160cp ones. Crafted weapons I can understand keeping their fixed colors, but I don't see why other dropped weapons can't have different weapon tints to specific tiers of material at the least.

For what it's worth, crafted glass and Stahlrim weapons also lack the red. Technically, Stahlrim have some material toned wirework at the base of the grip, but still.

Pumping out cash shop items seems to be less labour intense i assume...

At least with trans-mog we can change our weapons to motifs that aren't red at CP160.

I was think this the other day. Add some extra use to those lower CP mats.

If we have a transmog system released, this would be redundant (assuming it works how evetybody wants it to!) - you can just use a lower level weapon's appearance

paulsimonps wrote: »

Different levels of weapons already have different colors, I really don't think it could be that much harder to let us adjust said color.

https://forums.elderscrollsonline.com/en/discussion/339727/weapon-dyes-with-examples#latest

Examples of this in the above linked thread.

That is essentially what transmog is all about, if they do it that way. If they allow you to go back and set it to the lower level version of the weapon, you can change it to any of those weapon styles. It changes the color, along with everything else.

As for adjusting said color independently to anything you want, even if it is just those colors you referenced, based on what was said by ZOS, that is much harder.

The answer is actually it shouldn't be difficult.

In fact with any sort of intelligent design all the attributes are sourced from tables, no hard-coding involved.

The problems occur when programming short cuts are taken or assumptions are made. Then things can still be simple to resolve but need some actual effort to realise or they can be a real pig needing significant work.

Any customer support person will be told to say its difficult even it is not simply because the other way around would end up with us making even more complaints.

starkerealm wrote: »

Fine, no big deal.

In ESO, you need to see everyone's weapons. That means, if you tried to kludge it like you would in Skyrim, you'd need to load and display texture data for everyone who wanted a unique looking sword. Probably not an issue in lower pop PvE areas, but, Cyrodiil? Yeah, that sounds like fun.

You really don't understand how things work, do you?

Retexturing a single item across a client is not hard. In the example you provided, that was a modder taking the place of a developer in this instance. (Both are doing the same thing, with similar tools. The modder is changing the base game to display his texture... the developer in this instance would be changing the base game texture to the desired texture.) Nobody is asking for user-created content to be inserted into the game here.

Each item in the game, as it is currently, likely has a data structure similar to this

String name // the name of the object. Likely set in the object constructor near the end
String weapon_type // used to determine what weapon skills and number of hands one can have applied to the weapon
int level // level required to equip the object. Likely used to determine what Material overlay is applied as well as the damage
int level_CP // cp required to equip the object. Likely used to determine what Material overlay is applied, overwrites the level.
int quality // white-green-blue-gold. used for UI hooks and to determine weapon_damage and durability values
int weapon_damage // likely determined in the constructor, but stored in the object so it is easily readable.
int max_durability // maximum durability value for the weapon. Determined by quality and type. Not used for onhit actions with poisons equip
int current_durability //current durability value for the weapon. At 0 this weapon has no enchantment charges. Not used for onhit actions with poisons equipped.

Trait trait // links over to a weapon trait, which can be called by external objects. May be null
Enchantment enchantment// links over to another object, similar to this one for the enchantment data object. Ignored for onhit actions with poisons equipped.
SetBonus setbonus //this object is linked over .Can be null for crafted weapons
Texture motif_style //this is the display texture. in the weapon constructor this may be set by the setbonus.

Changing motifs, from a coding standpoint, is fairly easy. Adding a function to change motif_style from one style to another would be a handful of lines. (slightly more once you start adding exception handling, sanity checking, and potential bugs. Still not terribly much.)

Changing weapon colors, however, would likely result in needing to dramatically restructure the weapon datum and adding in a Materials overlay variable (which does increase database overhead, since every new variable needs to apply to EVERY weapon in the game). That said, it's very likely that the Materials objects already exist, so once you restructure the weapon datum you'd be mostly home free... after a few hours of testing, explaining why you want it implemented by your boss, more testing, QA, bugfinding, quashing bugs and then dealing with the inevitable end-user complaints.

Enemy-of-Coldharbour wrote: »

I think the main issue is time. There are nowhere near as many shields in the game as there are different weapons. So, to code each weapon for dyeing would be a huge undertaking.

I think the dye colors was already used for differentiating level on armor so it was pretty easy to give player access.
If this is not present on weapons, not database but overlay on 3d model. This would require redesigning all weapons.
Yes its an mask on top like tatoos, dirt / damage and Khajiit fur.
Vampire is one overlay and probably replace others.

lordrichter wrote: »

randomkeyhits wrote: »

The answer is actually it shouldn't be difficult.

In fact with any sort of intelligent design all the attributes are sourced from tables, no hard-coding involved.

The problems occur when programming short cuts are taken or assumptions are made. Then things can still be simple to resolve but need some actual effort to realise or they can be a real pig needing significant work.

Any customer support person will be told to say its difficult even it is not simply because the other way around would end up with us making even more complaints.

When designing the game, the work that they do is based upon the features that they need in the game at the moment, along with any features they do not immediately need, but know they will need later in development and have a design ready. They don't just throw in features to the game based on "what if" for a future capability that does not exist and has not been discussed. This can lead to all sorts of issues later on, especially when the feature is finally implemented, but it is different than what they "guessed" months or years ago. Prep work that is wrong, and has to be reworked, can cost more to bring up to current than it would to implement it new, and if they don't do that, could limit the implementation to an older design.

It is best to do the work for what is needed and deal with expansion to that when the time comes, rather than to try to guess what someone might want to do years later and provide for it at the onset.

In this case, there were probably no design points available for coloring weapons at the time when the weapons were being designed. Now, to go back and add that in costs time and effort, which translates to money. Were it not for transmog, they might do it, but transmog is a more general solution. Since they are implementing it for more than just weapons, it will probably cost them less than a dye system for weapons.

I'll stand by my statement thanks.

Good design puts complexity where it is controllable and is easily abstracted and that rarely if ever means hard coding.

Its not whether or not a feature is added at the beginning or not, its whether the design properly allows for the adding of new features.

A good modular design can more easily accommodate new requirements though regardless of quality sometimes a required feature isn't really possible without significant re-working.

No guessing, no just in case stuff, no what ifs, just solid sensible programming.

The question really is did they follow good principles or not. If not then yeah, everything is "hard"