I'm a dickhead because garnering attention is the only way to get things done around here. I'm ok with being the bad guy.

This is the real story, and what is going to jump-start custom client development.

I don't care who likes or dislikes me, but THIS is important for the development community.

If you're talking about the post you made yesterday, that would fall under doing it wrong.

Repeatedly crashing clients on P99 is also doing it wrong.

How you should of reported it since you seem to be completely incapable of understanding:

That provides enough details so a dev can fix it, it also gives one details to build a plugin to cause problems for servers, but that's okay, we need to fix those things. The dev looking at the problem shouldn't have to open up your plugin in IDA to see what you're doing to cause crashes :P

It's deeper than that. Every instance of strlen() is sploitable.

Also in terms of r99/p99, Rogean and I don't exactly have open lines of communication.

He makes it to where I can't communicate with him, so I have to show him.

Have not and will not.

You called me names :P

I would only call you a pal for contributing posts in my thread, whether in agreement or disagreement.

Update:

Found how to crash anyone running macroquest by overflowing it in multiple ways.

Will release it on the forum at some point.

An crude example, guild id of 0 will crash MQ. Ofcourse you can turn off mq captions to bypass but this is an example

A lot of times when I post in here I use my posts as references so I can come back to it. So if it seems like I'm talking to myself, it's probably the case.

So anyway, we are pushing forward with custom client development whether Secrets decides she wants to be productive or not. Here is our current Prototype source (it's shit, but keeping things open to the community as always) http://eqbrowser.com/misc/EQLoginClient.zip


From my understanding, to properly send and receive an opcode and related packet we have to emulate TCP in UDP... i.e. 3 way Ack(nowledgement of packet) handshake.

Some data, like chat message packets, is sent encrypted but we have that part done.

We need the ack system, the tcp in udp bullshit, and we need the library to be 3 threads.

1 main thread, the packet processing consumer thread which we have written on our own.

What we need is a producer thread for incoming packets, and a consumer thread for outgoing packets, so there will be 2 shared "volatile" mutex'd stacks (incoming and outgoing packets)

It gets even more complicated since there needs to be 2 stacks for incoming and outgoing (aka 4 mutex'd stacks) because some packets don't need the Ack system like movement packets, and other physics based packets.

"whether Secrets decides she wants to be productive or not."

Sorry, really irrelevant, but Secrets is a girl? If so, badass. Glad to see a female coder / dev :P (I think KLS is to right, or no?)

Only if you believe Cavedude misinformation.

Sadly cavedude has yet to fail me....Maybe I should look into his information source more.

very nice!

Please share =)

As far as I am aware, KLS is a man. She told me this herself.

Unity3d Plugin, a bitcoin-miner that integrates within your game. Users generate bitcoins for you while playing.

You have to email them for early access contact@icoplay.com

http://icoplay.com/icominer-faq/

Trying to follow along here. I've been lurking since whenever this account was created. It really seems like Tyen has the right idea about handling the EQEmu client with Unity, in browser and all of that. Whether users know it yet or not, I think this is going to be the end-all Classic/Titanium/Whatever client killer.

Are secrets' c# skills the last big thing that's needed to push forward?

Thanks pal,

I made a page to update on the most recent roadblock in development.

http://eqbrowser.com/help/

First post is explaining what needs to be done with: unity-client to Eqemu-server. All the source is available.


Null is putting the prototype into the Unity project. There is a sentence in there about eqemuauthcrypto, we are probably going to change encryption to SSL. C++ DLLs are not allowed in Unity3d Webplayer. They are allowed for Desktop, so the new unity project will have that included so the project can still connect to an eqemu server pre-ssl. The encryption methods on the server will change depending on the client connecting to it.


Also if you are a unity guy, and are interested in a job @ pantheon, send your resume and cover letter to jobs@pantheonrotf.com

Huge news for Unity.

https://blog.mozilla.org/blog/2014/0...ne-to-the-web/

Seen that earlier today. Good news indeed!

Mormons approve of EQBrowser

http://i.imgur.com/8s2fECV.png

Null added our C# networking prototype to a fresh Unity project so we can try and build the networking part of the client. It's separate from the main build so the focus can be on point.

It's still shit, but it's a start.

https://github.com/eqbrowser/Network...Unity-to-Eqemu

My asset extractor pal made a video.

http://youtu.be/d6IZIoXocQA

Tutorial zone in Unity

This will create a menu item in Unity to make XML import happen for objects.

You have to make a prefab resource called "Dummy" in "Objects" directory (this must be located in a Resource directory). The rotations are in radians and not degrees. You may see multiplyers like "pos *= 0.3f", this is for scaling.

In case your scene is rotated you should rotate it, OR modify the script to replace coordinates or rotation parts. Depends on your project, really.

Unity XML Object Importer: http://eqbrowser.com/misc/EQObjectImporter.cs

This is an example of the XML: https://github.com/eqbrowser/Ecommon...20ECOMMONS.xml

Points of interrest:
- modells are in blender files and not fbx
- there are some good shaders you may like for transparency (ambient light is not handled, so works only at daylight)
- to run the project you need account for photon networking - free licence is good enough
- the modell (human male and a skeleton) is rigged for use with fbx animations. so if you take animation from other locomotion modell, that will work with this.

http://eqbrowser.com/images/tutorial.png

Awesome! So nice to see the updates.

Video of me poopsing the build, lol.

http://youtu.be/AOvH2fYhzM8

Terrible video of the first multiplayer test, terrible camera angle, super bad.

http://youtu.be/iH6odVs04PM

Still cool to see progress.

I put my "test" builds @ http://eqbrowser.com/trash/

It currently has multiplayer, but there is a lot of bugs you are going to find.

Right now the camera is stationary, if you get lost you can click the button on the top left that says "Safe Point" and it will warp you back to the camera.

Load multiple tabs if you want to see the multiplayer in action.

Everyone now spawns with their own camera, praise.

There will be the same 3 angles as EQ:F9/EQB:V1 at some point.


There is a bunch of stuff in v1 that isn't in v2 that I'll be swapping over. Jump for example.

Characters take wide turns on v2 and there is no animation for walking backward. You'll notice tons of weird bugs like that in the meantime, like no swimming.


http://eqbrowser.com/trash is the most recent test builds, all are multiplayer. Load up a few tabs and check yourself out.

lol

http://i.imgur.com/fqmYPIV.png

Ultimate FPS!

New build live.

Check it out @ http://eqbrowser.com/play

At a glance, it seems that Linux is still unsupported.

...Boo!

Good to hear of progress though!

Logging packets


Image:
http://i.imgur.com/TwelpQh.png

https://web.archive.org/web/20120111...ets/Encryption

https://web.archive.org/web/20130301...u/wiki/Packets

all of this is supposedly the exact same as eq.

Awesome progress!

> .net client framework for Eqemu

https://github.com/eqbrowser/unity-e...ient-framework

> README

.NET 3.5
No pinvokes
No use of Marshalling
100% managed eqemuauthcrypto implementation
- I had to override the default behavior of the DESCryptoServiceProvider. It has an internal check that is performed to
detect weak keys (aka, keys with terrible parity). By default, .NET won't let you use a crappy key (which is what the
emu uses prior to being patched). Put another way, I had to make DES even shittier to work with the emu!
- On this, more for information than anything else. I believe VI/Sony set the key to all 0s for dev and testing, and
then would patch in the encryption key whenever they pushed out patches. This wouldn't make it any more secure as
a hardcoded encryption key is totally worthless, but I think that was what they were doing.

ICSharpCodeSharpZipLib is being used for compression/decompression. As far as I know, it does not pinvoke so it should
be OK. You posted a link detailing a change that had to be made to work with Mono. I didn't make that change because I
don't have mono installed, so you'll have to do that part. Looked simple enough.

The current implementation uses asynchronous receives and sychronous sending. Receives currently have a single buffer, but this can be easily
expanded to multiple if the client starts dropping UDP packets. Sending is done synchronously on a separate thread to avoid impacting the UI
thread.

Receive operations are automatically assigned threads from the thread pool.

When a packet is received it goes through processing. This is where the CRC, decompression, fragment reconstruction, splitting
of opcombined packets, etc. is handled. The end result is either a packet that is handled by the core server code (e.g. an ACK)
or is transformed into an ApplicationPacket that is placed in an inbound queue. The application (e.g. the loginclient) will then
read from this queue, process the application packet, and do whatever it needs to do.

The application layer (e.g. the loginclient) has a thread that is responsible for reading inbound packets. This will prevent it from
locking the UI thread.

In my very awful test client I have a LoginClient and an EmuClient. This was a simple implementation of the steps for contacting the
Login Server and completing the login sequence. I am automatically selecting the first Emu server because it was simpler for testing
purposes. You'll want to use the event to populate the UI.

The current code to handle translation of hostname to IP is slow. IMO, this could do with a test to say, "Is this an IP already? If so, we're done"
instead of always trying to translate. Anyway, when the udp client shell test app starts, it'll take a bit before the menu displays.

The transition from Login Server to Emu is done as a manual step in the test client, again, because it was simpler. In practice, this handoff
is automatic (duh) and follows the steps I implemented (disconnect from login server, connect to emu, send sessionrequest, get sessionresponse,
send login)
- I haven't implemented the login packet due to time constraints, but the easiest way would be to look at the emu to see what the packet
should look like and what data is in it. My guess is you'll have to provide the 10 byte Session ID that is generated by the login server
and your login server player ID at a minimum.
- I may get to this part, but I'm not sure yet. If it has been implemented you'll know if I did or not. =P

I loaded all of the Titanium OpCodes already and wrote a couple of the struct types for the initial packets.

As a general rule, try to avoid creating new reference types unless you actually need them. The primary reason is to avoid periodic
bursts of lag due to GC. You can actually see this happening if you use windbg and sos. You can dump the heap and see how many types
are sitting on the heap, waiting for GC, etc. This doesn't mean you have to use object pools everywhere, just keep it in mind. If
performance becomes an issue, it'll be one area to examine (with windbg and sos.dll)

I haven't implemented opappcombined packets yet because I don't have any examples of them to work with. The emu looks like it can
receive them, but it doesn't appear to send them, so it shouldn't be a big deal for now. When I work out how to make them, I can
add that to the code.

I don't have a full grasp on the set session stats packets yet. I have a very minimal implementation so far (the first packet you send)
which should be OK for now. I did see that they get exchanged periodically, but I haven't analyzed them yet to learn how to set the
values correctly. I'll update them when I work that part out.

I implemented the OP_KeepAlive timer, so you shouldn't have to deal with that.

To send packets, just send an applicationpacket. The UDP client will do all of the necessary compression, fragmenting, opcombined,
sequencing, ACKing, etc. I tried to make it as fire and forget as possible.


Contributed by Daerath.

Happy to help. I'm going to make some additional updates in the coming weeks as I work through a few ideas.

Go, guys go!

I started the server I'm using to connect to Unity, it's on the list as VZTZ, at the very bottom.

Char creation, North Qeynos, South Qeynos, and Surefall Glade are in Unity Webplayer now.

linked due to size of image.

http://i.imgur.com/16w4Yqq.png