Posts by LordFoobar

Quote from yahgiggle

also if your worried you could say he forked it from the protection script as some of the code he used is from that ie we-select

not saying he did but thats just a fact about coding some lines need to be the same to get the end result

or we could just keep it as is and use my chart for the block info haha

Display More

I would never appropriate someone else's code without having a damn good reason to This is what I do for a living (code), and I highly respect the works of others, regardless how much efforts they had put into it. Besides, my additions were mostly copy / paste of the existing code as well.

Quote from yahgiggle

yeah that looks good to me now all you need to do is make us the full script lol i know your just dying to do it hehe man my heads starting to implode just thinking about it

LOL

Yeah.... If the original author can make a Github project out of the script, I could fork it and make a PR for changes... That would make things much easier for everyone. I just don't want to take ownership without permission. Using Git, others could contribute as well.

If would be, something like

if blockType == "block" or blockType == "b" then 
  ...
elseif blockType == "halfblock" or blockType == "hb" then
  ...
elseif blockType == "ramp" or blockType == "r" then
  ...
elseif blockType == "stair1" or blocktype == "s" then 
  ...
...

They could be aliases; long names = short names. I did not invent these names they actually are the ones used in the game itself. (With the command item.)

Quote from yahgiggle

Ok i talked to Red and for halfblocks you add 195 to the id so did some testing of my own and found you can change the prossion of the blocks like so

195 halfblock bottom
198 halfblock center
201 halfblock top

so if your id was 37 and you want the block at the top you type /we-fillblock 20137

What if the id is, for example, 186? Would it be 20100 + 186 = 20286 or "201".."186" = 201186 ?

I am asking as we could amend the command to add optional values to the command arguments, such as

/we-fillblock id [blocktype [rotation [orientation]]]

Where

• blocktype could be one of block, halfblock, reamp, rampcorner, rampcornerhalf, rampcornerinner, cylinder or cylinderhalf (not sure about the other block types) (default block)
• rotation could be 0, 1, 2, or 3 (where angle = rotation * 90°) (default 0)
• orientation could be up, side, or down (default up)

For example

/we-fillblock 126 ramp 1 down

to place a ramp upside down, rotated 90 degrees. (Note: only id is mandatory.)

However, there might be issues with some block types and orientation that must be taken into account when processing the command. For example, cylinders and ramp corners cannot normally be placed sideways, only upward or downward.

Well, for those having any trouble with my proposed addon, here's the entire script for your own personal use, until it is approved and/or officialized

The command is, for example, /we-select then /we-fillblock 121 to fill the area with bricks.

Quote from Bogus

I have the code-snippets addet to the script, but I not know is this right.

[snip]

I testet in SP and I have no errors ..

Less the lack of indentation in your post ( ), it seems alright. If there are no errors, and you can fill your selected area with blocks of the specified ID, then yes, it is right

Quote from yahgiggle

what would the id for half blocks be i tried halfblock 37 as thats what you use for item but that wont work for /we-fillblock ??????

I actually woke up this morning with the same question Also, if blocks need to be rotated; how to apply rotation?

Maybe one of the devs can answer?

Can you please add this to the script?

-- start: line 108
elseif cmd[1] == "/we-fillblock" then


  if #cmd >= 2 then
    event.player:disableMarkingSelector(function(markingEvent)
      if markingEvent ~= false then
        coords = getCoordsFromMarkEvent(markingEvent);


        fillWithBlock(coords, cmd[2]);
      end
    end);
  else
    event.player:sendTextMessage("[#FF0000]Specify the block ID");
  end

And the function is quite simple, really :

function fillWithBlock(c, blockID)
  world:setBlockDataInArea(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);
end

Don't know why no one proposed that already... Tested and works great.

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?