Also Ragnarok in Browser!

[Neo-Mind]

kewl u released the repo    hopefully this project will now progress faster towards completion. 

Excellent work Curiosity

[Andre]

Edit: Okay it works! Very nice job!

 

I've have following bugs:

If i'm on the real Server (rAthena Server) i cant see any sprites (on map viewer i can see sprites!)

 

Chrome Console logs:

1. GET http://***********/RO/data/sprite/%C3%80%C3%8E%C2%B0%C2%A3%C3%81%C2%B7…%C5%A0%C3%82%C2%BA%C3%82%C2%B8%C3%83%E2%82%AC%C3%83%C5%A1_%C2%B3%C2%B2.spr 404 (Not Found) ResourceLoader.js:248

1. GET http://***********/RO/data/sprite/%C3%80%C3%8E%C2%B0%C2%A3%C3%81%C2%B7…%C5%A0%C3%82%C2%BA%C3%82%C2%B8%C3%83%E2%82%AC%C3%83%C5%A1_%C2%B3%C2%B2.act 404 (Not Found) ResourceLoader.js:248

1. Uncaught Incorrect file header sprparser.js:117

1. Uncaught ActParser: File format error; uknown identifier

 

and my movement speed ist pretty fast ... instant warp by clicking!

 

FPS = wow!! awesome!! (spawned 1000+ porings and dont have any fps problems on mapviewer)

 

Maprendering on Gonryun still buggy with pink colors, i know its the first release but i want to report all these bugs!

 

btw. sry for my english!

Edited August 23, 2013 by Andre

[curiosity]

Thanks for the report. Connecting to a server doesn't really work yet. That is, the packets aren't implemented, so NPCs will not appear at this time.

 

Glad to hear you're getting a good frame rate. I hope other people will also try the map loader so I can get a clue on what their performance is like at this point. I think most computers should run pretty smooth, even with lots of monsters on the screen. Though at the moment it doesn't share the processed data between actors with identical sprites, so memory consumption and loading speed can still be reduced by far. This is especially important for bigger monsters which take a relatively long time to ready for drawing.

[curiosity]

 

Some more updates. Mainly:

• Fixed a problem which made camera movement appear a bit jagged.
• Adapted projection & look-and-feel from Gravity's client. From what I found the correct field of view is 15 degrees, resulting in a flatter view which fits the 2.5D style much better than what I had before.
• Fixed the file loading routine to better accommodate sharing of processed resources. Notably sprite textures are now shared between actor instances, which gives various performance benefits.
• Added support for all top and mid headgear as well as the shadow sprite. Next up are weapons and shields for when I start doing interactions between actors, though I'll likely want to rework my sprite attachment system a bit.
• Implemented mouse picking for actors (the game knows which player you are clicking on).
• First attempt on in-game text. Name and chat labels for now.
• Added fog to the map.

 

Will update GitHub soon!

 

 

[Asura]

Thanks for the report. Connecting to a server doesn't really work yet. That is, the packets aren't implemented, so NPCs will not appear at this time.

 

Glad to hear you're getting a good frame rate. I hope other people will also try the map loader so I can get a clue on what their performance is like at this point. I think most computers should run pretty smooth, even with lots of monsters on the screen. Though at the moment it doesn't share the processed data between actors with identical sprites, so memory consumption and loading speed can still be reduced by far. This is especially important for bigger monsters which take a relatively long time to ready for drawing.

Hi curiosity,

 

Why not host a demo so that we can all test?   

If you need a VPS, feel free to let us know; we'd be more than happy to sponsor another cool project.

[curiosity]

Thanks for the report. Connecting to a server doesn't really work yet. That is, the packets aren't implemented, so NPCs will not appear at this time.

 

Glad to hear you're getting a good frame rate. I hope other people will also try the map loader so I can get a clue on what their performance is like at this point. I think most computers should run pretty smooth, even with lots of monsters on the screen. Though at the moment it doesn't share the processed data between actors with identical sprites, so memory consumption and loading speed can still be reduced by far. This is especially important for bigger monsters which take a relatively long time to ready for drawing.

Hi curiosity,

 

Why not host a demo so that we can all test?   

If you need a VPS, feel free to let us know; we'd be more than happy to sponsor another cool project.

 

Thanks for your kind offer. Maki has also offered access to a VPS, so it looks like I'm good for now.

 

I'll make sure to upload something everyone can try out soon.

 

GitHub is also updated, for those who are interested.

[Asura]

 

Thanks for the report. Connecting to a server doesn't really work yet. That is, the packets aren't implemented, so NPCs will not appear at this time.

 

Glad to hear you're getting a good frame rate. I hope other people will also try the map loader so I can get a clue on what their performance is like at this point. I think most computers should run pretty smooth, even with lots of monsters on the screen. Though at the moment it doesn't share the processed data between actors with identical sprites, so memory consumption and loading speed can still be reduced by far. This is especially important for bigger monsters which take a relatively long time to ready for drawing.

Hi curiosity,

 

Why not host a demo so that we can all test?   

If you need a VPS, feel free to let us know; we'd be more than happy to sponsor another cool project.

 

Thanks for your kind offer. Maki has also offered access to a VPS, so it looks like I'm good for now.

 

I'll make sure to upload something everyone can try out soon.

 

GitHub is also updated, for those who are interested.

Hi curiosity,

 

Sounds great, very much looking forward to it!

[Andre]

First i got following error:

1. Uncaught ReferenceError: require is not defined ResourceLoader.js:17

Loading scene! MapLoader.js:1473

THREE.WebGLRenderer 58 three.58.js:18467

1. Uncaught TypeError: Object #<Object> has no method 'getRsw' MapLoader.js:2146

 

so i changed "standAlone: true" in settings.js to "standAlone: false"
after that the maps load but with following error:

1. Uncaught TypeError: Object #<Object> has no method 'getAtlasTextureThreeJs' SpriteActor.js:486

 

i cant move, cant see any sprites etc. dont know what happens with this

 

But fog looks fine!

[curiosity]

Yeah, my bad. I must have forgotten to push some of the changes. And standAlone should be false.

 

I've updated GitHub again. Also cleaned things up a bit and fixed various issues.

[Andre]

Ouh wow ... its amazing!

Fog looks like original client haha.

 

Peformance is not smooth like beginning ...

(sprites should only be shown if you are in range ^-^)

 

But the new console commands are awesome! you rocks! nice work man!

 

ps: if you hold down shift and walk they instantly warps to this point and ignores blocking elements like walls? issnt a bug right? its for development right?

Edited September 5, 2013 by Andre

[nobigdeal]

This is really neat! I was able to get the map loader working in Linux after passing a couple bumps:

 

1. The filenames in Linux are case sensitive, so sprparser.js and actparser.js (as referred in both html) should be SprParser.js and ActParser.js or they will not be found.

 

2. Some data files are going to use whatever case they want (BLACK.BMP won't find black.bmp). There isn't really anything that can be done in ragnarok-js to "fix" this AFAIK, but in Apache you can get around it by adding the following to httpd.conf:

<Directory /path/to/ragnarok/data>
    CheckSpelling On
</Directory>

After doing that I'm walking around Payon.

 

As for Ragnarok.html, it seems to have a problem loading include/CustomControl.js, which actually doesn't exist in the folder. The login window still comes up though.

[curiosity]

I've been testing running it as a desktop application. I might just make that my main focus, because then I could use native code to do the most heavy processing. This would also allow for reading GRFs without essentially having to load the entire thing into memory and use TCP without WebSocket which simplifies things.

 

 

Notable changes since last time include...

• fixed sprite positioning when walking over uneven terrain
• improved accuracy of tile picking
• tile pointer now shapes itself after the underlying tile
• centralized input events
• added mini-map window and chat window to the map loader
• added RSW table for indoor maps and implemented rotation range

@Andre

How bad is it? I didn't notice, but my computer is only 2-3 years old. Unfortunately the 3D library I use has poor support for sprites. Adding shadows under players/monsters effectively makes drawing them twice as heavy, so that might be one reason your performance has gone down. Also picking sprites is a little CPU intensive (I've adjusted down the frequency by 50% now). I think sprites are culled when out of view, but they will still be updated. When I implement network the server will tell when they out of range of the player. Shift-click teleportation is intended, yeah.

 

@nobigdeal

Fixed the mentioned issues. How is graphics hardware support in Linux these days? Last time I checked I got horrible performance with Chromium, even though it was supposedly hardware accelerated.

Edited September 7, 2013 by curiosity

[Andre]

If i spawn now more then 100 mobs on the same spot they will hard lag ... maybe its the shadow idk sry ...

I think its all okay if the sprite dont will shown if i'm out of range

[nobigdeal]

I was finally able to figure out websockify and got a connection to login, char, and map! There were a couple packet warnings with 20120410, is that the right version?
 

How is graphics hardware support in Linux these days? Last time I checked I got horrible performance with Chromium, even though it was supposedly hardware accelerated.

It's been getting better. I'm running graphics off a Haswell CPU and the MapLoader runs at full speed in Firefox (For whatever reason my WebGL is now broken in Chromium). Supposedly Nvidia's Linux drivers sometimes outperform Windows. I haven't seen the benchmark so can't say if it is valid or marketing bull.

[curiosity]

I was finally able to figure out websockify and got a connection to login, char, and map! There were a couple packet warnings with 20120410, is that the right version?

 

At present there isn't really a correct packet version, just a collection of structures with the IDs they were initially assigned when they first appeared. As you can image this doesn't work terribly well, so I'm re-planning and reworking everything related to packets. This will feature the ability to use a packet version of your own choice, but unfortunately Athena's packet_db only gives structural information for client-to-server packets so there are still problems. In reality I'll probably target version 30, or something close to that depending on how many packet structures I'm currently missing. It appears Athena has at best spotty support for older packet versions anyway. From what I can tell it will for instance ignore sending monster/NPC/actor packets if your version is too old.

[Dia]

I want to use this for my aegis server. Sadly it seems to be not compatbile with the websockets. You got the desktop client version ready with tcp instead of websockets?

 

/edit: nvm, was somehow a bug with gender (11 instead of 1).

Edited September 27, 2013 by scriptor

[curiosity]

I want to use this for my aegis server. Sadly it seems to be not compatbile with the websockets. You got the desktop client version ready with tcp instead of websockets?

 

/edit: nvm, was somehow a bug with gender (11 instead of 1).

 

I guess you found out there wasn't very much network functionality implemented, huh? By now I've revamped the whole packet system with support for "any" packet version. I would like to eventually support AEGIS, but it probably requires much extra work depending on the version. I've based my packet builder on Athena's packet_db. Lots of packets are only slightly changed from one packet version to another, so as you may know Athena will just define a length and optionally indices of the fields it cares about. I only have the major packet structures available (not unique structures for every little change in the different packet versions), so I just base the outgoing packet on the most recent structure, then if I detect if the structure is modified in the current packet version I use packet_db's field indices to set only the data Athena cares about. This works great with Athena, but I imagine AEGIS wouldn't like it very much at all.

 

Project status: Lots of work done! Client in screenshot below is connected to rAthena using TCP and packet version 30. You can now walk, talk, see other players, monsters, NPCs and their movement.

 

 

[Neo-Mind]

 looking great . 

[curiosity]

Thanks.

 

I've updated the repository again after doing some major reorganization. From now on I'll stop doing "mega-commits", which I realize are cumbersome. If anyone wants to contribute to this project let me know, and I'll give repository access.

[Dia]

Is the windows client version also in source control? Would be nice if you could share it and tell how to start it

Edited September 30, 2013 by scriptor

[curiosity]

Desktop version is the same code as the web version. To run as desktop application you must download node-webkit and run nw.exe using the client's root directory as the argument. Make sure to enable the desktop option in settings.js to enable reading files locally. Also remember to configure TCP in the settings if that's what you want to use.

[Asura]

Hi curiosity,

 

I tried running it using the node-webkit pre-built binary for Win32, but it just displays a blank page.

 

I'm currently using the latest files provided in your repo, and I've renamed the settings template to 'settings.js'. Within the 'settings.js', the desktop value was set to 'true' and socketType to '1'.

 

The Ragnarok.html runs fine when on Chrome, but am just un-able to connect properly to a basic server. Got any ideas about this?

 

Edit; found this within the console of nw.exe

Info: File system API seems to be available

ResourceLoader.js:30

THREE.WebGLRenderer 58 three.58.js:18467

1. Error creating WebGL context. three.58.js:25729
   1. initGLthree.58.js:25729

Uncaught TypeError: Cannot call method 'getExtension' of null three.58.js:25733

[curiosity]

...

 

 

If you've set socketType to 1 then you won't be able to connect to a server from Chrome, because TCP sockets are not a feature available in web browsers.

 

For playing in web browsers you must use the WebSocket protocol, which is enabled by setting socketType to 0. Please note that this requires connecting through a WebSocket to TCP proxy such as websockify.

 

As for the error message, it is generally a sign that your computer doesn't support WebGL, but there can be a number of different reasons.

 

Try visiting http://get.webgl.org/, or run any other WebGL app, from Chrome. If WebGL is supported in Chrome then one thing you can try is copying libegl.dll and libglesv2.dll from Chrome's application data folder into your node-webkit folder (replacing the ones bundled with node-webkit).

Edited October 1, 2013 by curiosity

[Asura]

Hi curiosity,

 

Thanks for the response, but unfortunately it didn't work.

[nobigdeal]

@Asura

I was having that problem until I closed the version already running in my browser. Not sure what else it might be.

 

When running in Chrome do you got websockify going for each of the 3 servers?

The command would look like this for login, "python websockify.py 6899 127.0.0.1:6900" and just change the ports for the other two.

 

@Curiosity

Haven't tried multiclient but looking good so far over here. I want to try tinkering with it later when I get time, though I'm not very experienced with js.