Network Code Changes for LoY Release.

[Proxeneta]

If anyone needs an old eqgame.exe that can work with SEQ or MQ, to find offsets, ect. Go to

http://prdownloads.sourceforge.net/e...r.exe?download

Download the EQemu patcher, and If you dont want your EQ files to be outdated, copy your everquest dir into another dir.

Run the patcher to get an old Eqgame.exe that you can work with.

(you can't use this eqgame.exe to play...you know that)

[Jaerin]

Originally posted by Ratt
I'm going to dispell some common misconceptions...



And every one of those that tells you that should be summarily fired for being a moron and not knowing his or her business.

Obfuscation is a perfectly valid, well known and accepted security method.

Yes it is a valid form of security, but should not be the only form. That's all I'm saying. No SEQ hasn't been intentionally hidden from view to avoid visibility. SOE knows about it and won't forget about it just because a handful of people are still using it. No it might not be cost effective to directly change things to cause SEQ to break, but if they notice changes that would break SEQ all the better.

All I'm saying is taking an arrogant "Your too stupid to run SEQ" or "Only the leet will be able to use it" attitude is unneeded and annoying. I'm reading the exact same thing over on the MQ boards.

Thier project was created in Visual C++ 7 and has problems compiling under Visual C++ 6. At least one particular mod on the boards over there has been intentionally trashing all threads that give any kind of guide on how to make it work. Why? Because he's abusing his power and has that "You're too lazy attitude"

Yes there are lazy people that want to be spoon fed, but for those that are actually trying to do it themselves, they don't need to get flak everytime they ask a question.

So you could say that he's not deleting the question threads, just the guide threads. What's the difference? If your going to allow people to answer the same question over and over again why not allow a guide?

I don't see that attitude quite so bad over here, but it has been a lot more evident lately and it just continues to go unchecked. It's one thing for an angst ridden admin that's answered every question imagineable 100 times to be pissy, but lately it's been spreading to the new people. There seems to be rarely a post lately that doesn't have at least one flame, if not many, in it.

So take few days and cool off a bit. Life will go on with or without SEQ working. Being pissy and flaming isn't going to get it fixed any faster.

Jaerin

[uncleubb]

Originally posted by Jaerin


All I'm saying is taking an arrogant "Your too stupid to run SEQ" or "Only the leet will be able to use it" attitude is unneeded and annoying. I'm reading the exact same thing over on the MQ boards.

Don't take this as a flame, but the elitist stance can be useful.

For example, my understanding is that this was part of the "social contract" between SEQ and the SOE EQ developers. SEQ's side of this was to make it somewhat difficult to get the program up and running. This was a conscious decision by the developers and definitely elitist. In return, SOE developers were to allow SEQ to exist as it was.

However, per Ratt (and as is obvious to all) this contract was broken by SOE. The contract has been argued ad naseum elsewhere. Because of this, and other reasons, it has been argued that the elitist position is no longer needed (ie, bring on the WinSEQ).

The elitist position gave some protection to SOE by limiting quantity of SEQ users, so while the contract was in force, it was needed.

In any event, I don't think long downtimes like this last one will continue for very much longer. Longer term solutions are brimming... Whether said solutions are elitist or available at a click will likely be up to developer of the solution.

[Amadeus]

I'm just glad that the application is available period. I don't have time to develop it myself because I actually enjoy playing the game (with SEQ anyway).

I'd pay for SEQ, np...especially if it were a lifetime lisence for upgrades, etc... Hell, it might motivate them to develop for EQ2 as well.

[CybMax]

For example, my understanding is that this was part of the "social contract" between SEQ and the SOE EQ developers. SEQ's side of this was to make it somewhat difficult to get the program up and running. This was a conscious decision by the developers and definitely elitist. In return, SOE developers were to allow SEQ to exist as it was

A "real" thing? Or just another suspicion?

[uncleubb]

Originally posted by CybMax


A "real" thing? Or just another suspicion?

I'll let you decide for yourself by reading this thread. (http://seq.sourceforge.net/showthrea...&threadid=2523).

-uu

[baelang]

Originally posted by Magao
Anyone got it working on an HP-48SX? Any help would be appreciated thanks in advance

mahalo and aloha you very much

Magao

I just sold my 28s, or i would have gladly helped in that effort.

[SilentVoice]

This is in reference to Ratt's post about a window's program. I am familiar with windows programming and socket programming. I am not however familiar enough with the SEQ source to attempt writing a program that sends this data to the SEQ machine.

Could someone outline a few cases as to what you would be looking for and what would trigger it (i.e. need to send the zone name to SEQ when a player zones)? Also if I were to do this, it would be best to figure out some kind of method to send the data across since we are doing much more here than just sending the decryption key.

[Jillian]

Originally posted by SilentVoice
it would be best to figure out some kind of method to send the data across since we are doing much more here than just sending the decryption key.

let's encrypt compressed encrypted data sent to our seq boxes that way SOE will have a hard time in case they decide to sniff our outgoing packets

[lostinspace]

SilentVoice, as you already noticed, what you need is that someone who is familiar with SEQ source change SEQ so that it can accept and use packets sent from win sniffer program for more than just key.

After that theoretical change in SEQ, whoever did it should detail what packet structure SEQ expects from snifer, something like:
- structure for zone and/or player info
- structure for spawn info
- structure for spawn position change
- structure for optional info (spawnID of active target etc...)

That would be starting point for any windows programer to use in their sniffer program. I already mentioned that few posts back ... but I did not expect any fast response, so I said I will make my own win version of seq (memory reading, not packet sniffing) untill real SEQ is back - which I did.

While such program did not need at all sending packets over network, I made option for packets to be sent to second instance of same program on second PC - just to see what would be really needed in any sniffer/SEQ communication ( well, and becouse some ppl used to 2nd PC asked for it

In doing that network option, I realised that it is not so simple as I originally thought. I met same problems that EQ developers probably had - how to efficiently transfer data about all spawns from server (PC1) to client (PC2) over bandwith limited network.

And it is limited, even if you are on 100MB LAN, because if you send more than 12 KB/sec of UDP data , receiving widows socket will start missing that data.

So I did following:

1) defined minimum length packet of 22 bytes, containing updateType, spawnID, dataType and data. Data structure depends on dataType, and i use 3 so far: 0= I send name in data bytes, 1= I send x/y/z/direction/speed in data bytes, 2= I send level, guild, class and few other info about spawn

2) defined several updateTypes:
INSERT: send all 3 dataType packets, with name, x/y/z and other info
UPDATE: send only dataType=1 packet, with new x/y/z
DELETE: send only dataType=0 packet, where i use spawnID only
KEYFRAME_ZONE: send only dataType=0 packet, where name is actually zone name
KEYFRAME_PLAYER: send dataType=0 packet, where name is player name

3) Insert packet is sent when i detect new spawn. UPDATE is sent only when x/y/z/dir changed, DELETE is sent when i detect that spawn dissapeared. All are reffering to spawnID

4) when KEYFRAME packet is received on PC2, I mark all existing spawns for deletion. When several keyframes are received without spawn info being updated with any normal Insert/Update packet, i delete that spawn on PC2. That is to ensure that even if one DELETE packet is missed, i will evelntually delete spawn

5) after KEYFRAME packet is sent on PC1 (which is done every 10sec for example, may be longer or never), I send INSERT packets for all spawns. That insures that even if some INSERT packets were missed, new spawns will eventually get sent to PC2. Steps 4&5 are optional, and just safeguard against missed UDP packets

6) I group up to 10 data packets of any type into one UDP network packet ... so optimising bandwith usage ( with 50ish byte header, sending 200 bytes is better than sending 20 bytes ).

7) algorithm for sending packets take into consideration not to exceed 10KB/s throughput , by calling step 7 no faster than 20ms apart.


Now, not everything of above needed to be done for data to be sent from server to client , but with above principle I got best results. I detailed this here so anyone willing to make SEQ side change can possibly use some of this info as help to decide what structures could be sent.... although I believe whoever decide to do it on SEQ side may model his packet types according to actual EQ packets types.

[baelang]

Originally posted by lostinspace

In doing that network option, I realised that it is not so simple as I originally thought. I met same problems that EQ developers probably had - how to efficiently transfer data about all spawns from server (PC1) to client (PC2) over bandwith limited network.

And it is limited, even if you are on 100MB LAN, because if you send more than 12 KB/sec of UDP data , receiving widows socket will start missing that data.

so why not use some form of TCP if you are worried abgout data loss? sure, the overhead is more with TCP than UDP but you should be able to optimize windowing and such to meet your performance requirements.

even at 10mbps you ought to keep up with EQ data easily without performance hits.

[Logic_Dingo]

TCP is strictly two way though isnt it? So the Showeq linux box would have to send data back to the windows box for confirmation of packets sent. That doesnt sound good :/

[high_jeeves]

Might want to recheck your code... I am sending zone info, item info, spawn info (new, update, delete, death packets are all seperate)... I run at less than 2KBps doing all of this (using UDP)... not exactly a drain on a 100Mbit network (or even a 10MBit network, for that matter)

I havnt had any real dataloss issues (I sequence my packets, and report any dropped packets). Generally, it is less than 1% packet loss...

--Jeeves

[KaL]

You guys with your workarounds, I bet everyone would love to get copies of what you're running.

Throw us a bone!

[baelang]

Originally posted by Logic_Dingo
TCP is strictly two way though isnt it? So the Showeq linux box would have to send data back to the windows box for confirmation of packets sent. That doesnt sound good :/

Yes, TCP sends acknowledgements back. that is the point of it. it does not send one ack per packet, it sends one ack per window.

but that is a good thing and it is what you want to do IF (and that is a very big if) you are worried about dropped packets.

if all you are running is EQ and SEQ and a router, you shouldn't be seeing enough of a load to have signifigant packet loss. if you are getting more than 1% packet loss, you may have bad cables or some sort of interference with your cables, or a malfunctioning hub or nic or some such. if that is the case make sure you aren't running ethernet cables close to power transformers, power cords, CRT monitors, or anything that produces a shifting EM field.