Dev Tracker - News, Discussions

Next month is the usual return to home campaign so expect a CP then. But then again... Hyper Chocobo Digging Campaign for All!

Double exp/CP and an Incursion campaign please. Make Reisen T2's great again!

lol

They did mention something about a return / more interesting set of campaigns for new players like a few months back. I'm guessing since the alter-ego is for a full month, they may just do one of those 1-week "events" for the new player approach

We shall see

I'm down with that:
2x < 3 min.
1.5x < 5 min.
.75x > 10 min.
.5x > 15 min.

Apply to all difficulty levels and party count. Encourage people to be efficient.

I guess a lot of people forget the days of lines for Divine Might and other BCs littered throughout FFXI's history. We all (for the most part) know that SE doesn't do instancing in the truest meaning of the word...they instead built copies of BCs/etc and hoped they would be enough to handle demand. It hasn't been working for 12 years. This just seems worse because Ambuscade renews every month so it never "gets old".

The solution isn't gimmicky bonuses- the only solution is SE dedicating more resources to create more copies of the BC. Because they aren't going to suddenly after this many years change HOW they do this style of interaction. The best we can hope for is they just do more. I'm against the gimmicky bonuses because such mechanics are always abused eventually.

Not entirely true. BCs such as divine might that are carried out without a zone-in are indeed fake instances. You can pull up the skeleton of the zone and see there are 3 of most of them(1 of the ghelsba one). The mob lists show 3 of each monster. That's correct. The game picks a location for you and spawns that location's copies of the mobs. You can even pos to another group's location and watch their fight, if you were so inclined. These persist up through adoulin, including battlefields for the final missions of both WotG and Adoulin.

However, since ToAU there have been a large number of zones that appear to be truly instanced. Despite different groups entering them, each group shares the same exact coordinates, same exact mob IDs. Treasure pools are unique to each zone, there's no data sent on anyone else. Furthermore, limits are placed on the number of instances in action by the server running them. For example, you can have no more than 24 salvage/mmm instances up. However, they can be spread any way needed between the 4 salvage zones and MMM.

Furthermore, unique to those zones, when they are overloaded you'll find that linkshell chat travels extremely slowly in and out. This means they are not being treated as a single zone, where the zone would simply relay the message to all clients.. but some sort of IPC is slowly passing the linkshell chat to each instance. While not an easy experiment for an average person to replicate, during the time of the salvage exploit I had 22 runs going at once out of the 24 available instances. When speaking in linkshell, characters received it at drastically different times ranging from 2-3 minutes late to over 30 minutes late.

Additionally, after D/Cing inside an instance, the instance remains active for other players to appear inside. If you d/c in salvage, then log back in, you will be potentially visible to the person/people inside that instance until you are forcibly zoned out. This means that either the instance retains a handle, or you are shoved into a random existing instance as your character has a need to have an entry point. This is indicative of their ability to reset a single instance without destroying it. Initially, this could be seen as supportive of copies, but keep in mind that the limit to number of copies can be changed between zones in the same server(24x bhaflau remnants, 20x bhaflau 4 arrapago, 5x mmm 12x arrapago 7x bhaflau etc..). This means they're either checking for an unused copy in their list of active zones when entering a new person, or checking for any copy in their list of active zones when a person who has timed out logs in.

If they masked other players by checking which copy they should be in, as opposed to having unique classes, you would not be visible in that scenario. So, again, we see evidence of a unique class for each instance. Nobody can conclusively say if they're being generated as unique class instances or handled via a table(max 24 total, but each possible instance has 24 copies and they just decide which to use at that point). Common sense would dictate they are generated dynamically, because we can see that they are intelligently reusing existing zones in the cases of people disconnecting, whether it be by allowing others in or allowing the disconnected person into someone's existing instance to time out. If they are able to iterate through the zones, there's very little reason for them to be static copies instead of dynamically generated.

tldr; Most evidence indicates true instancing. Not enough information available to say 100% without viewing SE's source code. Even if not true instancing, copies can be dynamically distributed between potential uses on the same server.

SE likely can't make more of them because the hardcoded limits are based on the server's ability to keep up. Given the bottleneck with linkshell chat, it is almost certainly a performance limitation and simply increasing the limits would do nothing besides allow players to choke the server out. They would need to increase the efficacy of the instance code or buy better hardware, neither of which is reasonably within FFXI's current budget.

This is interesting... this reminds me one time back when I was spamming AAGK I entered and immediately said I couldn't call trusts because I had accrued enmity. Thought that was weird so go to fight GK and there was a dead guy for a tiny bit until it forced him out and then I was able to call trusts

That's bizarre in quite a few ways, because those BCs aren't real instances and even if the person logged back inside it they shouldn't have had the necessary status flags to impact or be impacted by your run. For example, a dead person could easily POS into a la'loff arena and there's no reason to believe it would effect the run going on(though they would be visible).

Exact opposite. They are just masking anything your not supposed to see when your inside Legion. It's a sort of hybrid method where the zone is static but the content is dynamic. It enables them to support more simultaneous fights then previous but it's not benefiting from the biggest advantage of instancing, smart resource allocation.

Again this is very old technology from a long *** time ago. They haven't even updated the client to user DX9, much less modern MMO infrastructure.

And for those wondering how I know about their internet structure, it's because I had to reverse engineer their server architecture.

All you lucky *** got to play by just clicking "Play" and didn't have SE's network security administrators black listing the entire country you lived in. Thing is, they only black listed the lobby servers and not the actual zone servers, so one could connect to the lobby servers if they had a tunnel setup to another location, my preferred one was a Japanese host. But since tunnels suck to play games through I had to figure out exactly which servers and on which ports the game was blocking, and which other ones it wasn't. Lots of packet capture and wiresharking while logging in and playing and then building route rules around that until I had nearly every zone and server mapped out based on destination IP and port. Occasionally they would move something inside their data-center and I'd get disconnected on zone until I was able to map out that new IP:port and then create more rules for it. I can even say that the POL login and patch servers are on a completely different network then the world servers and last time I had to use this solution they weren't even in the same building.

If SE was using true instancing then I would of never been able to play Ambuscade since every instance would of been a new UDP port number on one of their content servers and the IP address would of changed based on which content server hosted that zone.

BC's aren't instanced or even have dynamic content, they are static fields that you load into with an init script that calls the NM's up zonein. It's entirely possible that a dead DC'd person would reappear and the game could wait until they raised up or the RR timer expired before zoning them out.

If they mask anything you aren't supposed to see, why would a disconnected character inside salvage be able to see and be seen by the following group upon logging back in?

Furthermore, if they mask what's visible, why would there be a limit to unique instances that was more than a single easily modifiable variable? All they should need is a unique fake-instance identifier for each group.

Next up, we have the limits placed on salvage/mmm. There's a max of 24 total instances/masks between the zones. However, they can be split however they are needed. If the limitation was on #/masks, surely it would make more sense to limit it per zone?

Finally, where's the proof? A clean masking system and unique instances would be 100% identical to the client. That leads us back to what I said from the beginning, it can't be proven without their code. I don't necessarily think the masking theory is wrong, but like I've said for several pages.. you have yet to provide any meaningful evidence in favor of it.

Regarding your questionably legitimate story about your connection, there's no reason they couldn't use the same port and have the instancing handled server side. You don't need a unique listener to associate incoming data with seperate instances. It's very strong evidence that they don't do dynamic load balancing between multiple servers, but we already knew that based on how shitty their performance is.

You confusing different content and assuming it's all the same, which it isn't.

There has been a progression at SE throughout time as they got better and hacked in more modern methods. Originally it was all static zones with static content, either shared zones like Ground Kings, or private zones like BC's. Years later SE, under complaints from players about congesting in popular content, started looking into ways to do some form of instancing in order to enable multiple groups to do the same content. At first it was just a really large zone with multiple copies of the dungeon / battlefield, and eventually they made it so that individual groups were sectioned off and using the same zone but with content dynamically built for them. They rarely go back to older content to "update" to a newer or more efficient method of doing things.

Rollenberry Fields is different from Dynamis is different from BC's is different from Delve and is different from Legion.

We are discussing Ambuscade, which is the most recent form of shared battle content and uses a hybrid method. If they were using true instancing there wouldn't be congestion at such a small number of copies. Since the other content is largely empty, the resources on the cluster would be available for creating more dynamic instances with no lag effect. We get the exact opposite, extreme lag effect even with a small number of participants and other areas are completely fine.

Again, we're back to assumptions and no data to back them up. There's no reason to believe a zone created in 2012 wouldn't be capable of dynamic instancing.

They would simply need a superclass wrapped around their zone class. Replace socket connections for each instance with pass-through input that supplies character ID and packet data and pass-through output that uses the existing socket. Handoff zone asks instance zone to make an instance. Instance zone makes instance, returns id. Handoff zone tells instance zone which instance each character is going into as they are handed off. Pass data through to that instance, instance passes data out through zone server.

Boom, instancing that can be created in a day with an existing system. Bonus, it bottlenecks on packet data because it's all being crammed down a few existing sockets in one class. Sure sounds similar to what we actually experience.

There are numerous explanations that can be created for what we see. The only facts are what we can observe from the client end, and while you choose to interpret them one way, it doesn't make it fact. You obviously have a pretty good idea of architecture, you just refuse to admit that the conclusions you draw aren't the only possible way it could have been implemented.

No you can't use the same UDP port for that. UDP is stateless, there is no connection tracking which is why I was able to *** past their security servers.

As for your attempt at ad hominem

From 2008

http://ffxi.allakhazam.com/forum.html?forum=10&mid=1219917236275954806&h=50&p=2#58




Saevel's FFXI solution 1.0 was using packet capture on my own machine and sending it through a SOCK5 proxy a friend of mine was running in the USA. Eventually I got a VPN provided but didn't like routing all packets through it as that makes playing extremely laggy since I was sitting a few hundred km from the servers. I had to continue my sniffing and through a ***ton of testing got to map out their network and construct a set of static routes that would forward packets for specific servers through my Japanese VPN but forward everything else through my high speed internet connection. In this way I was able to fool SE's connection system to thinking I was in the USA while enjoying the latency and speed advantage of playing near Japan. All done years before we had this discussion.

That's a gigantic post of irrelevant information, though I will say it was very creative the way you got that to work.

They can quite obviously associate a UDP packet with the character it's controlling, else it would be possible to play someone else's character by simply modifying headers/character IDs. All they have to do is prepare the server to target that character to a specific instance, which they would do by sending data from the entry zone prior to allowing everyone to enter.

Is it clean? No. I'd say it's much cleaner than using masking to cram X fake instances into one zone class though, and less work to implement to boot.

No.

You can't host multiple services behind a single UDP port, doesn't work. That's literally what TCP was made for. UDP is fire and forget, no stateful information involved which is a requirement for multiple service. This is basic service architect 101. Your attempt at *** measuring would have more effect if you didn't try to call me out on reverse engineering SEs service architecture.

Doesn't need to be a seperate service.

Zone class is created as service.

Inside zone class are handles to all of the zone instances. Zone instances are modified to accept pass-through data instead of using sockets themselves.

Input is directed to the appropriate instance based on character ID.

It's not that complicated. It's much less work to create multiple instances of the existing zone class and change it from direct i/o to a passthrough than it is to create all the code behind masking. They didn't use masking in BCs, there's no reason to believe they had it already written.

Neither is 'correct' and both would be terribly shamed by any current developer. However, we can both agree that they do not have fully autonomous instance code capable of cross-server load balancing. That leaves only awkward solutions.

He said UDP packet, not port. The UDP packet header sent from the FFXI client contains identifying information.

However, given that the UDP packet header does contain identifying information, it's obviously possible to use a single UDP port for it.

y dont u just calls square enix and ask

Tried once, it's in the original thread off alla. After FFXI stopped working I made all sorts of phone calls to them trying to get some semblance of an answer on why. They don't give out that kind of information and I was forced to use that complicated multi-homed setup for nearly eight years.

Anyhow you guys are deliberately being obtuse, and Byrth should know better.

ya byrth what is wrong with you complaining about how terrible ppl are in public

Best way is to do what is already working in XIV. Daily Roulette works because I rarely have an incentive to keep doing dungeons after I get my daily bonus. Spammers and people farming for lights or whatever will still spam, can't stop them, and the game shouldn't penalize playstyle but it can encourage people to move elsewhse.

Massive 1st run bonus. If they are nice, they can even do it for vol 1 and 2 separately. They sort of already do this by making the 1st rekey of the day 1 kill and super easy. They just need to scale the rewards.

Removing the soloers for the queue will alleviate the congestion the most.

ROE is pretty much the perfect dailies reward scheme and its already in place. They just need to add those RoE quests that at minimum triple gallantry/hallmarks for the 1st run.

Y'know... I would have agreed a couple days ago.
But thinking about it, having daily RoEs that rewards a seal upon completion would actually increase congestion. (Or as you indicate a RoE that gives Hallmarks and Gallantry directly.)
As well as soloing.

As you'd have people run in and do each on VE solo just for a quick seal, then save those seals for a group.

However.... adding seals to the "kill 1 thing" dailies would NOT increase congestion as people would just kill a random thing every day and then use their stack when they're in a group.

From the developers own mouths err fingers.

So according to devs some content is. Guess half is better than nothing

They said Ambuscade is layered not instanced. Layered is multiple non-connected battlefields existing simultaneously within the same zone stacked on top of each other. It's that hybrid system I discussed earlier.