Runes of Magic US / AU

Quoted from "mnkmurphy885;504791"

Isn't 150 an even number? 75 + 75 = 150, no? Although, this is Froggy we're talking about, so if anyone could break the laws of the time-space continuum, it would be them lol. I guess we'll just have to see if we have issues tonight.

.......Sometimes it seems i don't think...like right now..haha sorry about that. You are right. The limit is 160 still though but if i was able to think 150 was an odd number i might want to go and recount before i feel like a bigger idiot.

Checked 2 more times, still end up with 160 so i am safe on that part hehe.

Quoted from "flyingltj;504792"

By this same logic, positioning a tornado in such a way to hit buildings through walls is perfectly acceptable.

Plus I never said exploit, you did.

Being without shame & playing dirty doesnt always involve exploiting.

That's an interesting idea, actually. I've never seen anyone use the herald tornado to take down a building inside a castle. I guess, if they know where your factories are, they've already been inside, and using it that way would be risky, because if you didn't get it aimed just right you'd end up wasting a tornado and taking out a stable or something by accident. Sounds doable but wasteful and yeah, kinda shameless. Getting the tornado placed just right to max the damage on the gate, which is what it was created for, strikes me more as clever and good strategy rather than shamelessness.

I'm with you on the "shameless =/= exploit" thing- some things are just rude and unnecessary, even if they are legit. In my opinion, flame towers on the castle roof fall into that category. You have a whole castle to deck out with flames in places where any class can run up and target them; putting them in an unassailable place strikes me as low.

I guess shame is in the eye of the beholder though- when we come across guilds that flame the roof, I groan, but I don't call haxx or necessarily think ill of them. At this point, scouts can still take them out; if they actually make the LoS thing work they'll be a real pain in the bum. Even then, they wouldn't prevent a guild from winning, they'd just drag siege out for a whole hour.

Quoted from "mnkmurphy885;504795"

That's an interesting idea, actually. I've never seen anyone use the herald tornado to take down a building inside a castle. I guess, if they know where your factories are, they've already been inside, and using it that way would be risky, because if you didn't get it aimed just right you'd end up wasting a tornado and taking out a stable or something by accident. Sounds doable but wasteful and yeah, kinda shameless. Getting the tornado placed just right to max the damage on the gate, which is what it was created for, strikes me more as clever and good strategy rather than shamelessness.

I'm with you on the "shameless =/= exploit" thing- some things are just rude and unnecessary, even if they are legit. In my opinion, flame towers on the castle roof fall into that category. You have a whole castle to deck out with flames in places where any class can run up and target them; putting them in an unassailable place strikes me as low.

I guess shame is in the eye of the beholder though- when we come across guilds that flame the roof, I groan, but I don't call haxx or necessarily think ill of them. At this point, scouts can still take them out; if they actually make the LoS thing work they'll be a real pain in the bum. Even then, they wouldn't prevent a guild from winning, they'd just drag siege out for a whole hour.

Back before the days when 1 player could, by themselves, rub a castle gate with a wet noodle and burn it down in a matter of seconds such things used to happen frequently. Just not so often anymore.

Quoted from "mnkmurphy885;504795"

In my opinion, flame towers on the castle roof fall into that category. You have a whole castle to deck out with flames in places where any class can run up and target them; putting them in an unassailable place strikes me as low.

When you play against guilds using exploits, flames planted on the roof are a must, as we learned few sieges ago.

Check out this fine example, as they landed on our castle roof and killed guy at spawn point (none of our gates went down during that siege)
http://a2.sphotos.ak.fbcdn.net/hphotos-a…081640543_n.jpg

Quoted from "gstnet;504857"

Check out this fine example from *removed so the FM won't have to* guild on Indigo server, as they landed on our castle roof and killed guy at spawn point (none of our gates went down during that siege)
http://a2.sphotos.ak.fbcdn.net/hphotos-a…081640543_n.jpg

Hmm, I'm kinda glad I saw that post before the FM's remove the guild name, because that screenie isn't really conclusive proof of them flyhacking. People frequently look like that whenever they res and start crashing/lag. That same effect is easily duplicated just by a visual bug.

However, since you mentioned that guild by name (which is against the forum rules ) I can say that they do have quite the reputation for such hijinks, and the chat log that's visible in the screenie is pretty inflammatory. My advice would be to have someone in guild with decent framerate and a stable system get either Fraps or Magic Hub and record them actually falling through the sky, which is typically what that hack looks like when they use it. It's about time they got hit with the banhammer, but screenies aren't enough, you need a good long video for the GM's to look at.

A lot of the time people complain about hacks, and in my experience anyway, real hackers are starting to get pretty thin on the ground- but like I said, these guys have a rep, and all the GM's need is a well-frapsed view of a siege against them, and I bet you dollars to donuts they'll get banned into the stone age.

Quoted from "flyingltj;504800"

Back before the days when 1 player could, by themselves, rub a castle gate with a wet noodle and burn it down in a matter of seconds such things used to happen frequently. Just not so often anymore.

I never saw it happen even then, to be honest. Back in those days, a scout or mage could just kill the pfactory through the walls and *poof* bye bye pfactory. Why waste a herald skill on something a player could do more effectively? That's really why I wish the LoS in siege would go away- we had all more or less adjusted and just invised buildings to prevent that from happening. If they want to take your pfacts down now they have to actually come in and get them, but it was that way already as long as you used the invis.

I can accept the walls and gates being made of swiss cheese as long as all the ranged classes can kill- as it is, scouts and m/d's and r/s's and wd/s's can do damage through gates- but the rest of us can't shoot back. Someone said that it was mostly x/scout elite skills that can do the shoot-through trick, but my Ice Blade is an x/scout elite, and I get LoS'd all the darned time.

Everyone or no one. This half can, half can't thing is the pits.

The incident with more actual evidence has been reported few days ago and F will or will not deal with it, which is not relevant to the topic at hand. I just posted this here as the graphic explanation why sometimes it might make sense to keep few flame towers on the roof - it does not hurt and obviously it might help.

Especially when i've seen some people try to place treaches on that spot (prior to the permaflop nerf)

Frogster i see it was a great idea to move the servers from the west coast to east coast. And ur supposed "fix" to siege lag is great. I now take 5 mins as opposed to 3 mins since the move. GREAT JOB FA!!!! Keep up the geat work. (sarcasm)

Siege was still laggy today, got in about half way through siege and at first i had about a 1second delay then progressively got worse and by the end of siege i had about a 10second delay.

.

We managed to take Crystal and end it early. Lag was real bad. 44 sec for server response at Factory.

Guild chat did not appear to have any lag.

Many crashed as Seige ended.

Some has more lag issues others. Some with bad lag got dumped and then had none when they got back in. Others had worse lag when they got back in after getting dumped.

Tracerts from throughout Seige with time and lag time notations between:
As you can see no real change in tracert response times.

Lag times were arrived at by opening Factory, starting stopwatch once I clicked Honor Building button, the stopping it when shop window opened.

I and several other in guild left seige about 45 sec after it ended for others.


1) 4 Min to Seige start

C:\Users\Owner\Desktop>tracert 206.253.173.53
Tracing route to 206.253.173.53 over a maximum of 30 hops
1 12 ms 3 ms 6 ms www.routerlogin.com [XXX.XXX.XXX.XXX]
2 33 ms 31 ms 21 ms c-XXX-XXX-XXX-XXX.hsd1.il.comcast.net [XXX.XXX.XXX.XXX]
3 37 ms 13 ms 14 ms te-1-1-ur04.XXXXX.il.chicago.comcast.net [XXX.XXX.XXX.XXX]
4 23 ms 32 ms 35 ms be-60-ar01.area4.il.chicago.comcast.net [68.87.2
30.41]
5 20 ms 28 ms 21 ms pos-3-9-0-0-cr01.350ecermak.il.ibone.comcast.net
[68.86.90.45]
6 121 ms 112 ms 115 ms pos-1-4-0-0-cr01.chicago.il.ibone.comcast.net [6
8.86.88.33]
7 45 ms 44 ms 43 ms xe-9-2-0.edge1.Chicago2.Level3.net [4.71.248.25]
8 38 ms 45 ms 43 ms vlan52.ebr2.Chicago2.Level3.net [4.69.138.190]
9 40 ms 46 ms 44 ms ae-5-5.ebr2.Chicago1.Level3.net [4.69.140.193]
10 63 ms 69 ms 68 ms ae-3-3.ebr2.Atlanta2.Level3.net [4.69.132.74]
11 87 ms 80 ms 102 ms ae-2-2.ebr2.Miami1.Level3.net [4.69.140.141]
12 51 ms 48 ms 122 ms ae-2-52.edge2.Miami1.Level3.net [4.69.138.102]
13 71 ms 66 ms 59 ms VAULT-NETWO.edge2.Miami1.Level3.net [4.30.20.2]
14 50 ms 50 ms 55 ms po1-car4.vaultnetworks.com [206.253.168.158]
15 54 ms 51 ms 52 ms 206.253.173.53
Trace complete.


2) 10 min into SW

C:\Users\Owner\Desktop>tracert 206.253.173.53
Tracing route to 206.253.173.53 over a maximum of 30 hops
1 7 ms 3 ms 9 ms www.routerlogin.com [XXX.XXX.XXX.XXX]
2 52 ms 33 ms 23 ms c-XXX-XXX-XXX-XXX.hsd1.il.comcast.net [XXX.XXX.XXX.XXX]
3 10 ms 13 ms 13 ms te-1-1-ur04.XXXXX.il.chicago.comcast.net [XXX.XXX.XXX.XXX]
4 37 ms 20 ms 39 ms be-60-ar01.area4.il.chicago.comcast.net [68.87.2
30.41]
5 21 ms 29 ms 17 ms pos-3-9-0-0-cr01.350ecermak.il.ibone.comcast.net
[68.86.90.45]
6 20 ms 21 ms * pos-1-4-0-0-cr01.chicago.il.ibone.comcast.net [6
8.86.88.33]
7 23 ms 23 ms 19 ms xe-9-2-0.edge1.Chicago2.Level3.net [4.71.248.25]
8 17 ms 33 ms 25 ms vlan52.ebr2.Chicago2.Level3.net [4.69.138.190]
9 38 ms 24 ms 38 ms ae-5-5.ebr2.Chicago1.Level3.net [4.69.140.193]
10 34 ms 37 ms 63 ms ae-3-3.ebr2.Atlanta2.Level3.net [4.69.132.74]
11 53 ms 53 ms 52 ms ae-2-2.ebr2.Miami1.Level3.net [4.69.140.141]
12 105 ms 52 ms 50 ms ae-2-52.edge2.Miami1.Level3.net [4.69.138.102]
13 59 ms 51 ms 54 ms VAULT-NETWO.edge2.Miami1.Level3.net [4.30.20.2]
14 55 ms 152 ms 56 ms po1-car4.vaultnetworks.com [206.253.168.158]
15 73 ms 51 ms 53 ms 206.253.173.53
Trace complete.



3) 17 min in Lag starting Several Second delay

C:\Users\Owner\Desktop>tracert 206.253.173.53
Tracing route to 206.253.173.53 over a maximum of 30 hops
1 25 ms 80 ms 3 ms www.routerlogin.com [XXX.XXX.XXX.XXX]
2 41 ms 35 ms 52 ms c-XXX-XXX-XXX-XXX.hsd1.il.comcast.net [XXX.XXX.XXX.XXX]
3 28 ms 15 ms 52 ms te-1-1-ur04.XXX.il.chicago.comcast.net [XXX.XXX.XXX.XXX]
4 15 ms 60 ms 30 ms be-60-ar01.area4.il.chicago.comcast.net [68.87.2
30.41]
5 20 ms 19 ms 36 ms pos-3-9-0-0-cr01.350ecermak.il.ibone.comcast.net
[68.86.90.45]
6 25 ms 19 ms 40 ms pos-1-4-0-0-cr01.chicago.il.ibone.comcast.net [6
8.86.88.33]
7 19 ms 20 ms 16 ms xe-9-2-0.edge1.Chicago2.Level3.net [4.71.248.25]
8 21 ms 23 ms 21 ms vlan52.ebr2.Chicago2.Level3.net [4.69.138.190]
9 21 ms 20 ms 27 ms ae-5-5.ebr2.Chicago1.Level3.net [4.69.140.193]
10 51 ms 35 ms 35 ms ae-3-3.ebr2.Atlanta2.Level3.net [4.69.132.74]
11 58 ms 50 ms 51 ms ae-2-2.ebr2.Miami1.Level3.net [4.69.140.141]
12 65 ms 89 ms 119 ms ae-2-52.edge2.Miami1.Level3.net [4.69.138.102]
13 88 ms 66 ms 54 ms VAULT-NETWO.edge2.Miami1.Level3.net [4.30.20.2]
14 48 ms 49 ms 52 ms po1-car4.vaultnetworks.com [206.253.168.158]
15 73 ms 64 ms 67 ms 206.253.173.53
Trace complete.


4) 30 Min in mild lag gettin worse

C:\Users\Owner\Desktop>tracert 206.253.173.53
Tracing route to 206.253.173.53 over a maximum of 30 hops
1 3 ms 6 ms 20 ms www.routerlogin.com [XXX.XXX.XXX.XXX]
2 55 ms 32 ms 23 ms c-XXX-XXX-XXX-XXX.hsd1.il.comcast.net [XXX.XXX.XXX.XXX]
3 23 ms 18 ms 13 ms te-1-1-ur04.XXXXX.il.chicago.comcast.net [XXX.XXX.XXX.XXX]
4 27 ms 22 ms 19 ms be-60-ar01.area4.il.chicago.comcast.net [68.87.2
30.41]
5 17 ms 20 ms 18 ms pos-3-9-0-0-cr01.350ecermak.il.ibone.comcast.net
[68.86.90.45]
6 26 ms 18 ms 21 ms pos-1-4-0-0-cr01.chicago.il.ibone.comcast.net [6
8.86.88.33]
7 35 ms 29 ms 24 ms xe-9-2-0.edge1.Chicago2.Level3.net [4.71.248.25]
8 37 ms 27 ms 50 ms vlan52.ebr2.Chicago2.Level3.net [4.69.138.190]
9 27 ms 61 ms 25 ms ae-5-5.ebr2.Chicago1.Level3.net [4.69.140.193]
10 34 ms 42 ms 44 ms ae-3-3.ebr2.Atlanta2.Level3.net [4.69.132.74]
11 67 ms 61 ms 110 ms ae-2-2.ebr2.Miami1.Level3.net [4.69.140.141]
12 169 ms 57 ms 54 ms ae-2-52.edge2.Miami1.Level3.net [4.69.138.102]
13 56 ms 62 ms 55 ms VAULT-NETWO.edge2.Miami1.Level3.net [4.30.20.2]
14 54 ms 107 ms 53 ms po1-car4.vaultnetworks.com [206.253.168.158]
15 54 ms 60 ms 55 ms 206.253.173.53
Trace complete.



5) 40 min into SW 36 sec for response from server

C:\Users\Owner\Desktop>tracert 206.253.173.53
Tracing route to 206.253.173.53 over a maximum of 30 hops
1 17 ms 6 ms 2 ms www.routerlogin.com [XXX.XXX.XXX.XXX]
2 41 ms 23 ms 31 ms c-XXX-XXX-XXX-XXX.hsd1.il.comcast.net [XXX.XXX.XXX.XXX]
3 11 ms 16 ms 13 ms te-1-1-ur04.XXXX.il.chicago.comcast.net [XXX.XXX.XXX.XXX]
4 33 ms 26 ms 23 ms be-60-ar01.area4.il.chicago.comcast.net [68.87.2
30.41]
5 53 ms 17 ms 143 ms pos-3-9-0-0-cr01.350ecermak.il.ibone.comcast.net
[68.86.90.45]
6 79 ms 30 ms 22 ms pos-1-4-0-0-cr01.chicago.il.ibone.comcast.net [6
8.86.88.33]
7 56 ms 29 ms 69 ms xe-9-2-0.edge1.Chicago2.Level3.net [4.71.248.25]
8 27 ms 38 ms 47 ms vlan52.ebr2.Chicago2.Level3.net [4.69.138.190]
9 55 ms 32 ms 29 ms ae-5-5.ebr2.Chicago1.Level3.net [4.69.140.193]
10 36 ms 50 ms 38 ms ae-3-3.ebr2.Atlanta2.Level3.net [4.69.132.74]
11 69 ms 75 ms 123 ms ae-2-2.ebr2.Miami1.Level3.net [4.69.140.141]
12 103 ms 81 ms 51 ms ae-2-52.edge2.Miami1.Level3.net [4.69.138.102]
13 50 ms 50 ms 52 ms VAULT-NETWO.edge2.Miami1.Level3.net [4.30.20.2]
14 59 ms 75 ms 59 ms po1-car4.vaultnetworks.com [206.253.168.158]
15 73 ms 56 ms 60 ms 206.253.173.53
Trace complete.


6) 50 min into SW 44 sec lag

C:\Users\Owner\Desktop>tracert 206.253.173.53
Tracing route to 206.253.173.53 over a maximum of 30 hops
1 6 ms 21 ms 5 ms www.routerlogin.com [XXX.XXX.XXX.XXX]
2 53 ms 72 ms 32 ms c-XXX-XXX-XXX-XXX.hsd1.il.comcast.net [XXX.XXX.XXX.XXX]
3 15 ms 18 ms 25 ms te-1-1-ur04.XXXXX.il.chicago.comcast.net [XXX.XXX.XXX.XXX]
4 18 ms 18 ms 19 ms be-60-ar01.area4.il.chicago.comcast.net [68.87.2
30.41]
5 42 ms 53 ms 18 ms pos-3-9-0-0-cr01.350ecermak.il.ibone.comcast.net
[68.86.90.45]
6 18 ms 16 ms 59 ms pos-1-4-0-0-cr01.chicago.il.ibone.comcast.net [6
8.86.88.33]
7 25 ms 18 ms 19 ms xe-9-2-0.edge1.Chicago2.Level3.net [4.71.248.25]
8 17 ms 18 ms 22 ms vlan52.ebr2.Chicago2.Level3.net [4.69.138.190]
9 41 ms 16 ms 36 ms ae-5-5.ebr2.Chicago1.Level3.net [4.69.140.193]
10 47 ms 38 ms 64 ms ae-3-3.ebr2.Atlanta2.Level3.net [4.69.132.74]
11 49 ms 49 ms 53 ms ae-2-2.ebr2.Miami1.Level3.net [4.69.140.141]
12 48 ms 53 ms 86 ms ae-2-52.edge2.Miami1.Level3.net [4.69.138.102]
13 55 ms 69 ms 84 ms VAULT-NETWO.edge2.Miami1.Level3.net [4.30.20.2]
14 59 ms 57 ms 51 ms po1-car4.vaultnetworks.com [206.253.168.158]
15 49 ms 53 ms 50 ms 206.253.173.53
Trace complete.
C:\Users\Owner\Desktop>


.

Siege was fine for us until the last 15 minutes.. Lag slowly started then and one person got kicked out to login screen at the end. Still everyone got rewards. Judging on a world chat, it seems we were the lucky ones this time around.

Ping statistics for 206.253.173.53:
Packets: Sent = 3600, Received = 3586, Lost = 14 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 41ms, Maximum = 1201ms, Average = 84ms

ping spiked around the 20 minute mark to a whopping 140-200ms (opposed to the 40-80ms) and settled down about 15-20 minutes into that spike.
What does that mean? Something started using the network at roughly 10:20 PM EST, very likely a network backup aka lots of disk access and processing if there is software encryption going on. Do I need to say it again? Consulting fees aren't cheap

First 30 minutes of siege worked fine, but than the delay came fast. Within 10 minutes, it was unplayable at 2 minute delay.

This is NOT a move to Miama issue or a latency to the server issue at least not in my case and what our guild is seeing. The latency to the server has stayed essentially the same. However there seems to be a good percentage of the Siege population, (about 70% of my guildmates) that cannot siege at all due to this Server Lag.
I am from the West Coast and the one day that I was in siege I was not feeling this effect whatsoever but at least 70% of my guildmates were. Their spells would take MINUTES to cast, they would see things that happened currently for me, minutes in the future.
This almost seems as if ROM is using multiple servers as one big siege engine and one of those servers is having issues, maybe therefor not effecting everyone in siege but those who happened to get into siege on that one server are. I dont know if that makes any sense at all but this is a very real problem. Our guild has not sieged since the second time this issue has risen after the last patch and we are a level 12 guild that sieges every day on a regular basis.

Today we took down Battleground servers for some changes again (http://forum.us.runesofmagic.com/showthr…ll=1#post504969). Hopefully the changes we have made will improve the stability in Siege War tonight. Please let us know how it goes.

Quoted from "Roeksha;504997"

Today we took down Battleground servers for some changes again (http://forum.us.runesofmagic.com/showthr…ll=1#post504969). Hopefully the changes we have made will improve the stability in Siege War tonight. Please let us know how it goes.

http://img710.imageshack.us/img710/3050/…12012522580.jpg

It's siege and anything combat related that's giving this outrageous ping.

i had never suffered such things on previous server. i might have to go on a long break until this is fixed completely.

I am no pro but this problem happened after the servers move, not i can not say that is the reason but after the servers move the game time got changed to being 3 mins behind the real life time. I was wondering if the game time being behind could have anything to do with this. 2 servers might have different times making a problem and having a delay for players.

Quoted from "kingzamorak;505038"

I am no pro but this problem happened after the servers move, not i can not say that is the reason but after the servers move the game time got changed to being 3 mins behind the real life time. I was wondering if the game time being behind could have anything to do with this. 2 servers might have different times making a problem and having a delay for players.

It's a good theory but not likely, or else the lag would be all throughout siege, not just 20 minutes in. Something is using the resources of the server causing ping timeouts and actual lag in the clients connected to it. The server is still able to process some people through, but that amount and which client is random. As I said, this is client-server architecture 101.

For contrast, Saturday night when our guild was able to Siege, I was one of the ones lagging, and I was also the herald. that night, I pushed Fearless and Thunder force and both got to me in about 5 minutes. Kingz, above, was one of the players not lagging that night and reported that he got the buffs almost instantly after I pushed them.

Last night, I was herald as well, and I didn't lag, and Kingz did. (as a matter of fact, there was 4? out of 18 players connected to SW that were not lagging.

We don't need a 'my gosh I hope this works', we need a 'man, this will work'. People have suggested the Siege war servers be taken offline. I support this. If something is seriously broke, you fix it.

But, in Frogster's/RW's world, this seems to be the opposite, if it's broke, you don't fix it and keep hoping it works the next time. If it isn't broke, you fix it so that it's broke, and then you don't fix it.

You cannot run a game server on hopes and dreams, people.

Quoted from "Jguy;505042"

It's a good theory but not likely, or else the lag would be all throughout siege, not just 20 minutes in. Something is using the resources of the server causing ping timeouts and actual lag in the clients connected to it. The server is still able to process some people through, but that amount and which client is random. As I said, this is client-server architecture 101.

For contrast, Saturday night when our guild was able to Siege, I was one of the ones lagging, and I was also the herald. that night, I pushed Fearless and Thunder force and both got to me in about 5 minutes. Kingz, above, was one of the players not lagging that night and reported that he got the buffs almost instantly after I pushed them.

Last night, I was herald as well, and I didn't lag, and Kingz did. (as a matter of fact, there was 4? out of 18 players connected to SW that were not lagging.

We don't need a 'my gosh I hope this works', we need a 'man, this will work'. People have suggested the Siege war servers be taken offline. I support this. If something is seriously broke, you fix it.

But, in Frogster's/RW's world, this seems to be the opposite, if it's broke, you don't fix it and keep hoping it works the next time. If it isn't broke, you fix it so that it's broke, and then you don't fix it.

You cannot run a game server on hopes and dreams, people.

I run servers for a living, I'm paid to do what I do. Yet I can't seem to beat the nail through the CM/GM skulls that they need to have their server admin look at something OTHER than the configuration of siege software.