BitShift
02-11-2003, 05:07 AM
Back when SoE changed the way encryption was handled, and Ratt "let loose the dogs of war", the basis of the outrage was that SoE had basically dug their own grave for an eventual windows version of SEQ to be released, because they had forced developers to switch to a non-passive form of decryption. (ie, you need to run some software on the windows machine in order for SEQ to work, so why not run ALL of the software on the windows machine?)
My understanding is that the most recent changes in the way the packets are compressed are basically a "good thing" as far as conserving bandwidth is concerned. But I'm also pretty sure that SoE's devs weren't shedding any tears over the new netcode conveniently breaking SEQ. My question is this:
In some ways, these most recent changes are yet another push by SoE towards digging their own grave in the non-passive direction. In another thread, Ratt expressed a certain amount of confidence in the dev's ability to crack this new netcode, but I doubt it's exactly a cake walk. So I'm sure more and more people with coding skills are asking themselves "why bother with all this encryption/compression bulls***?"
I'm sure we would all suffer from a public windows version of SEQ being released, but I doubt anyone would suffer from it more than SoE would. Because of that, SoE (in my opinion) should be more careful of how far they push in the non-passive direction. I'm curious as to what opinions the rest of you have about this. Does SoE -deserve- to have a WinSEQ released as a result of their changes?
To make this all seem a little bit more "real", let me say this: I have little coding experience, and some might even venture to call me a 'script kiddie.' But regardless of that, In only one day I was able to take the features of MacroQuest, combine them with visual basic, and have what amounts to a one-frame-at-a-time-windows-SEQ.
If you enable the telnet server in MQ, you can use it to allow a windows-based program to communicate with EQ over tcp. I won't be posting the code for that. On the MQ side, all you need to do is write a short macro. Mine looks like this:
#turbo 10
Sub Main
/filter macros none
/varset l0 $id(0)
/varset l1 0
:Loop
/varadd l1 1
/echo WINSEQ,$l1,$spawn($l0,name,clean) $spawn($l0,surname),$spawn($l0,level),$spawn($l0,c lass),$spawn($l0,race),$spawn($l0,gender),$spawn($ l0,x),$spawn($l0,y),$spawn($l0,z)
/varset l0 $spawn($l0,next)
/delay 0
/if $l0>0 /goto :Loop
/filter macros all
/return
On the windows side, you just parse through any line containing "WINSEQ" and add the details (name, level, class, etc) to the spawnlist, then just draw all of the spawns on the screen. Granted, it's not automatically updated, you need to re-run the macro anytime you want updated positions, etc.. But the fact remains: it's much easier to read the spawnlist from memory than it is to decode their encrypted/compressed network data. And if it is THIS easy to do, wouldn't it be in SoE's best interests to keep a passive SEQ viable?
My understanding is that the most recent changes in the way the packets are compressed are basically a "good thing" as far as conserving bandwidth is concerned. But I'm also pretty sure that SoE's devs weren't shedding any tears over the new netcode conveniently breaking SEQ. My question is this:
In some ways, these most recent changes are yet another push by SoE towards digging their own grave in the non-passive direction. In another thread, Ratt expressed a certain amount of confidence in the dev's ability to crack this new netcode, but I doubt it's exactly a cake walk. So I'm sure more and more people with coding skills are asking themselves "why bother with all this encryption/compression bulls***?"
I'm sure we would all suffer from a public windows version of SEQ being released, but I doubt anyone would suffer from it more than SoE would. Because of that, SoE (in my opinion) should be more careful of how far they push in the non-passive direction. I'm curious as to what opinions the rest of you have about this. Does SoE -deserve- to have a WinSEQ released as a result of their changes?
To make this all seem a little bit more "real", let me say this: I have little coding experience, and some might even venture to call me a 'script kiddie.' But regardless of that, In only one day I was able to take the features of MacroQuest, combine them with visual basic, and have what amounts to a one-frame-at-a-time-windows-SEQ.
If you enable the telnet server in MQ, you can use it to allow a windows-based program to communicate with EQ over tcp. I won't be posting the code for that. On the MQ side, all you need to do is write a short macro. Mine looks like this:
#turbo 10
Sub Main
/filter macros none
/varset l0 $id(0)
/varset l1 0
:Loop
/varadd l1 1
/echo WINSEQ,$l1,$spawn($l0,name,clean) $spawn($l0,surname),$spawn($l0,level),$spawn($l0,c lass),$spawn($l0,race),$spawn($l0,gender),$spawn($ l0,x),$spawn($l0,y),$spawn($l0,z)
/varset l0 $spawn($l0,next)
/delay 0
/if $l0>0 /goto :Loop
/filter macros all
/return
On the windows side, you just parse through any line containing "WINSEQ" and add the details (name, level, class, etc) to the spawnlist, then just draw all of the spawns on the screen. Granted, it's not automatically updated, you need to re-run the macro anytime you want updated positions, etc.. But the fact remains: it's much easier to read the spawnlist from memory than it is to decode their encrypted/compressed network data. And if it is THIS easy to do, wouldn't it be in SoE's best interests to keep a passive SEQ viable?