Really easy solution: Disable players from showing up in cutscenes at all, there's literally no reason for them to be there anyway
discord: melodyyy#0419
Have you ever done any programming? Clearly not and I'll leave it alone with you. Do you realize the players see things differently on their screen depending on where they are in the story? They may or may not see NPCs, landscape, buildings.
You want to have a choice to glamour but apparently don't want others to have a choice not to see it.
Last edited by CelestePinke; 02-22-2020 at 04:26 PM. Reason: Addition
I'm not a programmer. This is purely on my observation.
I am fully aware that people see things differently on their screens, but this is limited to things other than player characters. The world is deliberately arranged so that even if the world is different, players can consistently interact with it. (eg. The force field around Alexander that initially has rocks lodged in it, which fall away as Alexander's head moves into the same position - thus creating a functionally identical platform regardless of when you see it. They may not think you're standing on what you see them standing on, but there is solid ground there regardless.)
What you were saying is that glamours in solo instances are proof that there is already a system in place to have players appear differently to other players. I'm saying that this is not proof because for all we know your character's appearance in an isolated instance may be managed through a mechanism that can't be transferred to the larger game. That is irrelevant to what I think of the merits of such a system being implemented.
Last edited by Iscah; 02-22-2020 at 05:31 PM.
Realistically, unless something is wildly wrong with XIV's codebase, merely removing glamour entirely should not be terribly complex—provided you do it globally. (I.e., a single check, "does glamour show or not".)
Depending on how things are implemented, it might be kind of awful to try to do it conditionally; you'd think no one would put glamour-related logic in the primary runloop of an engine as opposed to in something like asset caching code, but you'd also think people wouldn't do a lot of weird things that games demonstrably do. (I'll admit to having been responsible for some such hackish shortcuts myself in those halcyon pre-crunch-burnout days when I still worked as a game developer instead of on embedded systems. I'm not proud of most of them, and someday I'll stand before the programming gods in the afterlife and be judged for those sins.)
So if any glamour-related logic is in a critical code path, you would potentially not want to make it conditional on specific characters. I.e., looking up whether or not a given character is in a glamour blacklist could have a measurable impact on framerate/performance; in that case, you would probably just want a global on/off switch where you disabled all glamour (potentially including your own) so that it's a simple boolean check rather than a lookup. Plus, a global switch could be implemented entirely client-side, whereas maintaining a glamour blacklist—assuming you wanted it to be account data like your normal blacklist—would require changing things on the server side to allow such a list to be loaded and saved.
If the glamour-related logic is all safely in code that just prepares all the assets/resources for a given instance and then it's done, then you could most likely make it per-character instead, albeit with more effort involved (since you'd probably want to modify the server to allow a glamour blacklist to be saved).
Hence my earlier suggestion that if someone honestly wanted to implement this feature, the way to do it that would probably have the least performance impact and take the least dev time would be a global on/off switch for glamour. Probably with the exception of weaponry, because I feel like people who grind relic weapons and whatnot would be Not Super Thrilled if people just turned off glam and you couldn't see that they had, say, a weapon earned via clearing TEA. Push the button, and everyone—me, you, that person over there—are in job-specific artifact gear, end of story.
I mean, I still am very meh on the suggestion—and even if I weren't, there's about fourteen quadrillion other things I'd personally prefer the devs worked on first—but if they were going to do it, I'd want them to take as little dev time as possible on it so it didn't detract from other things.
Not finished phone >_>
When the client side is getting pushed to its limit you would then need it to reglam everyone on screen to the desired feature glam.
Then have everyone there use the feature at the same time to see how the servers fair handling all the different client side information since your glam would be changed on others while normal for you so each individual player which are not static in their appearance unlike npcs would have their own client side. This may very well make the servers go boom XD at least with regards to ff14 servers which are yea ff14 servers
Iscah is probably correct in that they use glamour plates as it is an already designed system that they can use at will (also notice these solo instance glams only appear after glamour dresser was introduced), it would be a convenient shortcut than individually changing every possible item to it as instance starts, if I know programmers they would take the shortcut so long as it is functionable no sense wasting too much unnecessary time on it.
I'm no longer going to advocate for or against this feature (being that it was the principles of the whole thing that got me involved in the first place), but I also feel that we shouldn't mislead people from a technical standpoint.
The client is not only a executable full of code, but all of the assets in the game as well. Seeing as to how the races, genders, levels, and jobs of other players are already transmitted to you from the server, it would be very simple for any sanely-written engine to take that already-transmitted information and make a pre-programmed decision on what other assets to load instead of the glamoured ones.
The servers would not even need to be involved.
Except this feature is altering a fluid option to players constantly. It would be different if the feature was like visual effects which can be turned off but are still happening regardless which is static data. People move, new ones appear/disappear all new data that has to be constantly updated to suit this setting thus it would require a more extensive stress test. I'm not saying it is impossible but unlikely to happen due to this.
This would increase loadtimes as you enter new areas (small increase but will increase it) and instances.
This feature may just be a switch flick for the user but for a programmer it is way more complicated than that.
The only thing fluid you mentioned is jobs since we can switch on the fly, levels, race gender are static data since you cannot alter them freely levels can only go up except in an specific instance (Eureka) that has been designed for it, race&gender require an item to flag to change and disconnect from server (do also bear in mind you have to be naked to do this as clothes are fluid data), static data is far easier to change via settings so adding them is less tenuous but fluid data is the nightmare for programmers to add settings for duoable, but way harder and require more power, client side would not be able to support it with regards to ff14 and its playerbase not with how this game is run and apparently coded (based on their excuses of 1.0 code problems).
You still said nothing of why the servers need to be involved.
Let's say the server sends a "load player model here" request, sending things like coordinates, the job of that player, their gear (including glamours), their race, their gender, their name, etc etc etc. When the model loads and begins to render, it uses the glamour information. If you keep some default gear for each job loaded at all times and use that instead when the option is checked, then the server would not have to do anything.
|
![]() |
![]() |
![]() |
|