Chocobo during Queue - "Difficult"

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?

I don't understand the difficulty as it seemed he was saying they're trying to figure out how to best go about it.

Just add a "solo queue" checkbox to the DF, permitting you to queue solo whilst in a party.

This could also apply to partying with friends while putting in that solo low-level roulette queue.

It is not so much coding knowledge, as you need to know what their current code does.

As with paint, you can always paint yourself into a corner and it becomes much more difficult to do something. But it is never impossible.

I can see this being difficult.

Let's think currently the coding allows it as a party member to allow you to gain xp, and your chocobo to gain xp, while targeting and fighting for you reacting to you.
Plus you have the timer of the chocobo that is dwindling. Now the timer portion I can see they could use the same coding for that as they do when mounting, or in the major cities. However, the portion I think that's difficult is how would it be able to differentiate between a PC in the party and the Chocobo, since the chocobo's names can be created by the character as well. Also to prevent the coding from the chocobo to accidentally appear in the dungeon as well or cause a 5th/6th person to come in. Now let's take into consideration for the "pre made" parties. Don't forget they may use chocobos as well, so doing the coding to include those party members chocobos. While it may appear easy, there is many moving parts and some little tiny things we forget.

I don't know a thing about coding so I can't really judge one way or another. He did say though that he has to prioritize certain things and this seems to be near the bottom of the barrel at this time while they are getting out important fixes and content. To me that's pretty understandable.

Quote:

---

Originally Posted by Gesser

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?

I don't understand the difficulty as it seemed he was saying they're trying to figure out how to best go about it.

---

Yes.

The game isn't coded in a one page QBASIC script or something. You can't just go in and change a line and poof.

People always assume their ideas are easy to implement but it's not often the case. They had to completely trash the old version just to get some of the most basic features added to the game.

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 someone qued with a chocobo i would leave and not care about the penalty lol.

Here's my understanding of things.

Chocobos take up space in a party, but they are not necessarily considered "Party Members". They're almost like Guest NPCs, in a sense. If you form three players and a chocobo together, you don't get access to Limit Breaks whatsoever, because a Chocobo does not count as a party member, and thus, the party is not considered a "Light Party", which is required for four-man dungeons. This also has complications in the duty finder because, if a party is not a "Light Party", then it would allow players to recruit. However, if there are already four in the party (three and a Chocobo), then you can't have any more characters in the party in the first place.

Chocobo companions, at least when it comes to party makeup, is kinda paradoxical like that. And I'm sure, the way the system was developed, it would require some serious retweaking of the companion system for it to work to accommodate Chocobos (and maybe Magitek Armor later on) in parties for duty finder.

I know it's not impossible because SWTOR did it, but the difference there is that SWTOR built their party system with companions in mind. FFXIV did not. So... yeah. Definitely gonna need some serious code tweaking to fix companions in parties.

@Rjain, I don't appreciate the sarcastic remark.

I didn't say it would be easy, I'm curious how legitimately difficult it is.

@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.

It really all depends on how they have it set up. I have really basic knowledge of programming. I do find myself wondering why they cannot add an if statement for the queue that checks to see if the second party member(provided there are two people in the party) is a chocobo, and if it is then it ignores the fact that you're in a party and allows you to queue.

But then again it could conflict with adding you to another party once the queue pops. So again, it really all depends on how they have it set up.

Quote:

---

Originally Posted by Gesser

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.

Quote:

---

Originally Posted by Enepttastic

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.

Quote:

---

Originally Posted by Gesser

@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.

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.

Quote:

---

Originally Posted by Themis

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.

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...

Quote:

---

Originally Posted by Themis

<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.

Quote:

---

Originally Posted by Hulan

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.

Quote:

---

Originally Posted by melflomil

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

---

So, updates as normal then eh?

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

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

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.

I think some of it comes from being somewhat of a party member. The reason, I think, is that you can only have one companion. Would the SMN choose to have the chocobo out if it took the companion slot? I don't think so. So right there that would be a problem to moving them to complete companion.
Another problem of turning them into a compaion would make them, technically, usable in a dungeon. Yes there is a work around of saying that an entity with a data value of what ever the chocobo's data value is, is not allowed to appear in the dungeon.

Now you are saying, "Couldn't they do that with the current system?" It would probably require a HUGE rework of the instance infrastructure. When you zone into a dungeon you are technically in a different party than the one in the world, due to the world and the dungeons being on different servers. When you enter a dungeon you leave the world, now if you where to do that with a chocobo that would force it to despawn since you are not there for it to follow. Now when you zone back into the world it puts you back in your original party, but with the chocobo despawn it has left the party since it does not exist in the world nor does it have a persistent presence in the world.


Well that is pretty much all speculation on my part based on what I've felt of the game and somewhat complete knowledge on coding practices. I would like to end of saying I can be wrong, I probably am wrong since I have not seen the code, nor do I know their codding practices. But this is what I think is the case.

Comp Sci here, anyone who claims to know without knowing their current code is lying, as the first reply said. If you programmed the functions with that in mind it would be trivial, but when you have multiple systems relying on each other, and you never thought of it, it becomes increasingly hard. It's always possible, but being a business, it's a large cost/benefit ratio question.

Quote:

---

Originally Posted by Enepttastic

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.

---

It was a metaphor. One that I thought at the time was quite clever, but clearly not. I am - in fact - a professional developer (though I will grant those who claim as much are a dime a dozen around here); and while I do not claim to be perfect at my job, I am very good at it. You can, of course, go back and change old code, but doing so carries its fair share of risks. What you say has merit, but you cannot plan for everything, and what is done is done. Saying that they should have seen the need for companions to not conflict with the duty finder system is all well and good, but they did not, and I find it quite believable that it is now in a state where changing it would take fundamental reconstruction of at least one subsystem to accomplish.

Making something "right" the first time requires a complete understanding of the final product. Unfortunately, MMOs do not have a final product; they continue to evolve and change. One lack of foresight early on can have rippling effects for years. I am not so quick to forgive people for slipshod code, but I also understand the magnitude of the undertaking an MMO represents. Getting everything right is nigh on impossible, and even a seemingly good design decision can have unexpected consequences. Does that exempt them from the culpability of not foreseeing this issue? Maybe, probably not. But that wasn't the question. The question was, "Is it really that hard?". And the answer to that is: almost certainly. This issue involves a lot more than just "Is the chocobo in the party?" It touches on fundamental server architecture questions that we don't even know the question to find the answer to.

Quote:

---

Originally Posted by Bigpurpleharness

Comp Sci here, anyone who claims to know without knowing their current code is lying, as the first reply said. If you programmed the functions with that in mind it would be trivial, but when you have multiple systems relying on each other, and you never thought of it, it becomes increasingly hard. It's always possible, but being a business, it's a large cost/benefit ratio question.

---

Pretty much this. We can speculate, but without seeing the codebase, it's throwing darts in the dark.

I just don't see why they don't remove the chocobo from the party list, put it in its own group say "Guardian" link everything you can do with party to the guardian slot that way you can que up. as you que and DF pops, it could do a quick check/withdraw guardian allowing you to select enter or it could phase your chocobolink like how you zone in to a city.