Hmmm… Well… guess the title says it all.
I have been working on a d&d(ish… am I allowed to say d&d O.o) MMORPG since early alpha. Its coming along quite nicely.
Features worth mentioning:
–Player scripting language for creating custom hot-button commands (with in-game documentation… who woulda thunk it)–
i.e. (say for casting)
/stand
/target
/cast 3
/pause 7
/sit
–Fairly robust skill & spell systems
–Fairly robust crafting system for player made items
–Grouping & Raiding interfaces
–Well balanced scale-able attack system
–Fairly good NPC AI & AI pathing (always improving of course)
–Extensive character & inventory slots
–NPC hirlings & pet system
Features worth not mentioning: 
–Graphics are extremely placeholder-ish (as seen below)
and I guess that’s it for the moment.
Man thats awsome!!
Looks REAL cool 
I think the graphics are very nice actually, really like the gui
Good job!
Thanks a ton for taking a look! I have no clue how long this will take me to complete (or if I ever will be able to… as I am not the best at creating sheeeet in Blender)
A couple of the things I’m in need of doing:
- Updating my method of collision detection - I implemented my own collision detection system, as I am not using bullet physics (just some simple physics I wrote). I really need to ditch my 7-point ray collision for triangle collision, however, the link in documentation to implementing simple collision detection using shape collision is a broken link and I’m not completely sure how to respond to the collision results. I’m sure I’ll figure it out once I tackle updating the collisions detection. Mine works fine in most cases (i.e. I can continue development on functionality without worrying about updating this for now)
- Finish implementing character creation - I’m completely stoked about this, as I created the fundamentals for object creation with how I planned on implementing saving/loading/transporting characters/objects/etc to make it as SIMPLE as possible. Well, today I finally decided to test this theory (was terrified that my initial premise was wrong). So 12 lines of code later (for saving and loading characters) and HOLY CRAP!!! It worked without a hitch >.< All character equipment, inventory loads the proper geometry, all player data is correct and (most importantly) not corrupt. All interface components are set properly. And everything is where it should be in the world… after restarting the server.
As happy as I have been with how development has been going on this project… today was the best! If I only had friends to call and brag to >.<
Wow, looks nice. And the feature set sounds very impressive, congratulations
You can use bullet for “simple collision detection” as well, using physicsSpace.rayTest() and sweepTest(). They are a bit more flexible and faster than geometry collision but they require a (kinematic) collisionShape/rigidBody. Using geometry collision however also creates additional data in the background, you might want to try around with what works best for you.
@normen I was hoping there would be a way to do this, as you guys are MUCH better developers than I will ever be.
Is there anything I should keep in mind when changing over to this? (The reason I as is… I am still stuck using alpha 4 until the next stable reason–ATI card issue from another post–and want to plan ahead from when I can update).
Hm, nothing much but attach your controls, and set them to kinematic mode. Obviously, add/remove them to/from the physics space properly (you can also remove them by disabling the control with setEnabled(false)) and mind the collision shapes. By default a hull collision shape is created for rigidBodies with mass and a mesh collision shape for objects without mass, its created when the control is attached to the spatial based on the spatials geometry (sub)nodes.
@t0neg0d said:
@normen I was hoping there would be a way to do this, as you guys are MUCH better developers than I will ever be.
Is there anything I should keep in mind when changing over to this? (The reason I as is... I am still stuck using alpha 4 until the next stable reason--ATI card issue from another post--and want to plan ahead from when I can update).
Trying to be sure that I understand this correctly... you are using 8 month old JME because of that one shader issue? Seems like it would be easier just to patch the shader locally or just temporarily use a version copied into your assets folder. But maybe there was some other issue?
@pspeed said:
Trying to be sure that I understand this correctly... you are using 8 month old JME because of that one shader issue? Seems like it would be easier just to patch the shader locally or just temporarily use a version copied into your assets folder. But maybe there was some other issue?
Oh... no. I had to take an extended break from development do to moving to a new state and such. I just got back to work on this recently.
@t0neg0d said:
Oh... no. I had to take an extended break from development do to moving to a new state and such. I just got back to work on this recently.
Yeah, but I'm trying to understand why you can't run beta.
The shader issue is not the problem. I have that patched locally for the time being. The issue is in this thread:
Issue
The original post has the error in it.
A new stable will probably not fix that. My guess is that you have an old lwljgl on your path somewhere that is being used instead of the newer one or something.
@pspeed said:
A new stable will probably not fix that. My guess is that you have an old lwljgl on your path somewhere that is being used instead of the newer one or something.
Unfortunately, the "or something" part is what is holding me up. I would LOVE nothing more than to be using alpha... well.. that's not totally true... I would love nothing more than to continue writing this game. So, I am really not sure how to proceed :(
Ugh… can’t edit my post… I did mean “using beta”
@pspeed How would I go about checking version of lwljgl that is in use?
And… what version should I be expecting to see?
If it’s windows you can try searching your whole drive for the lwjgl dll. You can find out what it’s called but looking in the directory where you run your game, I guess.
I’m not familiar with where these things might normally end up… but I know for a while the SDK was dumping it somewhere under the user’s home directory and then that was fixed. If you have an old one hanging out there it will cause issues.
@pspeed I’m gonna look into this and see if I can resolve it now. I am 99.9% sure that this is the issue after giving it some thought (which hurts my brain most of the time… thus the procrastination).
I’ll report back with a HUGE thank you once I get this fixed!
@pspeed said:
The SDK was dumping it somewhere under the user's home directory and then that was fixed.
The SDK itself uses a folder under /(home or app data/roaming on windows)/.jmonkeyplatform/(sdk_version)/ to extract its binaries, hence beta should never get the same binary as any alpha version.
this looks nice. gl.
@normen said:
The SDK itself uses a folder under /(home or app data/roaming on windows)/.jmonkeyplatform/(sdk_version)/ to extract its binaries, hence beta should never get the same binary as any alpha version.
Since the DLLs had to go somewhere that windows would find them on the PATH then I assumed that they must have had to go to a more centralized place when not in the application's directory. And I know there was a bug that was fixed regarding the determination of whether these DLLs could be written to the project directory.
