Someone should shoot mah brain to stop it from pushing out ideas.

[Catalylia]

I recall an issue I had earlier with window shrinking when switching chars, and this made me realize there was another feature I think you had before that I don't know how to implement, but has the same issue.

I saw once on a server ages ago that had a sort of "quick loader" that excluded the music list from the loading process. I.E: you could log in a lot faster because you were not loading the music list each time.

The drawback was though that when you input the /loadmusiclist command to load the music, it kicked you back to the char select screen and shrunk the window.

I was wondering if there was a way to implement this Without this happening.

I recall this being because the client sends the DONE#% command out. Prob why it kicks you to the char select, since that is the thing AO does normally after you load music. Show you the char select.

The reason I ask about this is, as the amount of music AO servers can support expands, the longer and longer people will take to load their clients. Some people take three to four minutes for 400 songs.

....and then they DC.

Angst Ensues.

[OmniTroid]

100% feasible from the client's perspective. Loading times will, if the current plan succeeds, be reduced to a fraction of what they currently are. Character switching is also a planned client-side feature(there might even be a button). The new client will also not resize from character select to entering a server(because it makes no sense), which prevents all window-shrinking.

[Catalylia]

I was more talking about this for the music list loading in of itself. I am sure the client loading could be made faster, but generally speaking all the thing is loading is a txt file pointer for the music list form the serv. It's more connection speed that makes their load times slow as I can load my own server's near 500 song list in about a second. I was just wondering on this because it was a feature in serverD previously, ((Or still is and I don't know how to implement it.) But it could be made far better with the recent changes in code to avoid the window shrink.

Since this issue was solely about how the content from the server is loaded to the client, I figured it would be better to have this change be done at the server level. o.o The music list is always loaded last and is not generally necessary for the client to run o.o.

[OmniTroid]

The protocol itself is the problem, but it can be improved. Currently, the client loads 10 songs in every packet from the server. Because of this, the loading time for music equals;

(music/10) * latency

As you can see, latency and music are both factors to increase the loading time. If a server has 500 songs and a person has 200 ms ping(not unrealistic for a trans-atlantic connection),

50 * 200 ms = 10 seconds MINIMUM for something that roughly equals ~40kB

Now consider someone with a 500 ms delay

50 * 500 ms = 25 seconds MINIMUM

While it might be possible to postpone the music loading from the server, this would be a clunky hack at best.

[oldmud0]

Couldn't you just ignore song page requests and send all the pages at once?

[stonedDiscord]

i could, but i'm pretty sure packets would go lost and people would come and yell at me because the client stopped loading at whatever/54367436 songs

[oldmud0]

it's TCP, that can't happen

[stonedDiscord]

i know how TCP works but somehow it's dropping them anyway, even over 100MBit/s LAN connection in my testing setup

[oldmud0]

that's not right... something obviously wrong, or maybe bad order. maybe buffer is full

[Catalylia]

Is it dropping like random packets or is it just like "I'm connected but I dun't see no info even if it's coming in the wire like a herp derp."

[stonedDiscord]

i think it's because AO is just slow and ignores them if you send them too fast

[oldmud0]

maybe it's because TClientSocket just plain sucks

[stonedDiscord]

yes

closes issue even harder