Quote from red51any block shape will be available as "construction element", i.e. you will be able to place, rotate and scale it without any restrictions
Omg! That would be the best feature ever! 
With that capability and some of the talent I've already seen on some servers, this game would be catapulted to the top of the charts. So glad to have found it.
I think most of us share your observation about the "feel" of the game. Pretty much all of us have a background in Minecraft, but started yearning for the "grown up" equivalent, and this is it. I don't believe it's intended to be a MC knock-off, but has a very similar agenda.
I still like Minecraft, but now that this game has crossed the threshold to being a real game (early access or not), I seldom go back any more. I think you touched on what appeals to me the most. Like you, I cleared a sizable area for my base, removing hills and filling in low spots, all with just a few hand tools and a bit of persistence. Much more labor and finesse required than on MC, but also much more satisfaction with the results.
Reminds me of some real-life experiences I shared with my dad, and at the end of the day it was all about sitting back and admiring the fruits of our efforts. That's the "feel" I like. 
Quote from zfoxfireI'm not sure if this would deviate from Red51's desire to make the game realistic.
Surely you're not implying that ghosts aren't real, are you?
Maybe a more theatric approach would be to have dungeon ghosts who patrol the nearby area. When they encounter a player within, say, 100 blocks of the dungeon they get in your face for a couple of seconds and then take off in the direction of the dungeon, vanishing through cave walls or the ground itself.
The frequency of their appearance would increase as you get closer to the dungeon, accompanied by scary sounds, of course. A bit more involved than just having a detector device, but far more entertaining. 
I have no idea what it would take to create these wispy npc's, but it's an interesting concept.
So near, yet so far...
I’ve been cobbling together a plugin which centers around a fairly involved gui interface. In my final testing I’m focusing on error detection/recovery and foolproofing the gui to prevent the user from winding up in an awkward situation which may or may not be easy to recover from.
The only known bug left (forget the unknown ones for now 
) is the supporting of the Escape key as the universal abort tool. As it stands now, hitting Escape at any point in the usage of this gui terminates the current action and gracefully backs out of the task at hand. The one situation I can’t seem to do that for is when using a guiTextField.
When such a field is in focus, I don’t seem to get any onPlayerKeyEvents, so I have no way to inject my own abort sequence. When Escape is typed during a guiTextField edit session, the result is the appearance of the RW options window (Settings/Friends/Permissions/Return to main menu/Quit), right in front of the textField element. Getting out of that situation is a little tricky and not obvious, and may leave you in a worse situation.
I can (and have) incorporated alternate ways to abort the textField, but I really want to either have Escape do the natural thing or prevent it from doing anything at all. It's pretty certain the user will hit that key eventually.
So far I’ve tried a number of combinations and variations of:
All interesting stuff, but I can’t seem to reach my goal. Anybody done this?
I’m looking for actual solutions or suggestions. Not so much guesses that haven’t been tested. 
That's a good tidbit of information, MommaT. We're both Mac users, but you have an NVIDIA card and I'm using an ATI Radeon. Even if the problem is Mac-oriented, it may have nothing to do with the video hardware.
Hopefully that might be a clue for the smart people, like red51.
I recant. I made several attempts to reproduce the indoor-rain-filling-me-up scenario, but it just didn't happen.
Let's just say I musta eaten a couple of apples without even thinking about it and got some water that way in the original incident. That would imply that I'm senile, so let's just say it's a theory.
Interesting observation just now --
I was in my house, which has an actual roof on it, when the rain came. I could see it indoors, as this thread mentions, but at the same time, my water indicator slowly filled up.
Doesn't seem like a purely video artifact would actually cure my thirst, so now I'm wondering if the two phenomena are related or independent.
Maybe I should follow that rabbit down the hole... 
I started with the zip file, expanded it, and replaced the whole enchilada.
This was my 5th server update. I thought I had the procedure down pretty well, but I must have gotten careless bringing stuff over from the previous version to preserve the properties, scripts, world, plugins, etc.
To put it in technical terms, I musta screwed up. 
When in doubt, use a bigger hammer. 
Spent a couple more hours tracing and re-tracing my steps and everything checked out perfectly. Rebooted everything that could be rebooted. Double-checked file sizes, properties, configs. No joy.
SO... I finally went to the hosted server and scraped off anything and everything that had anything to do with Rising World. Right down to the metal (after making local backups, of course). Downloaded yet another fresh copy of the server zip file, and installed completely from scratch.
And it worked.
I will never know exactly what the problem was, but it's gone now. No doubt it was something silly, but I won't look back.
Thanks, Miwarre. Sorry I wasted your time. Good to know you're there, though.
I like the way you think, Miwarre.
I will now run a "chain of custody" on the jar file in question. Never hurts to double and triple check such things, especially when the problem still exists.
I'm pretty convinced that the jar that I launched on the hosted server is indeed a match to the one on my local computer, especially since the startup log confirms the version number. I will still double check.
It's becoming apparent that the response being given back to the client must be coming from somewhere other than that server software. Like a phantom server process that I just haven't identified yet.
Thanks for your clarity of thought.
Miwarre -
I may have confused things by giving too much information. The only client I refer to is the one on my local Mac.
The problem is between the client and the hosted server. The local server (yes, on the same Mac) works properly with the client. A copy of the exact same server jar is now running on the hosted Linux server. I do my own installs on the Linux host, and have done so for a long time.
The client matches versions with the local server, but not the hosted server.
Clearly I must have done something wrong, but for the life of me I can't find what.
I am prepared for a thorough embarrassment when this is solved. 
Never quite sure how to answer that question with linux. Does this help?
cat /etc/*release
CentOS Linux release 7.0.1406 (Core)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
This doesn't feel like a distro issue to me. The RW server seems to run fine. The client seems to run fine. The two seem to be exchanging packets just fine. I can find no stray processes running on the server.
Is there a way to query the RW server for its version number? Somebody's lying.
Just when I thought I could solve any of my problems by myself, reality pops up and kicks me in the butt. 
Quick history:
I have over a thousand hours in the game, been playing Steam version and recently added the standalone version for test purposes.
I run a local server on my Mac, mostly for plugin testing, and I have a commercially-hosted linux server which I’ve been running with a number of versions of Rising World over many months now.
The current problem:
All is working fine on my local computer, local server and all. But now when I attempt to run it on my hosted server, I get a befuddling version mismatch error. Fact is, my hosted server think's it’s runninng version 0.8, while the startup log says it’s running 0.8.0.1.
My client:
The server (from the log):
[minecraft@ValleyCraft RisingWorld]$ java -Xmx2048m -Xms1024m -jar rightDamnServer.jar
Rising World - 0.8.0.1 - Dedicated Server
Linux 2.6.32-042stab112.15 Java 1.8.0_05 (amd64) Memory: 1908 MB
2017/01/04 06:51 PM
The result:
If I bypass the domain name and go straight for the ip address, I get a slightly different result:
For those last attempts, I deleted the existing server.jar file, uploaded a fresh new 0.8.0.1, and even renamed it to make doubly sure that that’s the one I’m launching. My frustration *might* be apparent in the name I gave it. Apologies.
I also bypassed the startup script and launched it directly from the command line, just to make extra sure.
As you can see from the above snippet from the startup log, it appears to be running the correct version, yet, the mismatch errors persist, even after re-starting Steam from scratch. Same results running steam client or standalone version.
Full log:
SplinterCraft Version Conflict.txt
I’m at my wit’s end, which is odd ‘cuz I thought my wits ended long ago. 
I guess I should fess up --
I'm running a state-of-the-art (well, it was in 2010):
Never intended to run video games on it, but here I am.
Loving the heck out of the new release. Loving the weather, even though it shows up in my underground basement.
This basement is maybe a dozen blocks underground, and I was a bit surprised that the rain followed me there.
The first picture shows the rain. Zfoxfire was right next to me and he did NOT see rain.
The second picture shows the basement with just the room lights on.
The third picture shows the basement from the exact same position, but with night fog.
The weather follows me into every room in the house, even though it now has a roof.
Still an amazing release, but thought it was worth sharing the pictures.
Thanks for the input, Monotorious.
I'm inclined (no pun intended) to agree with you. Much of my house uses blocks for the basic structure and wood paneling (stretched planks) to show a different texture on one side. If the texture is not too intricate then blocks are a quick and easy way to go. Blocks also guarantee nice square corners which make a good reference for the rest of the build.
I guess there's no substitute for doing things right. But I tried.
At the risk of exposing my own ignorance, I just stumbled upon a circumstance that makes me realize how little I know of textures.
I guess the quickest way to explain my predicament is with pictures. My intention is to dress up the underside of my sloped roof to present a nice vaulted ceiling. But when I add the ramp blocks, the textures don't line up from one level to the next.
You can see from the pictures that it's not so noticeable on the exterior roof, although that particular texture is very forgiving in this respect. But the interior ceiling blocks are clearly out of alignment, thus ruining the effect.
Although I can probably get around this by using planks instead of blocks, I just thought I'd check to see if there are any other suggestions from the *real* builders on the forum.
I just confirmed that the standalone Mac version is now working, so we're good to go!
Not a bad day's work for a holiday, Red. You da man.
Mac Steam version is FIXED!!!
Less than 24 hours after the initial release. That's impressive follow-through.
Thanks, Red!
