Posts by LordFoobar

A new update is now available, introducing seasons and more!

    Adds something like a pot belly stove that burns firewood as fuel. {snip}


    Except from torches (big and wall mounted, etc.), fireplaces and furnace should, indeed, require wood to have fire. This would create ambiance in the game. For example, you are approaching a house in the middle of the forest and all is pitch black... with eventually murderous creatures or other dangers... you go in and use some wood to light up the fireplace and finally have some light (why not warmth as well? The cold could cause some side effects, like slowing you down...). Or, another example, you're again in the middle of the forest at night and you see lights inside a cabin... ...


    You could even extinguish the fire and light it up again later on, and other players could potentially steal your firewood from the fireplace :)


    Bottom line, great suggestion!

    A little update on the script. Still a lot to do! But it should be more functional, now. For questions, and suggestions, I suggest creating issues directly on Github. For general chat and other discussions, this thread is the place for that!


    ... and a reminder that... THIS IS NOT READY FOR GENERAL PUBLIC USE!!!! This is for testing purposes until mentioned otherwise :)


    Thank you @yahgiggle for your time at testing this

    Another update was made on the script. All terrain textures are now available via the /we fill command. Also, long help lines are now wrapped!


    The README was updated! Those who do not install using Git (aka manual install) should not forget to add the string-ext sub-module also!


    Some tools are coming to make everyone's life easier installing and updating scripts :) I don't know when, but the idea is brewing....

    The projects on Git are moving well! I have added a "Translators" team for anyone who'd like to add localizations to the current localized projects (area-protection--in dev--and world-edit as of today). No need to clone the scripts to be part of the team, as you'd have write access to the organization's repositories. Also, all issues should be reported on Github, preferably, to keep logs of corrections and new implementations. (Note : an "issue" can be a feature, a bug, a suggestion, etc.) As well, you will receive updates on your issue as it is updated and/or resolved.


    Any other question can be addressed directly to me via private message.


    Thank you for your contributions and collaboration!

    I think that everything should be original to begin with (on the finished game) so you have the radio object, as suggested, and the guys have created hundreds of original tracks and several radio stations, perhaps categorized by genre, for example they could have a station called dr.danceduck, and they could specialize purely in dance music.
    I strongly hope that the computer object will be a powerful customization hub, and allow you to add your music into the game. haa! Just my 2 cents, so to speak. hee hee!


    ... and I hope they create a virtual reality headset object that you can use with that computer object... 8o

    I don't know about that... personally, I would not use that feature. If I want to play music, I fire up my Rhytmbox (Linux) and just use keyboard shortcuts to control the music as I play. Since almost everyone play music differently, I don't think it would be wise to add this feature in-game.


    Or perhaps if someday there's a "Radio" object... but this needs other considerations (i.e. copyrights, DRM, audio codec, bandwidth, etc.)


    Sorry to burst that bubble :)

    Alright, that's what I guessed. So... if I understand this, LuaPlayer strictly returns an online player, currently connected to the server, while LuaPlayerInformation returns something only if the player has connected to the server at some point (online or not), am I right?

    No, just invoking Lua statements. For example, in World Edit, there's a function called getBlockId; being able to invoke that function directly from the console would return the value, thus help debugging and test. Or, in some script, if there's a global variable that should be set to a specific value, instead of trying to recreate the condition for that variable to be set properly, just invoke the console and set the variable manually. As simple as that.


    Or, for example, I'd like to evaluate the content of a player's attribute, live, while the server is running. I could simple test it in-line from the console. From a terminal, the Lua console can already be invoked, but there's a difference between that console and the game's. For instance, from a native Lua console, there's no include(), there's no getDatabase(), there's no getServer(), etc.


    Some typical use could look like this :


    Code
    $ telnet -l "AreaProtection 1.7" 127.0.0.1 23
    Rising World Lua Console Started
    Binding to "AreaProtection 1.7"
    > return server:findPlayerByName("LordFoobar");
    nil
    > = #areas
    47
    > ^C
    Connection terminated
    $


    Using the login name as the script to bind to (same name as in the definition.xml file). Using CTRL+C to quit.

    In AreaProtection, players are saved using player:getDBID(). This value matches the ID field in the table Player of the world's database. However, performing server:findPlayerByID(playerId) (where playerId is the saved value) does not return anything; nil. Is this because the player is not connected, therefore the method returns nothing? Shouldn't that method fetch the user in the World's DB instead if the player is not connected? What's the alternative, then?

    Once a server is running (or perhaps in single game, on localhost), it would be nice to be able to send some Lua commands via simple socket connection and get the execution result. The commands would execute in the currently running server Lua context. This would greatly help debugging. Naturally, this socket would listen for incoming connections on the LAN interface only! Such implementation could be done using a Telnet interface (using PuTTy for client in Windows); the telnet interface would litterally work as a direct console to the server's Lua container; to be able to manipulate data while the server is running.


    This interface would, of course, only be enabled through the server.properties file, using a configuration keys such as lua_console_enabled=true, lua_console_port=23, etc.

    If this applies ton only blocks, yes, it would be possible... but it would destroy ALL blocks in the specified area. It would not be possible to preserve any other previous blocks. It would be interesting to implement this once it is possible to copy / paste entire regions at some point.

    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!

    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


    Code
    ./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.

    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...


    Code
    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


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


    Currently, enableMarkingSelector always pass false to the callback function.

    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! :)