Naomi

I think it's a great idea, but taking into account a lot of what has been pointed out, I think in the end it would be best served pitched as a whole new Primary powerset on its own, which I think has been asked for in the past as some kind of power glove set. The way powersets are named, designed and customized in CoH makes enabling this level of customization a bit of a challenge without re-designing the powers system from the ground up. Currently, if we did it the way you're asking, you would be picking a rifle weapon in the costume screen, and then presumably selecting "Beam Blast" in the power customization screen per power. This animation and FX wouldn't let you customize your glove if there was one (and I'm pretty sure people would ask for that), so you would have each glove style listed as one of the customization options per power, which would be a quirky way of doing it and not really what power customization was intended for.

The way it's implemented elsewhere isn't the way Homecoming might do it, for reasons of security, maintainability, performance, or design reasons. I'm being intentionally vague here because I'm not out to publicly criticize what other people are doing, or how they did it, however constructive and well meaning it might be. Sometimes doing it the preferred way just takes longer. I don't think mastermind pet customization is a closed book at all.

Well just to be absolutely clear, the implication of what I meant was that it's about not wanting to hurt other people by way of disappointing them down the road rather than guilt. I don't require a safe space and I'm pretty thick skinned enough to handle criticism harsher than you'd probably find here, it's just that if I can avoid it all together, it's easier not to say anything (if its something that is allowed to be talked about). There's also a distinction there between each dev vs the whole team, which Galaxy has some solid points on. My guess is that marketing and money play a huge role in those kinds of failures. Most artists or developers I read about in those scenarios all seem to have one thing in common, and that is the wish that they had more time to polish. Again I really only speak for myself when possible, because if I were working on powers, which are probably the most hyper critical changes you can make, there are things I would feel completely differently about. I'm a little tired at the moment to address stuff I missed, but you have interesting and valid questions.

Commercial or not, what Galaxy is saying is we'll never hear the end of it, which I would say is probably true from past observation and of other gaming communities, despite how many reasonable people there might be who would be understanding. The disappointment can end up feeding negative sentiments over time of broken promises. (There is a very particular studio out there that has absolutely no problem over promising and under delivering because they can afford to, and last I checked, their forums were deleted because it turned into a uselessly toxic cesspool of those who felt betrayed and lied to, vs the white knighting. Granted, they are the epitome of this phenomenon and a bit of a far fetched example, but it does start somewhere and game developers in general I think have wised up.) For me personally, I've been on the receiving and giving end, and I feel guilty more so than annoyed when people bring something up from the past that wasn't even a promise so much as a casual, "Here's what I'm working on" only for it to have been shelved indefinitely. There would also be the need to constantly explain why one thing or another didn't happen. I'm also assuming you're talking about unreleased features or things in the early stages. I feel like its better to confine it to ones self rather than the whole community at large. I actually hit all kinds of walls unexpectedly (currently facing one, actually) and sometimes need to put it on the back burner to clear my head.. if I were to instead give people what they want ahead of time, then I face a heavy burden of the stress of failure if I cant get it done in a reasonable amount of time or get the quality I'm looking for within that time frame. Holiday content is a good example of this. They are things I enjoy tremendously and would love to work on, but last year I knew I had too little time to do Halloween or Winter stuff on schedule so, bases didn't get presents and trees, and all the other things I know people ask for every year. I'm not going to disagree here because I would want to know, too, and while you might feel that way, there's probably someone out there who absolutely has to have that feature above anything else and might consistently bring it up repeatedly, demanding it be given a second look, even if the reasoning was something monumentally unexpected. This person might also be completely non-entitled and just politely passionate (which I've seen), which makes it all the more worse. If you multiply that by everything on everyone's pet project list, we'd probably get completely toasted. These are just my personal views though, but I don't think anyone enjoys keeping people in the dark intentionally, unless it's to genuinely surprise them. For a lot of the original poster's suggestions, like the mastermind pet customization and things, there are legal and technical issues at play that may not seem immediately obvious, but they're there.

I think if you asked everyone on the team this question, you would get as many different answers. I find it difficult to answer personally, without it being married or grounded in actual context. 'Feasibility' with respect to time constraints plays a huge role in whether something is even considered from the get go, regardless of whether it's a good idea or not. After that, there are all sorts of variables and consequences to consider (which can be completely different depending on your role), which are absent when trying to answer the question in a general sense. Personally, I think City of Heroes is a lot of different things, to a lot of different people. For the original developers, it was their livelihood, part of their professional legacy and for some, their passion. For the players, it's everything from a comic book game, a story telling medium, an escape from day to day reality.. it's so many things. Regardless of what it means to anyone individually, I think the importance of preserving its original intent can't be overstated. What worries me the most is the thought that any of its original magic could be taken away by radical design and story changes. I think I can say with confidence (and it's been said before) that most of the team holds the original developers in high regard. The last thing any of us want to do is to take a sledgehammer to their work (some of the internals being an exception..). That said, it's also not lost on me that Homecoming is just one interpretation of where City of Heroes is going post-shutdown. The game itself is also in the unique position, for better or worse, that the state in which it had last been is out there for anyone to continue with their own interpretation, (which is happening), and in a way a rightfully fitting "ending" of the 'choose your own adventure' aspect of the game's story telling design as a whole. The nature of this being an unpaid, volunteer effort which isn't unique to Homecoming, is that there will always be occasional periods where members of the team are just busy with life. Some of us rely on each other's skill set to accomplish or finish certain tasks, and it can be a balancing act to find the right time to work on or discuss something. Unlike live, it's not very realistic to expect team members to adhere to strict deadlines and other things you might find in a development studio, so while there is a roadmap of where we hope to be going, it's one small step at a time. Occasionally there's a flurry of activity, which can be fun, but also exhausting. What should take a day, or hours or minutes, can occasionally be a week long project. If anyone ever feels left in the dark, the only reason it's done intentionally that I've ever seen is to avoid disappointing anyone if things take a different turn and we can't deliver. To think it's because we don't want to hear anyone's feedback is a mistake, as we are genuinely interested in constructive criticism. The community itself is a major part of the game's legacy, and your trust and patience means a lot to everyone on board. I don't have anything to do with powers, but what I find the most interesting as a player, is being able to make a clear choice with playing a tanker, a blaster, or a jack of all trades. Feeling powerful is certainly key if you're a superhero, but what also makes them just as interesting to me are their weaknesses. Inherent mez protection for every AT isn't something I would be comfortable supporting for that reason, as it takes away an interesting choice for the player.

All the time. It's actually been this way even on live for as long as I can remember. There are also some other long standing global friends list bugs like remaining hidden to others even when you're not (/hideall followed by /unhideall tends to fix it).

Would you be able to use MS paint to highlight the v-shape?

A fix for this and some other reported costume bugs is in the pipeline (so to speak).

First of all, you implied you were asking for tanktops to be ported to HUGE models from MALE models. I do not know which patterns specifically you wanted, but since I'm aware HUGE doesn't have every MALE part, I was willing to look at spending some time porting them over. For the record, MALE and HUGE do have tanktops, which is the only thing you specified. After asking you for a list, your response is a blurry screen capture of a FEMALE corset (Hearts Plus) on a MALE costume (not HUGE), which isn't what you originally asked for at all. Costume patterns are inherently separated into three body types for technical reasons explained repeatedly here and elsewhere. Texture coordinates are not the same, nor are the underlying base textures. Reworking these to adhere to a standard present throughout the game as well as my own isn't cheap on time. Regarding my posted screenshots to give you a visual example for why FEM -> MALE texture ports are different, I had intended to use Heart Plus, but at a passing glance of your screenshot, I hadn't realized it was the wrong one, which is my mistake. Regardless, it's irrelevant which part I chose, as 100% of the female patterns exhibit the issues I circled in yellow, the most consistent being that the underlying texture behind the pattern is the female base skin texture. Anyone can test and preview patterns like this by copying the Texture1 and Texture2 name from a female .costume file, and pasting it into a male/huge .costume file on the appropriate part (or any part for that matter if you just want to have fun trying different textures in the game on costumes), and clicking Load costume after you save it. I also don't understand the apparent hostility.

Responding to all of this in-depth would probably be better in a separate write-up elsewhere on the forums, but the shorter version is that after reading that first thread, @Jimmy pretty much covered how I also feel, and I would just be repeating "but we actually want to put the time into doing it right instead of just mass-enabling stuff and hoping for the best". For every topic of players passing on issues of quality control (because they think the issue is minor), there are topics such as the following: https://forums.homecomingservers.com/topic/25017-color-mapping-mismatch-bodysuit-muscled-matte-f-costume-piece/ or direct conversations with people expressing their concerns related to QA. There's also no one-size-fits-all answer to every item on a wish list. A devonly part is devonly for a reason, but they're not all the same reason. It might not even be a visual issue at all. Re: hyperkreator: See "mass enabling things".. tons of problems behind the scenes. This isn't the same dress, and something I quickly threw together, but like the above post, it's not showing you the whole picture of what's wrong (ignoring the fact the second of the two is not a tank top and has nothing to do with what was asked for, my point about coordinates still stands): If I have a hand in any modification, change, addition or bug fix, these results would simply not be acceptable to me (on a personal level, and not by any directive given to me or that I have given to anyone else). It's not as easy as flipping a switch sometimes to meet the height of the bar, and often that comes down to time and the work involved. What Jimmy means when he says "doing it right" might be the point of contention you'd like more clarity on, but like I mentioned, it comes down to having to address every item individually (for any feature in the whole game, not just costume parts).

There's no such thing as a "gender lock" really. Costume geometry and their corresponding texture coordinates are inherently different across body types. This means texture stretching, warping or misalignment in a lot of cases. This is less of an issue with Male and Huge compatibility, but still an issue. I don't think there's anyone who would disagree with Huge having access to the full set of Male parts if it were that simple. The reason they've always lagged behind though, is a reason of economics. Huge parts aren't simply male parts being automatically conformed to 'Huge' - they are separate ports done by hand. If there is a list of patterns (or even whole parts, as long as the lists are separated) from Male you would like to see looked at for Huge, I would highly encourage making a separate thread with them. I'm also not sure which tank tops you were referring to, but there is Cybertech 1 available on both Male and Huge.

This used to be a devonly part, and I'm not sure why it was added as a pattern when it should be a texture, but in either case, there's no amount of flipping, mirroring or tiling (in any direction) that would fix the seam (I tested it).

A majority of the tables. The "surface" for Surface placement is below the top of the table. in some cases, the Surface placement seems to be place the item to be placed against the bottom of the table. These aren't broken and are working as intended. You need to press F1 a few times to turn the grid off completely before you surface snap, as the grid is constraining the allowed position relative to the polygon you are targeting. In the case of say, Glass Table 2, the height of it's surface is a non-grid divisible value of like 1.87, whereas the tables that work with the grid still on have heights of some position of *.0, *.5 *.25. A lot of the old items are "larger than life" and were intentionally modeled this way because back then you were limited to 1.0 ft increments and little else.

I like the idea of adding more depth to regular gameplay, so while it's probably a technical nightmare, I wouldn't mind having a player's alignment changed to hostile for a period of time (other players can freely attack them) if they assault or 'harass' civilians.. which could either be non-defeatable (someone you can stomp kick around while they try to run away, yelling different things) or defeatable after some abuse (enough you don't do it accidentally), with both instances resulting in different yet-to-be-implemented-consequence-mechanics. Ideally, if someone is marked hostile, attacking the player (and only when you decide to engage) means they can then attack you in return. The target tab thing Legree pointed out would bother me though, as well as the almost guaranteed possibility that you would be attacking every NPC you tried to help from a purse snatching with AoE attacks.

I think I would be okay with removing tailors from most trainers, primarily because we have them in bases now. I've never had a need to use the Surgeon (Supertailor) but I like to think the distinction is now canon between a Facemaker and Surgeon, so, rather than replacing all Facemakers, I would perhaps suggest putting some Surgeons in some of the hospitals. Redside, they could be placed outside in the back of the building, black market style. I also wouldn't object to an extra fee (if that's even possible on a per-NPC basis) for the hospital surgeons to account for their accessibility, which probably isn't a popular opinion, but I feel like it could help balance the trade off of tailors being less trafficked, since they are pretty iconic to CoH.

Some of the requested items haven't been included intentionally, so maybe this can shed some light on why: - Alphabets: Even under their own tab, they can grow unwieldy, since each font consists of 26+ items, or 52+ if we're including an upper & lowercase set for it. I think players would naturally want more styles going forward (neon sign letters, and so forth), so it can quickly add up. There's also some other considerations like kerning, poly-count, whether a font is done as planes + alpha or real geometry, which set of sizes is most ideal, and so on. Ultimately, fonts would be better served with a special section where you could select a style, tint and scale, type something in and have those letters "grouped" as 1 selectable word object that you could then place as a regular object. Regarding kerning and letter placement, it can be very time consuming and annoying when you misalign them when you're trying to center text somewhere. - Lights: We could add vertex lights by themselves as objects, which would be great for outside of the plot where base lights don't exist, but they would currently be static.. so like the alphabets, a decision on the available colors, brightness and fall-off radius would have to be decided in advance. If a color and fall-off selector UI like in the map editor were added for a single light object, that would be much more ideal. - Tintable "walls" and basic shapes (this includes glass windows and stairs, etc): The thing about these is, they require extra planning. Once you set out to make a set of modular components, you can't really go back and make changes once people start using them in their base (for a lot of obvious reasons). Planning the right sizes, corners, floor and ceiling styles (for any imaginable interior and exterior themed set) is pretty important, as it will dictate what can and can't be easily used and put together with other sets. Ideally, for the most bang for your buck, you would really want to favor compatibility here with other themed sets. This is probably a really wordy way of explaining that you're basically trying to design objects as if they were going to be used to build the zones in the game, which a lot of the older zones are all put together from (the environment and buildings).. and while the map editor has more advanced controls, by and large, most of the bulk of what you make up a zone with fits very well together for the map editors to use - it also makes zones look much more consistent and clean. I know a few basic shapes is all that's really being asked for, but I wouldn't feel that good about leaving the bar that low and calling it a day. On top of this, like the alphabets and lights, a texture swap selector for a set of parts would allow us to re-use the same geometry of a "set" to add more variety, without spamming the item list with 10 variations of "8ft Corner Wall 1", "10 ft Corner Wall 1" and so on. Speaking of planning for these, things like wall height (a possible point of community debate) and poly-count could make or break the whole thing. Modular parts like this actually require that most of the set have the same poly density as the smallest component because of the way vertex lighting works in bases. Anyone who's tried to put a large brick plate surface down next to a small brick plate knows that the lighting doesn't play nice, despite the fact they're otherwise seamless. This is because the large brick plate has the same number of polys, just larger in size. You would have to subdivide the large plate into 16 just so the lighting is compatible with the smaller parts that are designed to fit together with it. Overall, you'd have much higher poly-count bases that made use of modular sets. I wouldn't really feel comfortable even starting the planning phase until some solid performance testing was done beforehand. It's possible that high density meshes everywhere will cripple the editor every time the base flickers when it tries to re-light everything. Overall, these all require code-changes. I would venture to say they are non-radical code changes, as in, within potential reach in the future, which means that if you got the basics now, there's the potential that all of it becomes legacy content no one uses anymore in the future. My personal wish list would be, aside from the above features: - Fixing item drift (I have never built outside of the plot for this reason alone, aside from lighting limitations) - Keyword filtering per object for the search box, rather than just on name. (typing "table" currently shows all objects that have the word "tintable" in them). - Interactive objects in bases (turning lights on and off, playing music, opening and closing doors). Basically a script to replace one object with another when it's clicked on. Persistence saving would be done as though the user had edited the base themselves. - The option to hide all the base walls and floors - Larger horizontal editing area 2x, 3x or 4x the size of the current max sized plot, basically. - Item grouping as player-renamable sub-objects (this is one reason I've avoided working on holiday decorations.. putting a ton of them up in the base every year and deleting them is a slog. If you could save a group like an AE arc and load them up that would be amazing) - Base saving / loading / backing up like costume slots (if debate around base theft and technical issues aside involving item storage were resolved). - Personal housing per character, or the ability to join multiple groups to include the one you are an owner of.

I believe the issue here is that the breast plate and collar piece (one object) is in the Cranium geo, which is where the ear options are, as well as using the Cranium bodypart. The costume editor only allows you to use one costume part per bodypart typically, so it's automatically clearing the other option. I'll see if I can get a fix for this soon, thanks for pointing this out.

If I do end up doing the stockings, I'll try and see about including that. I just did some testing with it and it's a pretty versatile alternative to Bikini 2.

These were already on my TODO list, but just so you're aware, costume parts that show any tintable skin can only have 1 tintable color and can't accept sub-patterns. You can however, mix the intensity of the tintable color and/or have non-tintable colors to work with. Most often, these would be black and white, which tends to lend itself well for certain types of costume options.

My "tldr" opinion on this is that I think AI upscaling is more of a novelty that isn't quite there yet rather than something you would realistically want to pursue as a real feature to support and maintain. I can't remember off hand if texture mods let you play with changing the image dimensions as well, but if they do, something like upscaling would be (just my opinion) better released as an optional and occasionally updated pack of some kind from the community, rather than distributed alongside patches or as piggs (texture_library itself is currently around 5 GB.. so depending on how many and how large we're talking, that's a lot for some folks to carry around if they happen to not want to use the feature.) The biggest downside to upscaling is that no matter your algorithm, you aren't actually adding any new detail to the extra resolution being utilized. It's a cheap and effective way of imitating quality by allowing you to see the same existing detail closer to the camera / at higher resolution(s), which is really only half of the equation when it comes to visual quality. It's kind of like re-sizing an image and applying sharpening filters.. unless you add new unique detail, it becomes exponentially wasteful, or in other words, you get diminishing returns. Granted the algorithms in question (some better than others) try to add this detail, it's done purely based on the information already present in the image rather than something unique. Skin, fur, hair, straight crisp lines and details tend to suffer the most. The photos shown on post #894 in this link highlight the effect pretty well. What should be a floor grate is clearly a vague blurry guess at its higher resolution shape. So in conclusion, while it still might look better than nothing, you're also not getting the most bang for your buck v.s. hand authored. Doing this for legacy games like Doom and others (CoH probably included if we're going based off age) is interesting, but it will always carry some burden of extra memory bloat (or CPU/GPU processing if we're talking about doing it in real time for every texture). Most textures (according to NVIDIA) can be as high as ~30% wasteful already, and with upscaling, we're also not just talking about the (e.g.) 512x512 main surface texture, but all of the other supporting ones, in most cases the normal map that would also be doubled in resolution. And so at this point we would have to scratch our heads at which supporting textures make any noticeable difference to include if we didn't outright decide on doing them all in bulk because we decide doing it selectively is taking up too much time (and it would take an enormous amount of time doing it selectively, because as far as CoH's engine is concerned, there's no instant preview of inspecting different texture changes (which you can occasionally get away with, but by and large, most of the time it requires a client restart if it doesn't crash the client or corrupt the surface.) If we ignore the supporting maps entirely because we decide just the main texture is "good enough" then the same selective problem exists, since not all textures in the game are equal in terms of their fidelity or the way they're used and mapped. Some are mirrored and rely on a perfect seam that could become distorted (most costume parts) and tons of objects in the game. Some are also low resolution but are designed to tile favorably (in fact most textures designed to tile don't need to be upscaled or would benefit the worst since they are designed to repeat). I'd say the time in selecting and deciding which get treatment alone is significant enough that it could be better spent elsewhere (hence it being better suited as a community crowd sourced thing), though in hypothetical terms, there is enough memory bloat and change in visuals alone that would very much point to this being a new setting entirely (as you mentioned), requiring code changes to support referencing upscaled versions over the originals.

There are a variety of existing parts that are either blatantly obvious in their need of fixing (belts being wildly oversized around the hips and unusable) or something more subtle but warranting a consideration for a new version that look or fit better (e.g: female jeans), so if the basis for this suggestion stems from parts like that, by all means feel free to make note of them here. Otherwise, if there wasn't a specific example that you think fits that criteria, then yes, as neat of an idea as it is, it's way out in the Oort-cloud of feasibility!