Posts by LordFoobar

I would like to propose the event PlayerAction.

This event would be triggered if a player presses the "action" (i.e. "F", or KEY_F) key. The handler would receive :

• the player (lua.wrapper.LuaPlayer), and
• the chest (lua.wrapper.LuaChest), or the door (???), etc.

being activated.

If an object (ex: a chest) is being activated, it would prevent the user from even opening it, thus making it locked.

This event should also be triggered even if no object is being activated. This would enable scripts to handle the action key when the player is in an area, for example.

For example

function onPlayerAction(event)
  if event.object != nil then
    if (event.objectTypeID == OBJ_TYPE_CHEST and checkPlayerChestAccessRights(event.player, event.object) == false) or
       (event.objectTypeID == OBJ_TYPE_DOOR and checkPlayerDoorAccessRights(event.player, event.object) == false) then


      event:setCancel(true);
    end
  else
    -- handle action when no object was activated
  end
end
AddEvent("PlayerAction", onPlayerAction);

I am aware of the PlayerObjectStatusChange event, however this even if too limited and would not trigger when the action key is pressed. As a fallback, the PlayerAction could get fired if the action key is pressed, but PlayerObjectStatusChange does not apply. Moreoever, if cancelled, this event would even prevent PlayerObjectStatusChange from being fired.

Quote from yahgiggle

i think it users AUTO_INCREMENT for the id so id 1 would be area id 1 area 2 would be area id 2 and so on to remove the area you need to be inside it so then it would only remove the right id of that area you are inside

You are mistaking MySQL id (a PRIMARY KEY AUTO_INCREMENT) with an area id, which is defined when calling player:createArea. I am talking about the latter.

While I think it's a good idea to have an external management system for scripts, configurations, and all.... why isn't it coded in Java, the language Rising World is written in, which is not only cross platform, but is not dependant on a 450Mb+ framework (i.e. .Net), and less WTF-prone?

BTW: the link to the .png is dead.

I'll answer my own question : Yes, it will create areas of the same id every time, and will not replace a previous area of the same id.

I was wondering if calling repeatedly player:createArea(area); player:showArea(areaId); , where area[0] == areaId , with the exact same values created multiple areas with the same id, or was replacing any previous area?

I am trying to wrap my head around the fact that the game won't load because of my script. Two of my includes scripts cause the game load to fail with no errors; it just stops and hangs at the loading screen. When I comment the two includes, everything is fine. These two includes register the command and player events. I have tried to run the script inside the Lua CLI program, but the global function include does not exist.

The console debugging is enabled, so I see where it hangs, or not. But there are no errors being displayed, so I am not sure where or why it hangs. Any idea of how I can debug instead of launching and exiting the game every single time?

How do I sanitize values being inserted into the database?

For example, for a given user input string fooString, how would i sanitize it's value before inserting or updating the table?

Since there's already a way to load properties, I believe only a simple option to detect the player language should be fine.

translations = {};
translations["en"] = getProperty("locales/en.properties");
translations["de"] = getProperty("locales/de.properties");
translations["fr"] = getProperty("locales/fr.properties");
...


function t(player, msg)
  return (translations[player.getLocale()] or translations["en"] or {})[msg] or msg;
end

Quote from andyzee

reload game client if you are doing this in singleplayer
there should be no issue when restarting a dedicated server

Well, yes, that's what I figured. But even restarting the game is only but a temporary fix. It is an issue in singleplayer, and it does not help debug scripts.

As for the server, the term "should" is what bothers me, and thus why I asked for more precision--as I know it happens in singleplayer, but did not bother test a server since I do not necessarily need to test one at the moment.

My point is that, even when you load a same world in singleplayer multiple times, the console shows the scripts being loaded every time. However, AddEvent is supposed to be "locked" once onEnable is called. The fact that I received two outputs for two different singleplayer game instances (i.e. the same world loaded twice, and the same script loaded twice), shows that AddEvent is persistent, and the scripts are not being unloaded correctly. And I was wondering if that'd explain lagging server issues, too.

Yes! I totally support that suggestion; about the lua events. Much better than a static config key.

AddEvent("PlayerGameTypeChange", onPlayerGameTypeChange);
AddEvent("PlayerMovementTypeChange", onPlayerMovementTypeChange);

that could be cancelled on certain conditions. For example, prevent flying in certain area. Or prevent creative mode in a specific area (ex: arena), on enforce it in others.

I was playing around with an idea for a script and wondered why I always had error on lines that had no code. The error was going away when I was exiting the game, but errors would persist even after I fixed them in the code.

So I tested

local function onPlayerCommand(event)


  print("Ok");


end -- function onPlayerCommand
addEvent("PlayerCommand", onPlayerCommand);

And, sure enough, it printed just fine when I typed any command; it echoed "Ok".

hen I modified the code and changed "ok" to anything else (i.e. "Hello world!"). When I reload the world, and typed a command, I got two output :

Ok
Hello world!

So, I thought, WTF? The event is not being unregistered/cleared when going back to the main menu and reloading a world?? Can it be possible that other scripts suffer from this, too? (i.e. areaprotection, worldedit, etc.) If so, no wonder the server crawls to it's knees when many users connect, get disconnected... especially admins, and commands are typed; they must be applied multiple times!

Any thoughts, precisions?

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.