longbyte1 wrote:
I haven't tested if specific behavioral portions of the protocol (grenades, respawn, block line, even positions) are working as intended, but I assume they are since they're not bugging out like they were before.
A weird thing that is also happening is that the backend also wants to load the map data only when I'm running it with the debugger. Otherwise it just gets stuck on one packet and stops loading for some reason (?!).
1. I suggest to render a minimap at first.
2. I know you're not using C, but in C, the debugger often makes programs work that would crash otherwise, cause it changes the memory layout. Maybe you have something like that?
Definitely something with the memory, I agree. Must be the ENet bindings screwing up again (they are for the most part compiled with Emscripten, and they've caused trouble before).
News: I've acquired an AWS EC2 instance. For now it is running under free tier (t2.micro) and I am still exploring its capabilities. I might even place a simple little ad to keep the instance afloat once I finish everything. I'll also probably put the frontend on GitHub Static Pages to keep the DDoSers away (only way into the instance would be websockets).
longbyte1 wrote:My goal right now is to make a 0.75-compliant client.
Please keep this your priority so we can thoroughly support it. For one, being compatible with pysnip is hugely important. Keep us updated on your progress.
longbyte1 wrote:My goal right now is to make a 0.75-compliant client.
Please keep this your priority so we can thoroughly support it. For one, being compatible with pysnip is hugely important. Keep us updated on your progress.
Thanks for your support!
My summer program still continues but things should be a bit smoother perhaps by next week.
One of the large challenges that I am facing while thinking about the client is moderation. With a websockets proxy, PySnip will see that the IP address of a player is that of the proxy, not the player on the web browser. So when said player is being a butt and gets kicked or banned, the consequence is that nobody can join that server through the WebGL client, or the success rate is intermittent based on how EC2 is configured with IP addresses.
However, what I can do is that I can send in an additional packet that is not specified anywhere in the AoS protocol in order to identify players who are playing behind the websockets proxy. Let's say that the packet ID is 63. The first field would be the address type: IPv4 (0x0) or IPv6 (0x1). If IPv4, 4 bytes should be expected next; otherwise, 16 bytes for IPv6. If valid, the address in this packet would overwrite the "player IP" field as stored in PySnip for all banning purposes. In order to prevent abuse, however, this packet should only be accepted from the IP address of the websockets proxy/gateway.
so, what are the benefits of making a WebGL client? Like, why would a person perhaps choose this over the classic client? Is it cause the performance of the game would be better on a WebGl client? (:
bloodfox wrote:so, what are the benefits of making a WebGL client? Like, why would a person perhaps choose this over the classic client? Is it cause the performance of the game would be better on a WebGl client? (:
It obvously benefits from giving more customisability (ie not stuck with the 0.75 executable etc yet). Tho that's not exclusive to a WebGL client.
WebGL benefits:
- Hardware accelerated, good performance (Chrome & FF anyway, which is about 50% of the browser population, can't speak for MSIE)
- Easy- open a page, load some assets, go.
- Easy to update, no need to push updates out to installations across many PCs
- MOBILE Support (Particually Chrome on Android)
- Modern, so no DirectX/Flash needed
bloodfox wrote:so, what are the benefits of making a WebGL client? Like, why would a person perhaps choose this over the classic client? Is it cause the performance of the game would be better on a WebGl client? (:
It obvously benefits from giving more customisability (ie not stuck with the 0.75 executable etc yet). Tho that's not exclusive to a WebGL client.
WebGL benefits:
- Hardware accelerated, good performance (Chrome & FF anyway, which is about 50% of the browser population, can't speak for MSIE)
- Easy- open a page, load some assets, go.
- Easy to update, no need to push updates out to installations across many PCs
- MOBILE Support (Particually Chrome on Android)
- Modern, so no DirectX/Flash needed
But back what I was regularly saying, do you think that we could possibly not have a framerate lock on this client since it's not the actual game itself...? Or is it still limited to a 30fps lock....
bloodfox wrote:
that game absolutely fucking sucks.
But back what I was regularly saying, do you think that we could possibly not have a framerate lock on this client since it's not the actual game itself...? Or is it still limited to a 30fps lock....
That game is a demo. Don't take any notice of the gameplay, just the concept- ie In browser voxel WebGl game.
The framerate lock is entirely down to the developer. As long as the in game logic/physics don't depend on the frame rate, FPS is dependant on what the developer decides- lock it, leave it, lock it to vysnc etc. WebGl doesn't limit framerate, it's the hardware that does that.
[Warp-UK] FN-FAL, MK11, G36C, VSS Vintorez, AK12, ACE 52, AKs74u Look for more (Inc Sounds)
The only actual advantage of using WebGL that you listed above is the updating. Everything else can be achieved with "normal" programs. I guess the main reason for your choice is that you're a web developer ;)
Anyways, I hope you don't make such a shitty implementation of the protocol like in OpenSpades. It has slightly different behaviour than AoS, which might look reasonable at first, but actually breaks some scripts. Examples: death when HP is set to 0 (only should happen when recieving the kill packet) or ammo glitches when the reloading mechanism suddenly works differently than in original PySnip (probably not caring about the ammo/stock count carried in the weapon reloading packet).
LeCom wrote:The only actual advantage of using WebGL that you listed above is the updating. Everything else can be achieved with "normal" programs. I guess the main reason for your choice is that you're a web developer ;)
Might just be. Your comments about OS are interesting, I never knew that.
[Warp-UK] FN-FAL, MK11, G36C, VSS Vintorez, AK12, ACE 52, AKs74u Look for more (Inc Sounds)
Icarus North wrote:It's a good thought, but hear me out.
I still don't fully understand how SQL injections work
If there's going to be a system that will "check" for "local bans," what's there to stop the user from deleting the file/cookie, or worse, inject malicious code into this local data?
ughhhhh somebody had to resurrect this threaddd
I never really believed in cookies or local storage except for storing settings. Everything else like ban info should always be stored in a server. It's easier that way, because then players can't hack the client to circumvent anti-cheat features, but then the attack vector would shift to the server as well.
Players who use Tor would get what they want - privacy - unless I decided to block clients coming from any IP of a daily list of Tor exit nodes.