Posts by LordFoobar

I am nearly completion of refactoring the AreaProtection script. It is now in testing phase for all those who'd be interested to check out the code and test the features, and such.

Read the README carefully. Do not use on a public server! Backup your current area protection script database before using this branch.

Roadmap

• Enable the rest of the player events; place blocks/constructions/etc., remove blocks/constructions/etc. and all the other building rules (needs testing)
• Implement the help command (as of 2015-05-12)
• Localize all strings (as of 2015-05-12, only English provided... I don't speak German )
• Testing group hierarchy rights
• Allowing specific group members to create limited areas (ex: a landlord can create limited areas on it's domain area) (Note: some security issues with overlapping areas and rights...)
• Minor tweaks.

Using an existing world and scriptDatabase.db file should work; there are some structural changes in the refactored Area Protection script, but all data should be imported just fine. But still, backup your scriptDatabase.db anyway

Cheers!

Anyone still updating this API reference?

For now, I'm manually extracting the .class files and using javap to view the internal API....

A user who, for some reason cannot log on to the forum (??), sent me an email that TManGamez is going about and sending "gifts" to players and annoying them. I don't know who he is, but his player name should be posted on the watch out list.

My guess is that, while your server can connect outbound and announce itself, others cannot connect as they are blocked by your router.

• Make sure that your server has a reserved IP address (static DHCP) on your local network (LAN)
• Forward all inbound connections from your configured port (see server_port in your server.properties file) to your server's local IP address (passthrough connexions from and to the same port)
• Use a tool, such as this one, to check that your server is responding

Then it should work.

It would be nice to have some way to specify the loading order of scripts. This way, a script could mark an event has "handled" and prevent other scripts from picking them up (i.e. short circuit the event, and stopping it from bubbling).

My rationale is that, on some servers using AreaProtection or WorldEdit, even when entering a valid command, a "Unknown command" is still printed from some other scripts. This could also help ensuring that AreaProtection is loaded first, thus truly preventing any invalid editing by stopping the propagation of the event to other scripts.

An idea would be to use the same principle as init.d in Linux, by prepanding a loading order in front of the script's directory. For example

./rising-world
  ./scripts
    ./00-area-protection
    ./05-trustlist
    ./14-teleport
    ./30-world-edit
    ./99-custom-script

Any scripts not having a loading order prepanded would be loaded after in their normal alphabetical order.

Good point. I will add an auto-ban to AreaProtection... those who want to comment can discuss it's implementation here.

I have seen the comments on Steam (I bought the non-steam version) and, honestly, the only negative comments are about not having the proper hardware. My point is that people don't buy smart, and making the game on sale will just increase the number of dissatisfied players because:

A. the game is still in alpha and, while there's plenty to do already, lack some contents (i.e. RPG features, settings, skins, etc.)
B. even if mentioned numerous times in comments and descriptions, etc., people with older or cheaper computers, will buy the game before checking if they can run it.
C. people are lazy and don't understand why installing Java is a good thing. Heck! they install .Net for other things and don't complain!

At the moment, the price is fair, and is low enough not to attract too much of these players. At the moment, what I see are players that love this game and are here to help fix things and suggest (even propose) new features. Perhaps make a special sale in a beta stage, or something. Just not now. IMO.

Thinking about it, it should perhaps be a separate function...

player:setInitMarkingSelector(function ()
  if previousSelection then
    return previousSelection;
  end
end);

Then, if the callback of setInitMarkingSelector returns a non-nil value, it should be a table (i.e. object) with the proper attributes to set for the initial selector start and end point coordinates.

The next function would then be

player:enableMarkingSelector(function (markingEvent)
  if markingEvent ~= false then
    print("Initial marking selection set);
  end
end);

Currently, enableMarkingSelector always pass false to the callback function.

Quote from yahgiggle

they said they might add locking stuff later on its at the bottom of the list but its there

I am slowly working on an update for AreaProtection (could've completed an RC version last weekend, but had some last minutes schedule change...) Once it is ready, you'll be able to have your area protected and allow certain players to open doors only. (No admin needed.) I'll upload a dev branch (that should not be used on a public server) to the github repo this evening so others can review the changes as they are edited.

The sliding glass door is an idea that has been floating around for some time, now... And I can't wait to have them as well!

Quote from Bogus

When I make the command setspawn on a server, is that for all user or only myself ?

All NEW players connecting or when a player dies

First, thank you for the quick fix on the marking selector "thing"! It was a quick fix that got a lot of server owners relieved

Anyhow! It would be great to be able to set the initial coordinates of the marking selector. For example, when resizing an area in AreaProtection, the script could just invoke event.player:enableMarkingSelector(...) and the player could already have the current area's boundaries selected. Another example would be when selecting an area, invoking some commands and realizing the selection should've been just a little wider. I managed to go around this with the latest World Edit by adding -p flag, however I could also add a command to recall the last selection... just in case.

The way this could be implemented is fairly simple; the callback function receives a markingEventStatus object or a false value (in fact, player:enableMarkingSelector seems to always get false); if the callback returns anything, it should be the markingEventStatus, or any compatible table that should modify the selection. Naturally, some values should be capped to avoid WTF situations, but this is trivial boundary checks.

For example, this could be an implementation

--- Start new selection. If there was some previous
--- selection saved, use it as initial selection boundaries
player:enableMarkingSelector(function ()
  if savedSelection then
    return savedSelection;
  end
end);

This is no rush, but would greatly enhance scripting.

Quote from red51

It will be added in the future^^ First we need to do some changes to the block system, then we will add several new forms

Fair enough

Why can't we place ramp corner and ramp corner half sideways?? I believe this is not so difficult to do... no? We can place ramps sideays after all...

@DHLF, your concerns have been noted.

Concerning player names, there is already an API to get a player from it's ID. Since players are not deleted, it's ID will always return it's name. There's really no need to duplicate this value locally, in the script's DB.

As for the area name still showing on screen, even after removing it, yes, this will be addressed in the upcoming changes.

Quote from DHLF

I was thinking about adding the ability for some "trusty" players to use the command /addplayertoarea.
A quick look into the script files keeps me speechless.. I really expected some check like "if playerisadmin" like I saw in other scripts.
Instead of testing IsPlayerAdmin for each "forbidden" command you shortened it by:

Code

if event.player:isAdmin() == false then
     event.player:sendTextMessage("[#FF0000]You are not an admin");
     return;
end
 **your whole code thought for use by admins**

While this keeps the code smaller it runs into a slight issue:
If the player is really not an admin and he tries one of the "allowed" commands like /showareas the command will be executed but at the end it will still show "You are not an admin!".
One possibility to avoid this is to exit this (I dont know lua, so.. ) if there is something to exit the whole function.
Another possibility could be to change the code with two lines like:

Code

if event.player:isAdmin() == true then


     **your whole code thought for use by admins**


else
     event.player:sendTextMessage("[#FF0000]You are not an admin");
     return;
end

Display More

Thank you for sharing your concerns. I am currently modifying the AreaProtection script, with the help of others, to add features and fix things like that. You can come on IRC (freenode.net, channel #risingworld) if you want to chat with us!

Cheers!

Script updated on github! Please take a look at the updated README for updating instructions. Also, check out CHANGELOG for more information about the recent updates. The most noticeable change is the -p option, which will preserve your current selection and not discard it after filling, placing, or clearing it.

Example usage :

/we select
/we place block 121 -p
/we place block 122 -p
/we clear abs -p
/we fill grass

Note that only one /we select is issued.

Cheers!

Quote from red51

A small update has been released which fixes some problems You find the changelog in the initial post.

Awesome!

Quote from Meltron

Just wait for the official wiki I guess

Seems to be soon as it no longer 404 when clicking the WIki, on rising-world.net

The thread should get updated. There are new blocks, and a lot of missing objects in this reference. I'd love to have this document collaboratively editable so we can all update as needed.

@red51 can you take a look at this?

https://github.com/RisingWorld/world-edit/issues/2

There is a getMarkingSelectorStatus function already, could there be a setMarkingSelectorStatus ? Or will updating the markingEvent object simply change the selection directly?