Post deleted by User.
PacketFlow - For Ashita And Windower
PacketFlow - For Ashita and Windower
Aricomfy said: »
RadialArcana said: »
Would you be interested in trying a mod of that zone to see if it fixes your issue?
Someone asked me about this years ago and I made a mod for it, I can give you a link to try if you want.
Someone asked me about this years ago and I made a mod for it, I can give you a link to try if you want.
I was lurking the thread when this issue was brought up and I believe the root of the problem was the smoke from the chimneys coming off of almost every building or something that was lagging the game more than normal. Was it your mod that "removed" the smoke with a texture edit?
The slow motion effect with 60 fps mode happens in other circumstances with above average stress which is why I thought PacketFlow might actually help relieve this problem.
Yeah, posted it ages ago. Some said it helped at the time.
Thanks very much for this, it was one of the most annoying parts of the game which I assumed would never be resolved. Might be another 9 months or so until I can try this, but just wanted to show my appreciation for the hard work.
If SE goes about banning people for this it would be disappointing, because it's not seriously affecting them, nor is it giving anyone an unfair advantage. It cleans up the information sent to us for a smoother experience, which makes for better and less frustrating gameplay.
However, if I were still playing, I wouldn't try this for at least six months, because if you really care about your accounts, then you've got to give SE time to confirm if this is something they choose to ignore. Fingers crossed they do ignore it, and you guys can make this one of the best addons to the game in years. Cheers!
PS: Does anyone know if this helps with animation lock? Like when you pull too many mobs and the game freezes you in place because it can't handle it?
If SE goes about banning people for this it would be disappointing, because it's not seriously affecting them, nor is it giving anyone an unfair advantage. It cleans up the information sent to us for a smoother experience, which makes for better and less frustrating gameplay.
However, if I were still playing, I wouldn't try this for at least six months, because if you really care about your accounts, then you've got to give SE time to confirm if this is something they choose to ignore. Fingers crossed they do ignore it, and you guys can make this one of the best addons to the game in years. Cheers!
PS: Does anyone know if this helps with animation lock? Like when you pull too many mobs and the game freezes you in place because it can't handle it?
Cerberus.Kylos said: »
PS: Does anyone know if this helps with animation lock? Like when you pull too many mobs and the game freezes you in place because it can't handle it?
It doesn't, but there are a lot of ways to deal with that. One easy one would be to make an addon that temporarily blocks all action packets that hit you, but aren't initiated by you. You load it, stop seeing the mobs attack, get out of animation lock, then unload it. You could even implement it on a timer, like '/blockpackets 10' to give yourself 10 seconds of mob attacks hidden. Then you don't have to bother with an on/off.
[+]
RadialArcana said: »
Aricomfy said: »
When using 60 fps mode in the config addon there are very apparent slow downs in some areas such as Western Adoulin. Would PacketFlow reduce this issue for 60 fps mode? I wouldn't think so but just to make sure, I figured I'd ask.
Would you be interested in trying a mod of that zone to see if it fixes your issue?
Someone asked me about this years ago and I made a mod for it, I can give you a link to try if you want.
I'd be interested in a link to this too, if at all possible. Anything that reduces that horrible slowdown would be very helpful
Shiva.Thorny said: »
Cerberus.Kylos said: »
PS: Does anyone know if this helps with animation lock? Like when you pull too many mobs and the game freezes you in place because it can't handle it?
It doesn't, but there are a lot of ways to deal with that. One easy one would be to make an addon that temporarily blocks all action packets that hit you, but aren't initiated by you. You load it, stop seeing the mobs attack, get out of animation lock, then unload it. You could even implement it on a timer, like '/blockpackets 10' to give yourself 10 seconds of mob attacks hidden. Then you don't have to bother with an on/off.
If someone could make this I'm sure the community would love it, lol. The only workaround I had was making sure I'm engaged and stay close enough to my target to not disengage, but it can still be tricky. It's the worst feeling when you pull too many and get locked helplessly for over 5 minutes until you die.
JaZero also makes you ignore incoming hits when it comes to pulling out your weapon. If you're fine with that aspect but not the other things it does, you can load it then unload it when you engage.
Asura.Geriond said: »
JaZero also makes you ignore incoming hits when it comes to pulling out your weapon. If you're fine with that aspect but not the other things it does, you can load it then unload it when you engage.
but i am also phoneposting and havent verified, so grain of salt
SimonSes said: »
Bahamut.Immortalknightx said: »
The best question yet. How do I get it?? I don't see a download link
Built in to windower. Konami code on plugin tab to unlock few hidden plugins including this one.
I stupidly dismissed this as sarcastic reply.. nope.
Go to windower's app with the 3 tabs, choose the plugins tab, on your keyboard: ↑↑↓↓←→←→BA
Asura.Geriond said: »
Does this also help with input lag (IE, you issue a command and it does go through, but it takes like 1-2+ seconds to initiate)?
What you experience as "input lag" might as well be "output lag"
you click a button
action is sent to server
sever does the action
results is sent back
delay
delay
more delay
Your clients receive results
You see the results
its my understanding we send very little informmation to the sever vs how much we receive that most likely lag is on the feedback rather than the execution
DaneBlood said: »
Asura.Geriond said: »
Does this also help with input lag (IE, you issue a command and it does go through, but it takes like 1-2+ seconds to initiate)?
What you experience as "input lag" might as well be "output lag"
you click a button
action is sent to server
sever does the action
results is sent back
delay
delay
more delay
Your clients receive results
You see the results
its my understanding we send very little informmation to the sever vs how much we receive that most likely lag is on the feedback rather than the execution
Nah man, he keeps missing those sweet headshots when he fires with the controller.
Has anyone experienced crashes while using this plugin? I gave it a try on Thursday, and ended up crashing to the desktop within 5 minutes of my first segment run.
It could be a complete fluke of course. Just curious if anyone else has had the same issue. I'll probably give it another try here in the near future.
Definitely appreciate all the hard work.
It could be a complete fluke of course. Just curious if anyone else has had the same issue. I'll probably give it another try here in the near future.
Definitely appreciate all the hard work.
Asura.Neviskio said: »
Asura.Bippin said: »
So I have no idea about any of this stuff but does increasing bandwidth by 60% increase server cost for SE? Assuming enough people are using this.
I can picture it in my mind:
data analyst/business intelligence at square enix presenting in front of the producer/higher ups for ffxi
"...and this graph shows that our 10k monthly bandwith/server costs in june increased to 20k, we're investigating the causes but we believe it might be due to a third party addon."
I'm sure this will go very well for the future... the producer and execs will definitely turn a blind eye, what could go wrong affecting the bottom line of square enix on a game in its sunset stages?
Unless the claim it increases the bandwith has been exaggerated I would not risk it considering they will notice this and some higher up will get this shut down instantly
just for clarity
- it only 60% increase not 100% incres
- it would only be 60^in crase if everyone ran the addon
- it would only be a 60% increase in worstcase heavy traffic situations
So concidering all these affect reducing factor. the above scenario is not as likely as you potray it
Shiva.Thorny said: »
One easy one would be to make an addon that temporarily blocks all action packets that hit you, but aren't initiated by you. [/quote
What would be the drawback. you want see dmg to you in chat log? but hp would still be update?
would it be possible to just do it for "auto-attacks: si we can still see spell and TP moves ?
im thinking this would be very helpful addon if it didn't blind us to much
What would be the drawback. you want see dmg to you in chat log? but hp would still be update?
would it be possible to just do it for "auto-attacks: si we can still see spell and TP moves ?
im thinking this would be very helpful addon if it didn't blind us to much
RadialArcana said: »
Yeah, posted it ages ago. Some said it helped at the time.
link ?
in general loving the results even with my piece of ***toaster that I play this game on, but this morning I had severe freezing of the game while dumping sparks/accolades with this running along with using SellNPC.
I don't have near the knowledge to accurately represent what was happening, I just know I've never experienced the game freezing that severely in just a town before, and thought any info was good info in this stage of the game.
I don't have near the knowledge to accurately represent what was happening, I just know I've never experienced the game freezing that severely in just a town before, and thought any info was good info in this stage of the game.
Internet usage is measured in bits, not Bytes, a bit is 1/8th of a Byte. The following math is in bits
10k people at 6.25kbps is 62.5mbps
add 60% and you have 100mbps
So, from a purely network usage perspective, we would have to decide is SE really cares about an increase of roughly 40mbps
The increased bandwidth is pretty small compared to anything their other services provide. Usually in the types of facilities SE would host the game from bandwidth is purchased by the gigabit (1000 kilobits is a megabit, 1000 megabits is a gigabit)
to put that in perspective, 40mbps is 4% of a gigabit.
a 60% increase in bandwidth, on a game made for DIAL UP, is still basically nothing.
*The math is meant to be close enough to illustrate how insignificant this should be to SE, nothing more.
10k people at 6.25kbps is 62.5mbps
add 60% and you have 100mbps
So, from a purely network usage perspective, we would have to decide is SE really cares about an increase of roughly 40mbps
The increased bandwidth is pretty small compared to anything their other services provide. Usually in the types of facilities SE would host the game from bandwidth is purchased by the gigabit (1000 kilobits is a megabit, 1000 megabits is a gigabit)
to put that in perspective, 40mbps is 4% of a gigabit.
a 60% increase in bandwidth, on a game made for DIAL UP, is still basically nothing.
*The math is meant to be close enough to illustrate how insignificant this should be to SE, nothing more.
[+]
Outside of consumer connections, egress isn't charged by speed, it's charged by data transferred. I already covered on page 3 that even at exorbitant egress rates their cost is a drop in the bucket. Their egress still costs less than 1% of their gross revenue at an absolutely insanely cranked to 11 worst case estimate.
Byrth and Thorny have also pointed out well enough that the game isn't sending you any more data than it would have anyway except in the laggiest instances, it's just sending the same set of chunks more rapidly.
But anyone else who needs to come in here and throw remedial networking knowledge around to feel better about using this plugin is welcome to, I guess.
Byrth and Thorny have also pointed out well enough that the game isn't sending you any more data than it would have anyway except in the laggiest instances, it's just sending the same set of chunks more rapidly.
But anyone else who needs to come in here and throw remedial networking knowledge around to feel better about using this plugin is welcome to, I guess.
So I'm trying to wrap my head around the way this works a little more. I'm assuming the server and client both keep a queue of chunks waiting to be sent that is purged, prioritized, coalesced into a UDP packet, then sent at certain intervals. If the queue fills before the interval, then lower priority chunks are discarded (or sent later?). I'm also assuming the server side purge/sendparse is triggered either by certain time intervals or the queue filling, but it also sounds like it can be triggered by receiving a packet from the client.
If all that is the case (assuming I'm not way off base), where does the 6.25 kb/s limit come from? Is that the frequency the server sends packets/purges regardless of what is in the queue? I'm reading that as the client isn't solely responsible for the send frequency.
Based on what Thorny said in reply to the CPU utilization question, I'm also assuming that this plugin works because the increased packet frequency from the client results in this purge sooner, meaning it's less likely that chunks waiting in the queue to be sent will be deprioritized or discarded since the purge is happening sooner. It'd also mean the only real consistent increase in traffic is whatever outbound/inbound messages are being sent at that 250ms interval (some keepalive or position packet?), which presumably is small, and the chance of increased bandwidth usage would only occur when the queue is filling at a higher rate and the response packets are larger because there are more chunks from the queue. In other words, the frequency remains fairly consistent, but bandwidth usage is dictated by queue size and CPU usage is a non issue since the only additional usage would come from having to prioritize multiple chunks.
Is that right or am I way off? I'm mostly curious about the implementation details, but also trying to understand the risk of there being an issue.
If all that is the case (assuming I'm not way off base), where does the 6.25 kb/s limit come from? Is that the frequency the server sends packets/purges regardless of what is in the queue? I'm reading that as the client isn't solely responsible for the send frequency.
Based on what Thorny said in reply to the CPU utilization question, I'm also assuming that this plugin works because the increased packet frequency from the client results in this purge sooner, meaning it's less likely that chunks waiting in the queue to be sent will be deprioritized or discarded since the purge is happening sooner. It'd also mean the only real consistent increase in traffic is whatever outbound/inbound messages are being sent at that 250ms interval (some keepalive or position packet?), which presumably is small, and the chance of increased bandwidth usage would only occur when the queue is filling at a higher rate and the response packets are larger because there are more chunks from the queue. In other words, the frequency remains fairly consistent, but bandwidth usage is dictated by queue size and CPU usage is a non issue since the only additional usage would come from having to prioritize multiple chunks.
Is that right or am I way off? I'm mostly curious about the implementation details, but also trying to understand the risk of there being an issue.
That's as well as I understand it, thinking of it as a fixed 400ms tick rate with a maximum 1.25kb payload that gets populated with queued chunks. To go back into speculation land, I bet they're cramming what they can into a 1500 byte max MTU with some wiggle room to avoid fragmentation, which means the true maximum bandwidth of the game is 3.75KBbps if someone wanted to include all possible overhead.
I'm also curious what kind of packet is being sent to the server to get it to spit one out sooner. If it's just an empty packet then I worry about it being atypical and causing the server to error/log it. If it's a player input packet of some sort I actually worry less because there'll just be more of them.
I'm also curious what kind of packet is being sent to the server to get it to spit one out sooner. If it's just an empty packet then I worry about it being atypical and causing the server to error/log it. If it's a player input packet of some sort I actually worry less because there'll just be more of them.
[+]
Asura.Raelia said: »
I'm also curious what kind of packet is being sent to the server to get it to spit one out sooner. If it's just an empty packet then I worry about it being atypical and causing the server to error/log it. If it's a player input packet of some sort I actually worry less because there'll just be more of them.
I'd expect the server is smart enough to discard any packets that are abnormal or don't pass basic parsing. I also think Thorny mentioned position packets earlier, my assumption being these are typically high frequency, small size packets that would not raise alarm (I'd also assume both server/client have some form of keepalive, but maybe position fills that role also)
Asura.Raelia said: »
max MTU
Never realized until now that this was RAS Syndrome.
-client sends a udp packet every 400ms under normal conditions
-this contains a 0x15 chunk, which is auto generated and includes your position, amount of movement, current target, last received sequencing id, etc. any actions youve taken since the last packet get appended to it
-server responds with a udp packet containing pending chunks and a sequencing id
the plugin alters the clients logic so that if you have received a server-client packet since the last client-server packet you sent, and 250ms have elapsed, this 400ms window is considered met
the client will generate the 0x15 entirely on its own, appending anything thats pending, the plugin only alters the timings. the higher frequency means more s>c chunks are sent out prior to being discarded
any additional cpu burden on the server would be from the greater frequency allowing for more position updates from both the player using the plugin to other players, and from mobs/other players to the player using the plugin. attacks, actions, etc.. would not be sent again. in most models this is not a significant burden, but we cant be 100% sure since distance calculations can be costly if applied to many other targets each movement packet
-this contains a 0x15 chunk, which is auto generated and includes your position, amount of movement, current target, last received sequencing id, etc. any actions youve taken since the last packet get appended to it
-server responds with a udp packet containing pending chunks and a sequencing id
the plugin alters the clients logic so that if you have received a server-client packet since the last client-server packet you sent, and 250ms have elapsed, this 400ms window is considered met
the client will generate the 0x15 entirely on its own, appending anything thats pending, the plugin only alters the timings. the higher frequency means more s>c chunks are sent out prior to being discarded
any additional cpu burden on the server would be from the greater frequency allowing for more position updates from both the player using the plugin to other players, and from mobs/other players to the player using the plugin. attacks, actions, etc.. would not be sent again. in most models this is not a significant burden, but we cant be 100% sure since distance calculations can be costly if applied to many other targets each movement packet
[+]
This plugin is awesome. Thanks a lot!
If I get banned for using it in few instances where I need it, then I don't care. I can understand lack of more content, but when I see something like this being possible to do by 1-3 people with no access to all the toys SE has access to, I just lose my temper. They could have done it so many years ago...
If I get banned for using it in few instances where I need it, then I don't care. I can understand lack of more content, but when I see something like this being possible to do by 1-3 people with no access to all the toys SE has access to, I just lose my temper. They could have done it so many years ago...
[+]
Kinda feels like that skeleton crew of a skeleton crew just doesn't know how to do modern programming imo
we can do all this stuff with external tools fixing the problems from the outside in, but these guys are hardfocused on fixing what they can from the inside out (which is not a bad idea, but that requires NOT being on a skeleton crew of a skeleton crew)
we can do all this stuff with external tools fixing the problems from the outside in, but these guys are hardfocused on fixing what they can from the inside out (which is not a bad idea, but that requires NOT being on a skeleton crew of a skeleton crew)
[+]
Matsui-P should get an intensive full-time English course to at least B2 to maybe C1 as part of a professional company training and speak to some persons of the Windower/Ashita community, then push to Yoshi-P and the CEO's to hire them freelance for a while. Can't even imagine what some people could accomplish if they just had the real back end on their hands. UX would be fixed in no time. You guys doing so much work around this game, it's astonishing. Great job actually posting this. Much love to all the devs and data miners out there!
[+]
All FFXI content and images © 2002-2024 SQUARE ENIX CO., LTD. FINAL
FANTASY is a registered trademark of Square Enix Co., Ltd.