Posts by LordFoobar

I personally would say "no" to this, as it would be most annoying... The psychological part of the character should be the player.

However, I would like to see hallucinogens in the game. Would make things interesting.

I agree with this, too! The backdrop should toggle when pressing T, and not be visible all the time, however. Also, long lines should wrap.

Quote from ozzyjimbob

I seem to have found a small father christmas face in the cooking grill. Please tell me you see it too. hee hee.

As long as nobody say they have found Jesus in the game.... everything is fine.

I have seen a lot of people demanding ways to perform advanced things in the game, and I believe they are right to want that. And since LUA scripting is already supported in the game, I would suggest implementing this on the client side for constructions. I would support this on objects, and not blocks. The idea is this:

• Each object could have two more properties : UID (null or none by default), and an axis. This axis could be selected via the mouse (i.e. the same way a light can be fixed on an object, etc.) and implementing this would only mean to display that axis when editing the object's properties (i.e. object edit mode)
• Activating an object would run an associated LUA script on the client. Any update made the script would update any other users nearby. Object activation could be triggered by one of these event : action key (via keyboard), or proximity

An example script could be

function onAction(event)
  -- event.player   the player information who triggered the action


  local obj = world:getObject("objectuid");


  obj:acquireLock();   -- will return as soon as the object is ready. This is essentially a semaphore implementation

  if obj:getData("closed") === false then
    obj:translate(20, 0, 0, 500, false)    -- (x, y, z, speed, absoluteOffset)
       :then(function()
         return obj:rotate(0, 0, -45, 300);                -- (x, y, z, speed)
       end)
       :then(function()
         obj:setData("closed", true);
         obj:releaseLock();
       end);
  else
    objobj:rotate(0, 0, 45, 200); -- (x, y, z, speed)
      :then(function()
        return obj:translate(-20, 0, 0, 300, false) -- (x, y, z, speed, absoluteOffset)
      end)
      :then(function()
        obj:setData("closed", false);
        obj:releaseLock();
      end);
  end
end

Obviously, the limitation of the scripts should not affact objects outside a certain range (i.e. retrieving an object that is too far away would fail, even if that object exists). and the object's original position should be able to reset in case a script mess up it's coordinates and position (i.e. obj:reset();). Also, an object UID can only be seen if the player can edit in the area where the object is placed.

The possiblity with this can allow to make

• Custom doors, windows, etc.
• Teleporters, Elevators
• Dynamic lighting
• Trains and subways, buses
• etc.

Anyway, this is a draft idea. I don't know how to integrate this with the idea of power sources (for power lines, and other ideas that were discussed the forum regarding objects requiring an energy source to work), or how to move a group of objects at once.
et me know what you think!

Quote from andyzee

Or you can just implement something like getTerrainBlockData(coordinates) etc. and leave paint-like requests to lua scripters =)

The problem with that is that the current implementation will broadcast changes when calling world:setTerrainDataInArea. Providing a way to get block data and modify then would also require exposing the broadcast API, which opens a door to all sorts of flood scripts and such. It is just unwise to do so.

This is similar to the world:placeBlock method, which only allows to place a single block, then broadcast the change to all users and the server. Implementing a script that would fill an entire area of blocks this way would probably saturate the network, or worst.

On the other side, it could be possible to change all that by implementing a queue that would push chunks of modifications automatically, preventing any flood from a user (i.e. would detect and discard when trying to send too much data). Then, world:placeBlocks(...area coords, blockId) and world:getTerrainBlockData(coordinates) could be possible, as modifying the single block data would send modifications into the queue, thus modifying block data in batch would be fine.

Sure thing! Thank you for replying! I understand that there are quite a few other more important things to implement. As a fellow programmer, I can relate! I am actually interested to see how you guys will implement water physics in JME, without sacrificing too much in performance.

I have used JME in one university (BA) project, about 2 years ago, and coming back to their web site earlier this month, this is how I got to know about Rising World. My little terrain editor is nothing compared to what you guys have done with the engine!

Can you add "green" in the list of named blocks?

/we-fill green

the same as

/we-fill id 2

Also, a command to fill, without clearing objects/constructions (but vegetation is ok) would be nice. When filling an area within construction, I'd like to leave any set blocks or objects intact. For example, putting dirt around a building foundation.

Another idea of API method :

Within the selected area, generated some randomness in land elevation. Something like

world.setTerrainRandomHeight(int ?, int ?, int ?, byte ?, byte ?, byte ?, int ?, int ?, int ?, byte ?, byte ?, byte ?, byte sharpness)

Where the sharpness variable indicates how steep the slopes should be (average), from 0 (flat) to 100 (vertical "walls")

Or, perhaps making this method into a slope generator, with randomness. Something like

world.setSlopeTerrainDataInArea(int ?, int ?, int ?, byte ?, byte ?, byte ?, int ?, int ?, int ?, byte ?, byte ?, byte ?, byte sharpness, byte orientation)

Where orientation is a value from 0 to 4 indicating the direction of the slope.

The API is great! Although having named arguments instead of "paramInt1", "paramInt2", etc. is counter productive... It would be better to have them named so we actually know what they are...

Aside from that, the World Edit script makes it possible to flatten a piece of land, etc., and put grass (well, make the area "green") where there is dirt, however when a player makes a nice slope (in dirt...) with the rake, it is not possible to make that slope "green" (in grass). Would it be possible to have a paint method? Instead of filling the area with data, just change the current blocks data to the specified value?

Something like :

world:paintTerrainInArea(c[1],c[2],c[3],c[4],c[5],c[6],c[7],c[8],c[9],c[10],c[11],c[12], blockID);

Is it me, or the command "/we-clear all" does not clear any blocks? Would be nice if it did.

The game just crashed (froze) and I had to kill the process again. It happened at around 10:55am EST (GMT-4.00).

However, I may have a solution. Since the game already saves a "login.dat" file, once a user logs in, the auth server should return a login token (that should be saved in the users database along with the user login information), that would be saved inside a "session.dat" file.

1. If the game exit properly, delete the "session.dat" file
2. If the game is launched and a "session.dat" file exists, send the login token.
2.1. If the login token is the same as the last generated login token, generate a new token and assume the user's game failed to exit properly.
2.2. If the login token is different, the account is already in use (i.e. default to the default behaviour)
2.2.1. If this situation happens often, report account for investigation (logging the connecting IP, etc. for more information)

What do you guys think? It's simple and does not open doors for fraudulent usage.

I am unsure at the time you checked the database. I tried every once in a while until it finally worked. I should probably have paid more attention of how long it took for it to succeed. Will do that next time.

Same problem, now. There was an ISP problem and lost connection for a few minutes. Now my account is already in use. There should be some way to "reset" the account... To prevent duplicate (fraudulous) connexions, the reset process should logout any connected clients that are connected to the Internet.

This is a duplicate of Account already In Use (or at least, is about the same subject; should perhaps be merged)

Quote from ZaCormyr

Nice work red! yeah I hope this to be a function in game (for creative mode) instead of an outside script like a mod.. if that makes sense. At some point of course, not next update if not possible. Thanks man!

Maybe this could even be useful with in game computers at some point... not sure how.. just planting a seed.

The game should come with pre-existing LUA scripts. At the moment (version 0.5) there's no script provided. I am not in favour of having these functionalities "built-in", but the game should provide an extensive API so more scripts can be written and, ultimately, be community driven.

I just had this problem; my router crashed and, upon restarting it, I can not log into the game as it says "Account already in use". This message appears not only if some "Rising World" (i.e. Java) process is still running in the background but, for whatever reason, the game loses connection without disconnecting (ex: crash, network failure, computer power loss, etc.).

I'm on Linux, so I switched to VT1 and killed the entire "java" process tree. Then I restarted Gnome Shell. The game was running at about 1 FPM (yes, minute), and it consumed 100% of all my CPUs (I have an i7!). It actually took me a solid 10-15 minutes to shut it down... I edited the "risingworld.sh" executable and adjusted the memory to 4GB instead of 1GB (I have 16GB total). I'm not sure how long it took to unlock my account, or how the account was unlocked, as I was only able to retry after work, today, and was only able to log in tonight. (I have not restarted the computer since the last Kernel update... about 4-5 weeks ago.)

There didn't seem to have any remnant of the game running in the background as killing all "java" terminated the entire processes trees for the JVM... and the CPU and memory usage was back to normal.

Quote from LordFoobar

Same here. Would be nice to have something to cleanup unresponsive accounts. I waited for an hour, but the game still won't log in ("Account already in use"). Since the game is in it's early stage, I suspect this will be a common problem... and not so much fun! As a solution, the game should implement a hardware profiling check-up, and send that profile when logging in. This would benefit in at least two things :

1. when blocked, a login attempt using the exact same hardware could unblock the account;
2. when unblocking, DEV could assume something went wrong and the game crashed (or something like that) and needed to be restarted without logging out first.

Of course, there's always the matter of hackers forging data; so sending the current IP and date could help, too. Resolving the IP to a location is fairly easy, and this information can be saved along with the credentials so further attemts can validate some form of authenticity. Or, at best, log the last X logins and check for some discrepancy (ex: alternating IP addresses, multiple logins with no logouts, etc.)

My 2 cents.

Display More

just registered. I came from the Website and thought I was already logged in.