Chocobo during Queue - "Difficult"

[WingsofWar]

Someone with coding knowledge tell me...
Is it really that hard to keep your Companion flagged as a party member & simply cause an automated disband/reform when you accept a queue?

What we fail to understand is not the coding, but how the system was built. It seems like its not just a simple flag in the header needs to be altered, rather an entire object class or model that needs to be changed or redone to accept the que, and if that is the case we don't know how large this object is and how much it affects the system entirely.

The object model for party and the object model for queing into instances may have strict checks, and if the companion model is embedded into the party object you are going to run into a wide range of issues trying to que into instances.

What issues? I can only guess that the instance server will have a tough time holding onto your companion model in your party while your in another party. Essentially you are trying to run 2 party objects one with you and chocobo, and 1 with you and the instance dungeon.

That's my guess from my basic knowledge in coding C++/C#/Python/Ruby/ObjectC.

[Themis]

No, I wouldn't consider it difficult(as in hard to do), at all. Time consuming, perhaps, but that's going to be due to the lack of common sense shown when developing to begin with.

If you think that, you should apply to work for SE.

It's not hard to do, if you design the system to work that way in the first place. You have to remember that the party system, the companion system and the duty finder system are 3 different systems, and interfacing effectively between them isn't a simple "just do it" task. Can it be done? Of course. But unless you have even the smallest idea of what their design decisions and their code base is like, don't assume you know better than they do. They aren't incompetent, and solutions don't fall out of the sky.

But evidently, the way it has been design doesn't allow for a simple change by adding in a couple of variables. The reason they don't want to just start hacking away at the code is because it would detract time away from other, more important areas of the game, like new content. Considering how many people seem to complain that there's nothing to do, this seems like a bad choice.

[ArashiDaigon]

@ArashiDaigon, under my suggestion the system wouldn't have to differentiate between PC & Companion as party makeup (and changes to) would have no effect on the 'solo queue' check/flag.

Under my proposal, you could freely move to & from parties, companions included, it would still retain your solo-queue status.

In theory. However, let's say you input said code like you suggested. The program would then have to say ok, disband/reform for what? It would look and see PC(Chocobo). So it would disband the chocobo, then when you have "completed" dungeon, you'd be back at the spot and chocobo reform. Now... when it reforms, will it use a gysal green again, cause with the coding to "reform" party it may.

Now, let's take same code. You are no longer soloing but in an actual party. You wanted to form with say a friend, so you are duo partnered. If you use said coding, this may cause you to go in solo, and cause your duo partner to go into another queue instead of you being in the same system. As your duo partner is registered under (PC).

So then you'd have to input a different strand to differentiate between said sources and such, while also tying in the structure you have now. In other words, something that seems soooo simple and very easy can be longer than anticipated, not to mention could potentially cause another code strand to break, or not do it's intended effect.

[Hulan]

Keep in mind also that when you go into an instance, the responsibility for processing on your character is transferred to a physically completely different machine (don't ask me why, but this was confirmed in their response to the /tell in dungeon question). This means that a lot of the information about your character's state has to be correctly maintained and curated by two machines simultaneously. Such situations practically beg for synchronization dilemmas such as race conditions, resource starvation, or deadlock. Yes, "putting a flag on it" is a correct and simple enough answer. But things get infinitely more complicated and dangerous when you inject data moving between physical machines. It also bares mentioning that, as mentioned above, they have backed themselves into a corner with the party mechanics. Chocobos are treated special. They count as being in a party for the sake of things like party invites, but have special rules associated with them, such as the inability to enter instances. Without seeing the code, it's impossible to tell, but they could easily have coded themselves into a corner.

To be clear, this does not make them bad programmers, it's something that happens all the time especially on evolving projects like MMOs. Imagine you are building a Car, and you build a Ferarri sports car, then someone comes in and says "Ok, now make it seat 5 people." It's impossible. Yes you can make a car seat 5 people, but you can't make that car seat 5 people.

[Alacor]

It's not hard to do, if you design the system to work that way in the first place. You have to remember that the party system, the companion system and the duty finder system are 3 different systems, and interfacing effectively between them isn't a simple "just do it" task.

Exactly. I don't know how they do things in game development studios when it comes to programming, but I'd imagine they have multiple people working on multiple systems when building the game. That means integrating features that interact with multiple systems requires complete knowledge of how each involved system works, otherwise something could go horribly wrong that you never even thought could/would happen. So when you see odd bugs in games that seemingly make no sense as to why it would happen, just remember most things are working in tandem with something else.

[Yukiko]

i think the problem they have is the messed up code:
Lets say they have to deal with local variables, but they need global variables now because DF cluster wise...

[Enepttastic]

<snip>

Note that I said it would be time-consuming to do it now, since there was a distinct lack of common sense when developing the companion system. Being able to queue while one's chocobo is out is something that should have come up during the design phase and either decided for/against. Two out of three possibilities(didn't come up, decided against) show poor usage of common sense during the design phase, similar to how chocobos weren't originally able to be ridden while summoned.

As for it "evidently" not allowing for a fix, there's no proof of that. Merely proof that, as of the moment, it's considered enough of a non-issue to warrant spending the man-power to either figure out a solution or to code it in.

Admittedly, I'd have to have a first-hand look at the logic behind the coding before I could say, for a fact, how time-consuming it would be to implement, but considering that in just a couple of minutes, I have several different ideas(many utilizing logic that's ALREADY EXISTING in the game) so no, I don't believe for a fact that it would be difficult at all, merely time consuming and the fault for that lays directly upon those involved in the design process.

To be clear, this does not make them bad programmers, it's something that happens all the time especially on evolving projects like MMOs. Imagine you are building a Car, and you build a Ferarri sports car, then someone comes in and says "Ok, now make it seat 5 people." It's impossible. Yes you can make a car seat 5 people, but you can't make that car seat 5 people.

Except that programming does allow for going back and tweaking previous work to facilitate the new concepts. While not impossible, it's a little harder to do changes like that for physical items without making previous work wasted. That said, I'm going to repeat this: I doubt this is a problem the programmers caused, the issue was created during the design phase for chocobo companions and should have been considered/planned for then.

Yes let's do this and Game breaking bugs gets introduced me.

So, updates as normal then eh?

[DefendPopPunk]

I took intro to programming where we used C# to make a calculator. It was buggy as hell and frankly it never worked. Even still, how complicated could this be? I bet I could do it. Just toss in an if statement and a do-while and we're home in time for lunch or whatev

[melflomil]

Yes let's do this and Game breaking bugs gets introduced me.

[Codek]

I'd imagine that there are all kinds of complication from implementing it that the risk is just to high.

For example, they probably use the party flag to determine if you should be removed from duty finder (invite a friend and it will drop you from queue). If you are queue'd with a companion and are set as "in party", then if you invite a friend, the system will not know to kick you from the queue. This would require a complete re-work of how they flag for when you are no longer eligible for duty finder. If your companion does not form a party, then they will have to re-work the party limitation for when companions are out. Either way, major bugs would need to be addressed.

Throw into the mix that they could be developing all kinds of changes to companions or an alliance system and the effects become un-imaginable.

It sounds like they are waiting for development of the expansion to settle a bit before deciding on the best way to approach the issue.