[WoW Emulator] eWoW - a modularized C# emulator

[Apoc]

i agree,i prefer having collision in the client, but for WoW thats just not an option, since blizzard decided to be dickheads... DAoC has the client check los, it just sends a los request to the client, and waits for it to return


We used mpqnav for reference, but the amount of polygons, is simply too great lol.. You wanna reduce the amount by applying ridiculously complex formulas to reduce the size of each tile, and make raycasting less costly cpu wise... Our problem is the fact that our algo isnt efficient enough for terrain/ADTs :/

Nono, I'm saying, the client (using the right flags, of which I can't remember off hand atm) can check LoS without any server requests.

[mgX]

Nono, I'm saying, the client (using the right flags, of which I can't remember off hand atm) can check LoS without any server requests.

I seriously doubt that. Innerspace used the client's internal LoS checking system, but it cannot be done serverside. Theres no way to invoke it through packets alone...

[Mitron]

I wanna see this up and running btw isnt C# pretty close to VB.NET ?? or is there more than one C# ??

well enaff bout that :P if there is needed and other apps for it that can be made in VB.NET i would like to help (prolly there isnt any of em know tho) but well contact me if u need always wanna help ^^

[mgX]

Apoc:

you see? too many polygons... our current polygon reduction algorithm isnt efficient enough, and thats with an extremely high error tolerance

[The-Eradicator]

isnt C# pretty close to VB.NET ?? or is there more than one C# ??

C# = .NET language = Basically the exact same thing, just different syntax. That's why there's a billion converters that can switch projects from one .NET language to another.

[Mitron]

Ok thanks Eradicator

[Apoc]

Apoc: ...snip...

you see? too many polygons... our current polygon reduction algorithm isnt efficient enough, and thats with an extremely high error tolerance

That's actually pretty close to as good as you can get. I would stop looking at your map reduction, and start looking at how you're actually calculating LoS, etc.

[mgX]

That's actually pretty close to as good as you can get. I would stop looking at your map reduction, and start looking at how you're actually calculating LoS, etc.

well, thats already taken care of... And we're pretty positive our algo is crap... At least thats what a 3D programmer guy told us :P problem is, hes stuck in iraq with crappy internet, so its a bit hard to fix that (he mentioned something about suiciderates might drop for the yankee troops, if they fixed the internet...hard to argue with that assumption :P)

[Apoc]

well, thats already taken care of... And we're pretty positive our algo is crap... At least thats what a 3D programmer guy told us :P problem is, hes stuck in iraq with crappy internet, so its a bit hard to fix that (he mentioned something about suiciderates might drop for the yankee troops, if they fixed the internet...hard to argue with that assumption :P)

Haha. Awesome!

It's about as good as it'll get, simply because you've got to worry about 'slow-sloping' hills and whatnot. Sure, the quick stuff can be huge regions, but some stuff simply can't be knocked down to lesser ngons without losing it's worth. Also, (haven't checked, so correct me here) I hope you're not doing all the parsing at runtime, as that would be a waste of resources.

[mgX]

Haha. Awesome!

It's about as good as it'll get, simply because you've got to worry about 'slow-sloping' hills and whatnot. Sure, the quick stuff can be huge regions, but some stuff simply can't be knocked down to lesser ngons without losing it's worth. Also, (haven't checked, so correct me here) I hope you're not doing all the parsing at runtime, as that would be a waste of resources.

That pic is 35k polys, or around 4-500kb for a whole tile.... And no, we parse the entire shit and create the bsp trees in a sepperate app, so the server can use them...

[Apoc]

That pic is 35k polys, or around 4-500kb for a whole tile.... And no, we parse the entire shit and create the bsp trees in a sepperate app, so the server can use them...

4-500kb sounds about right. (My entire world dump for my old nav system was around that area.) I guess it comes down to how you're storing the data. (At one point I was using XML as it actually *is* the fastest compared to others, but holy hell does it take up a lot of space...) Now, I (de)compress all my data with LZMA then read via the BinaryReader. (Have my own file format worked out that keeps space to a minimum. Not the best, but far better than the alternative) Though, for a server, this kind of system is kinda useless as it would take too much resource wise to handle the nav data properly. (I was doing it for the current player, which leaves little to no overhead in the end.)

[Hellgawd]

This thread should be renamed to 'Apawk's Dev Talk'

[mgX]

4-500kb sounds about right. (My entire world dump for my old nav system was around that area.) I guess it comes down to how you're storing the data. (At one point I was using XML as it actually *is* the fastest compared to others, but holy hell does it take up a lot of space...) Now, I (de)compress all my data with LZMA then read via the BinaryReader. (Have my own file format worked out that keeps space to a minimum. Not the best, but far better than the alternative) Though, for a server, this kind of system is kinda useless as it would take too much resource wise to handle the nav data properly. (I was doing it for the current player, which leaves little to no overhead in the end.)

We are confident we can get it down in size But xml loading isnt exactly fast in c# (faster in java lol), since it relies on some crappy iterational system which i hate... We're making our own binary format for it....We're mostly concerned with the raw data really, since thats whats gonna be loaded, so reducing polycount is of paramount importance

[Mitron]

This thread should be renamed to 'Apawk's Dev Talk'

What he said ^

[sado55]

what ones do i download?