Emulating Foreshadow's Costume Mechanic

First off; costume (top,bottom) is cool; if we don't have it then we need it .

(Foreshadow is the Trainer in the Hollows)

Secondly, his 'off set'/one-sided pieces on both his shoulder and glove...

This is something that I would like to be able to do with my toons; have separate Right Glove/Left Glove, Right Shoulder/Left Shoulder (maybe even Right Boot/Left Boot) selection in the Character Creator.

---

Apparently, I play "City of Shakespeare"
*Arc #95278-Gathering the Four Winds -3 step arc; challenging - 5 Ratings/3 Stars (still working out the kinks)
*Arc #177826-Lights, Camera, Scream! - 3 step arc, camp horror; try out in 1st person POV - 35 Ratings/4 Stars

Well first off the Devs always tell us that unique NPC costume items will likely always remain unique because that's what supposedly makes them "special" or somesuch. I understand the concept but I also find myself wishing that wasn't the case.

But as to your idea of having separate left and right shoulders, gloves and boots I wouldn't be surprised to see that happen here eventually. As I understand it that "other" superhero MMO coming out in a month is going to allow for that so it would seem reasonable that this game would want to support it too.

---

Loth 50 Fire/Rad Controller [1392 Badges] [300 non-AE Souvenirs]
Ryver 50 Ele� Blaster [1392 Badges]
Silandra 50 Peacebringer [1138 Badges] [No Redside Badges]
--{=====> Virtue ♀

[ QUOTE ]
First off; costume (top,bottom) is cool; if we don't have it then we need it .

(Foreshadow is the Trainer in the Hollows)

Secondly, his 'off set'/one-sided pieces on both his shoulder and glove...

This is something that I would like to be able to do with my toons; have separate Right Glove/Left Glove, Right Shoulder/Left Shoulder (maybe even Right Boot/Left Boot) selection in the Character Creator.

[/ QUOTE ]

The challenge is that there's just one slot identifier for "boots" and to have left/right boot, for example, you'd need to use two slot identifiers. You also have a finite number of item identifiers within each slot, so you couldn't realistically just put TONS of combos into one slot (like "pegleg+rubberboot," "pegleg+monstrous" etc)

The devs have noted in the past that there's a hard-coded number of slots possible (due to how it's encoded with all the other data for swift and accurate communication) and at the moment, IIRC, we're down to 1 more "unused" slot and they want to make it count.

---

[ QUOTE ]
[ QUOTE ]
First off; costume (top,bottom) is cool; if we don't have it then we need it .

(Foreshadow is the Trainer in the Hollows)

Secondly, his 'off set'/one-sided pieces on both his shoulder and glove...

This is something that I would like to be able to do with my toons; have separate Right Glove/Left Glove, Right Shoulder/Left Shoulder (maybe even Right Boot/Left Boot) selection in the Character Creator.

[/ QUOTE ]

The challenge is that there's just one slot identifier for "boots" and to have left/right boot, for example, you'd need to use two slot identifiers. You also have a finite number of item identifiers within each slot, so you couldn't realistically just put TONS of combos into one slot (like "pegleg+rubberboot," "pegleg+monstrous" etc)

The devs have noted in the past that there's a hard-coded number of slots possible (due to how it's encoded with all the other data for swift and accurate communication) and at the moment, IIRC, we're down to 1 more "unused" slot and they want to make it count.

[/ QUOTE ]
Having only one more hardwired data field "slot" for costume data sounds like a typical software Dev "hand-wave" excuse to me. I should know - I've been a software engineer for almost 20 years now. Think of it this way: Somehow our Devs found the space to transmit all the new custom color info for the I16 power customization adequately enough.

I'm not trying to suggest adding the capability to have separate left and right costumes items would be trivial to do or even that it's guaranteed to happen. But I -am- suggesting that if it ever became a big enough priority that the Devs would be capable of finding a way to make it work even if that meant changing other more far reaching things like general network message formats.

---

Loth 50 Fire/Rad Controller [1392 Badges] [300 non-AE Souvenirs]
Ryver 50 Ele� Blaster [1392 Badges]
Silandra 50 Peacebringer [1138 Badges] [No Redside Badges]
--{=====> Virtue ♀

I don't have 20 years (quite yet) but pretty close, and I agree completely. Hardcoding is done almost always when something has to go out NOW-NOW-NOW! and is very unfortunately whenever it happens. It does make it a problem later on, but not remotely an insurmountable problem. As Lothic mentioned, I16 is proof-positive that the number of data slots is liquid. Furthermore, there actually is a pretty simple fix that would cover all future modifications and vastly increase the available space for the AE files. Mind you, I said "simple", not "easy". It wouldn't be easy at all. In fact it would be a pretty major undertaking, but it is simple.

Right now the file data for all character descriptions are in essence xml files. They're ASCII text files with custom meta data detailing the fields (category name, sub-category name, field name, value). Since each value has a limited number of options, and there are a limited number of values, that could actually be done in a binary fashion so that each item is placed in a particular location and given a specific range of values. You'd wind up with something that looked like an extremely long GUID but with less than, for instance, 5k you could define any character this game could possible create.

Again, though, the problem is not complexity. The problem is difficulty. I'd be very surprised to hear that the developers hadn't already considered a change to a binary serialization of the character descriptions, especially during their brainstorming sessions for MA, but dismissed it due to how integral the current system is to everything they do.

As to the original idea, I agree with Lothic when she (assuming based on the avatar) suggests that it's likely this will come up in the future, but I wouldn't look for it any time soon.

Robin

---

--If we can have huge sig images, why can we have only five lines of text?
--...faceplanting like a Defender pulling an AV (Nalrok_AthZim)

[ QUOTE ]
[ QUOTE ]
[ QUOTE ]
First off; costume (top,bottom) is cool; if we don't have it then we need it .

(Foreshadow is the Trainer in the Hollows)

Secondly, his 'off set'/one-sided pieces on both his shoulder and glove...

This is something that I would like to be able to do with my toons; have separate Right Glove/Left Glove, Right Shoulder/Left Shoulder (maybe even Right Boot/Left Boot) selection in the Character Creator.

[/ QUOTE ]

The challenge is that there's just one slot identifier for "boots" and to have left/right boot, for example, you'd need to use two slot identifiers. You also have a finite number of item identifiers within each slot, so you couldn't realistically just put TONS of combos into one slot (like "pegleg+rubberboot," "pegleg+monstrous" etc)

The devs have noted in the past that there's a hard-coded number of slots possible (due to how it's encoded with all the other data for swift and accurate communication) and at the moment, IIRC, we're down to 1 more "unused" slot and they want to make it count.

[/ QUOTE ]
Having only one more hardwired data field "slot" for costume data sounds like a typical software Dev "hand-wave" excuse to me. I should know - I've been a software engineer for almost 20 years now. Think of it this way: Somehow our Devs found the space to transmit all the new custom color info for the I16 power customization adequately enough.

I'm not trying to suggest adding the capability to have separate left and right costumes items would be trivial to do or even that it's guaranteed to happen. But I -am- suggesting that if it ever became a big enough priority that the Devs would be capable of finding a way to make it work even if that meant changing other more far reaching things like general network message formats.

[/ QUOTE ]

I'm an engineer too- specialize in antiquated systems at the moment- and I've studied how MMO devs compress data and encode packets to get the most out of what can be a very tight bandwidth. Particularly during CoH's development period, the MMO industry focused on minimizing bandwidth to a near-obsession. A single byte may be divided up between several purposes, and the code that accesses each of these may or may not be easy to track down and point elsewhere.

And remember, we're talking about a 9-year-old codebase in an industry that really didn't have much need for code sustainability. Heck, just go back 9 years and look at the "conventional" code standards back then, and games tended to focus on "expedience" over sustainability & maintainability.

When you think of it in THAT context, expanding to add more slots can be a considerable challenge in something this complex.

---

[ QUOTE ]
I don't have 20 years (quite yet) but pretty close, and I agree completely. Hardcoding is done almost always when something has to go out NOW-NOW-NOW! and is very unfortunately whenever it happens. It does make it a problem later on, but not remotely an insurmountable problem. As Lothic mentioned, I16 is proof-positive that the number of data slots is liquid. Furthermore, there actually is a pretty simple fix that would cover all future modifications and vastly increase the available space for the AE files. Mind you, I said "simple", not "easy". It wouldn't be easy at all. In fact it would be a pretty major undertaking, but it is simple.

Right now the file data for all character descriptions are in essence xml files. They're ASCII text files with custom meta data detailing the fields (category name, sub-category name, field name, value). Since each value has a limited number of options, and there are a limited number of values, that could actually be done in a binary fashion so that each item is placed in a particular location and given a specific range of values. You'd wind up with something that looked like an extremely long GUID but with less than, for instance, 5k you could define any character this game could possible create.

Again, though, the problem is not complexity. The problem is difficulty. I'd be very surprised to hear that the developers hadn't already considered a change to a binary serialization of the character descriptions, especially during their brainstorming sessions for MA, but dismissed it due to how integral the current system is to everything they do.

As to the original idea, I agree with Lothic when she (assuming based on the avatar) suggests that it's likely this will come up in the future, but I wouldn't look for it any time soon.

Robin

[/ QUOTE ]

Don't confuse the XML files- the way the data can be understood and stored here- with the data packet encoding that transmits that data. THAT is where the limitations are the most significant. What the code does with the data once it's on your PC is another issue.

---

I'm not (I'd likely get fired for making that kind of a mistake since it's what I do for a living). There is a significant discrepancy, however, between what is being transfered and what could be transfered. Their focus on efficiency is primarily related to active, as opposed to passive, data. By that I mean things that go on during combat and communication. Building changes, character descriptions, event triggers and such that gets sent once and then is just indicated by a place-holder until a change is required are seldom optimized to the same degree. They really don't need to be for something like this. Even the note I made is pretty irrelevant except as a way to help players store more custom critter definition on the server.

To really notice the difference look at the huge compilation differences between the piggs and the character/MA files. Data that gets pushed once in a while stays bulk for ease of access/use because conversion time is more important than throughput while data that gets passed repeatedly and during massive traffic is more important to optimize for throughput than conversion. The idea is to offload as much of the processor intensive activity to the clients. It's the same in any EDI scenario.

Regardless of the details, I think we're saying the same thing about the point. It'd be a huge undertaking to change the basic method of compression and isn't likely to happen any time soon.

Robin

---

--If we can have huge sig images, why can we have only five lines of text?
--...faceplanting like a Defender pulling an AV (Nalrok_AthZim)