Questions about Client implementation details

[borka]

https://github.com/k-t/SharpHaven

[loftar]

Only specific questions for now would be concerning the resource files; what finalized format are they in?

A custom format, but a very simple one. Each resource file is just a list of the various parts (images/sound clips/textures/meshes/whatever) that make up a single resource. Look at the Resource class for the details (in particular, the load(InputStream) method decodes the container format); again, I don't think I can document it in text much shorter than the code does it.

Where are they stored?

Some come bundled with the client in the accompanying Jar files, but when the client lacks one that it needs, it downloads it over HTTP when the server has given it the name of the resource.

I have a bloodoath vendetta against Java [...] (No offense to users of these languages; I just really, really don't like to use them myself.)

Also, I just kinda wanted to add how I don't hold this against you at all. The client code is, as a whole, by far my least favorite part of this whole deal, and that is very much because of Java. Though, to speak ill of Java while speaking well of C# seems a bit... odd to me.

[marvi]

https://github.com/k-t/SharpHaven

It's a client for the old haven. As for hafen, there are .NET libraries that allow to work with resources and there is an outdated network protocol implementation (it wasn't updated to support floating point coordinates):

https://github.com/k-t/haven-dotnet

It might be a bit more convoluted than the original Java implementation since I tried to support both legacy and current protocol at once.

EDIT.

Aha! Sweet! This should help a ton. I'm curious how much the overall server/client comms have changes since then. It looks like the main reason he gave up was the nitty-gritty of implementation; adding all the widgets and linking them up properly.

Well, not really. I guess you saw code for the legacy client. I gave up on it after hafen announcement. I actually tried to experiment with Unity afterwards (and figured out how to make basic UI: https://www.youtube.com/watch?v=1Iul5fWfyUE >_>) and I'd say the main challenge is how to dynamically load all resources and 3D stuff and render it close to how original Java client does it. I'm not that experienced with Unity though.

[Dreadicon]

A custom format, but a very simple one. Each resource file is just a list of the various parts (images/sound clips/textures/meshes/whatever) that make up a single resource. Look at the Resource class for the details (in particular, the load(InputStream) method decodes the container format); again, I don't think I can document it in text much shorter than the code does it.

Thanks! Just pointing me to the right place is a great help. I appreciate it! Honestly, only thing I could ask for is more commenting in the code, but it's not expressly necessary.

Some come bundled with the client in the accompanying Jar files, but when the client lacks one that it needs, it downloads it over HTTP when the server has given it the name of the resource.

Ahhh, that clears things up a bit. It has a caching system so that it doesn't spam the server with requests, right? I'll re-implement that ofc if I do pull assets. Hopefully there's a hash/checksum/versioning I can have the client check once per day to verify that the assets are the latest available without re-pulling from the server.

Though, to speak ill of Java while speaking well of C# seems a bit... odd to me.

Hehe, I think we dislike Java for different reasons is why. You dislike it (I'm guessing) for the same reason my C++ programming friends do: It's a managed language and a counter-intuitive (to C++ and lower level programmers) combination of hands-on and hands-off when it comes to optimization. C# isn't much better from that point of view. But if one accepts that managed is OK, and that the level of hands-on management makes sense, then if you compare C# and Java, the former shines while the latter dulls to mud. C# has a more robust IDE, is possibly the most well documented language in existence, has very clear guidelines for style and format that make reading it easier between programmers, it's GC is tight and predictable, and users aren't CONSTANTLY fighting with their managed language VM between 5 versions and breaking changes (looking at you, Java7/8/9/x32/x64/web/desktop/global). Java, like PHP, also has a long history of very bad programmers building the most prominent applications for it (Minecraft, for example), and as such there is a lot of breaky, quirky bits of the language that continue to be supported and added to.

TL;DR: I speak ill of it not because I disapprove of the kind of language it is, but because I dislike the implementation for it's class of programming language.

I gave up on it after hafen announcement. I actually tried to experiment with Unity afterwards (and figured out how to make basic UI: https://www.youtube.com/watch?v=1Iul5fWfyUE >_>) and I'd say the main challenge is how to dynamically load all resources and 3D stuff and render it close to how original Java client does it. I'm not that experienced with Unity though.

I see. Building the meshes should be dead easy. Unity allows you to construct meshes on the fly without much work, all considered (I've done this before). I haven't looked into their animation building or texture mapping manual operations though, so offhand I can't say for sure. But it should be possible, if not easy as well. Ultimately the best thing to do would be to write a converter into a common format that Unity can load at runtime, which would bypass all those concerns. If you happen to have that Unity project laying around, I'd love to have it It might not be much, but it'd be a nice starting point (I like examples of how a library is used, even if it's only a tiny part of it)

So, that unity test was using your library to log in? That's great! Honestly I can handle picking apart the data given some time I think. Looks like from here a C# Unity Haven is just a matter of grunt work and time.

EDIT: PS, if anyone would like to work with me on this who also has C# experience, just let me know via PM. I'll get you into the messengers I use (Hangouts, Discord, Steam, or Skype) so we can talk more.

[Paradoxs]

Ahhh, that clears things up a bit. It has a caching system so that it doesn't spam the server with requests, right? I'll re-implement that ofc if I do pull assets. Hopefully there's a hash/checksum/versioning I can have the client check once per day to verify that the assets are the latest available without re-pulling from the server.

After you see something it gets stored into your hafen.jar from what I can tell, it might be put into builtin.jar too, but I don't think so.
It appears that the resources also have a version tag, its used in a small check that

Code: Select all

       if (this.ver == -1)
            this.ver = ver;
        else if (ver != this.ver)
            throw (new LoadException("Wrong res version (" + ver + " != " + this.ver + ")", this));

I imagine the way the code deals with that is by downloading the resource but I havent gone too far into it to know.

[gigafunk]

A unity client would mean possible Vr integration. Holy hell i could be in haven....

Ready, Player one?

[shubla]

A unity client would mean possible Vr integration. Holy hell i could be in haven....

Ready, Player one?

Why would unity be needed for it?
I think that anything is possible, server only tells you information about objects and so on.
How you present that to the user is your choice.

[Ysh]

I think that anything is possible.

Right on!

[APXEOLOG]

PS, if anyone would like to work with me on this who also has C# experience, just let me know via PM. I'll get you into the messengers I use (Hangouts, Discord, Steam, or Skype) so we can talk more.

I know a lot about protocol level, even have my own console client written from scratch. I'm a Java programmer and i don't want to spend time on C#, but i can answer some of your questions. You can reach me in skype (apxeolog) or discord (APXEOLOG#3742)