Posts by Miwarre

Quote from Cartephylus

I know tree spawning can be done via a script because i saw the planting script. But how much cpu load would a script cause, that implements self planting trees like i suggested above. It's a huge job, But if could be done a little at a time, Maybe it wouldn't be so bad.

Wait, wait! You are missing the most important part. The planting script just adds trees out of nothing according to parameters. A spawning script should work on the existing trees, adding new exemplars of the same kind at reasonable, even if random, distance and spread. It should also take into account existing room: for instance, in most RW pine forests there is actually no room for new trees.

Then, the script should know where each existing tree is, of which type it is and how distant from other trees (of whatever kind). I don't know if the API currently support this type of query. Then, of course, CPU load might be a concern, given the number of trees in an average RW world!

Quote from mjminfo

BTW if I replace the whole dir with the new one, will my wp's still be saved or they get erased ? if they get erased, what files do I need to keep in order for them to be saved ?

Sorry, busy week-end! I assume you found the answer in the meantime. But, in short, the WP are kept in the gps-<world-name>.db file; if you keep this file, your WP's will be safe.

@mjminfo please have a look at the GPS original thread...

A new 1.3.0 version of the GPS plug-in is now available.

New:

*) A list to select WP's to share and share several of them with a single operation.

*) Some bug fixed.

Details and download in the top of this thread.

@Jon_miner:

Glad to know it now works as 'expected' (between quotes, as even I, I am not sure what to expect!).

Calculations: unless I am severely mistaken:
1.75 real secs per in-game min * 1440 mins per day = 2520 real secs per in-game day
2520 real secs per in-game day / 48.7 changes per in-game day = 51.745379877 real secs per change

(and, yes, I imagined there were testing settings, not to use on a 'production' environment!)

Seasons: it is surely a matter of taste and personal preferences. I like to have some variation along the (in-game) year, as it gives some impression to be in a more 'living' environment.

For instance, with the default 1.75 time speed, one in-game year = 2520 * 365 = 919800 real secs = 10d : 15h : 30m (real time). If one connects to a given server regularly every day at approx the same time, he will find the server advancing of slightly more than one month every time and a different combination of weather types every time.

The limitations you quote are true, though.

'Vanilla server' settings: no idea, but I suspect that, without any manual alteration, there are 4 - 5 weather changes per day. Distribution seems more or less the same across all types, as I usually find very little 'good' weather. But these are pure speculations...

@Jon_miner: thanks for your testing! In fact, I accidentally removed some lines while 'cleaning' the code (too aggressively, it seems!).

I have uploaded a 0.1.1 version which corrects the bug.

I have also noticed that, with your test settings.properties file, new transitions were started (once the bug corrected) before the previous one could complete. I have added a minimum weather cycle duration of 70 seconds (for the record, your setting had a weather cycle of about 52 seconds).

P.S.:

*)The difference between "default" and "clear" seems to be that "default" is the weather used before weather changes were implemented: nice weather with a few clouds; "clear" is 0 clouds.

*) If a probability value is set to 0, that weather type should not occur for that year period.

Quote from lenko

I think the idea is good. It is perhaps a little complicated to understand [...]

Well, it is intended mostly for server owners (or local play); interaction is also limited to setting 'tuning' with the documentation right in sight. So, there is nothing really complex to remember or to understand.

If the explanations in the settings.properties file need improvements, please let me know.

Also, I noticed that, as everything is probabilistic, most changes are observable over some time of play (some hours), rather than immediately.

Sorry for the late reply...

Adapting for translation is rather easy; for RWGui it is a bit more complex (just a bit!).

I noticed you didn't set a package in your classes: it would be wise to set one! Can you decide for a package name?

A plug-in along the lines I described above is now available here.

The whole thing is rather experimental: feedbacks are very welcome!

A plug-in to customise the probabilities of the various types of weather.

Version 0.1.1 Experimental!

- Features:

*) Probabilities of the 10 types of weather supported by RW.
*) An in-game year is split in 25 periods, each of which can have different probabilities.
*) Rate of change.
*) 'master' setting to reduce variability from full use of all weather types progressively toward more favourable types, down to default weather only (good weather with some clouds).

- Commands

There is no command, as the plug-in is intended as "fire-and-forget": just configure it as you prefer and run it. As there is no user interface, there is also nothing to localise.

Installation

*) Extract the files in the ZIP placing the whole weather folder into the plugins folder of RW (if the plugins folder does not exist, just create one). The resulting hierarchy shall be:

── RisingWorld
    ├── plugins
    │    ├── weather
    │    │    ├── settings. properties
    │    │    └── weather.jar

Notes and open points

*) The provided settings are aimed at a nice, Mediterranean / temperate kind of weather. Play with settings to achieve different types of climate.

*) As in R.W. the weather is global, all biomes share the same settings.

*) The whole thing is experimental: it should not crash, but the actual results are yet to fine tune.

*) Some of the settings are not obvious: please read the explanatory comments in the settings.properties file carefully, before modifying them!

*) Transition form one weather type to another may take up to 60 / 65 seconds. As I have no idea if starting a new transition before the previous is completed may adversely affect the system, a minimum limit of 70 seconds has been put on the weather cycles; if the changesPerDay setting is set to a too high value resulting in too fast weather cycles, a minimum delay of 70 seconds is forced between transitions.

*) Feedback is welcome!

Ah, I see! thanks for the clarification.

Quote from red51

However, as a workaround you could retrieve the value from the server.properties by using the getOption() function, e.g.:

Java

String val = getServer().getOption("settings_time_speed");
float timeSpeed = Float.parseFloat(val);

Of course! I didn't think of this!

Am I blind or there is no Server.getTimeSpeed() API method to retrieve the time speed set in server properties?

If it is not there, it would be a useful addition...

As far as I can tell, Player.getPermissionGroup() always returns an empty string.

I tried from the PlayerConnectEvent and from the PlayerSpawnEvent, with an admin player and with a non-admin, always receiving a null string.

Am I forgetting something, or the method is currently not supported / implemented?

My idea about a weather plug-in is somewhat more complex.

The game has an internal calendar, it is then possible to get the current month and day => season. A plug-in could then set a prevalence of clear sky with very occasional storms during summer, more rain and some fog during autumn, more extreme conditions during winter (very bad weather alternated with very clear days), much rain during spring.

A "master volume" setting would tune the whole from a strong prevalence of default weather to the full variability.

In principle, it would be possible to establish a daily cycle too, but unfortunately wind is not supported separately (the wind cycle tends to be daily). Also, it would be possible to define several weather patterns (a 4-season pattern as in temperate latitudes, a 2-season (dry and wet) pattern as in equatorial latitudes) but probably, as the weather is global for the whole world, it would make little sense.

I'll try to summarise (and integrate) the comments I made to my own post quoted above.

1) Custom permissions can already be added to permissions group files, as long they follow the general syntax (I tried and the server didn't complain). Those custom permissions are simply ignored by the server.

On this side, there would be nothing to add.

2) The Player.getPermssionValue(String key) method only returns values for keys it knows about; it does not even return a value for top-level permission properties like "group" or "chatcolor" (it simply returns null). It should return a value for any key actually present in the permission file.

This should not require a big change in the code, as the permission files are already de-serialised.

The two steps above should already cover the bulk of @zfoxfire request.
____________________

Then, a few notes:

A) The current syntax for sub-level keys uses a '_' as level separator (The key customimages:\n enabled: is expressed by the string "customimages_enabled"). This is unusual and may become cumbersome if one of the levels already contains an '_'.

A different separator( '.', '/', ...) would be better. This is actually rather low priority, though.

B) The possibility to query for a non-terminal key (for instance, "customimages") and have back a structured object (of whatever kind) is nice, but not so important, IMHO, particularly if this would require to add new code to the server to construct such an object on the fly at each request (I have no idea how permissions are stored internally).

Also, it would possibly defeat encapsulation: as the object is always returned by reference, any caller could modify it directly, which is probably not wise to allow.

The ability to query only terminal keys ("customimages/enabled", "customimages/maxupload", ...) would be enough; it would require a few more API calls, but it would also spare (server) code to construct the structured object and (plug-in) code to parse it.

C) Of major concern: currently plug-ins are completely self-contained in their respective directories; 'polluting' the permission files with plug-in-dependent keys would break this self-containment and risk to leave behind 'dead' values as plug-in are removed or updated.

D) I am not sure this would actually simplify permission management. For instance, assuming there are 3 plug-ins, each with two permission values, all boolean (a rather conservative assumption); this would require up to 2^6 = 64 permission files to manage all the possibilities.

Sure, not all possibilities would make sense, but the number of permission files to create, debug and maintain risks to be quite high anyway.

E) Some convention should be established and enforced to avoid key name clashes; the proposal suggests to group permissions for a plug-in under a top-level key with the name of the plug-in. In fact, even plug-in names risk not to be unique (I think there are already several teleport plug-ins). I have no idea how any chosen convention could be enforced, though.
____________________

Summarising, even if something to simplify the management of plug-in-related permissions could be useful, I am not sure this would be the way to go.

Even if the discussion has been carried away by disparate comments, I noted the same and asked for improvement suggestions here.

Quote from mjminfo

when I try, I only get 1 choice (the last WP I exported) and there is no list of all the export I made before

This is not expected; the list should contain all the exported WP's by whomever. I'll check what's going on.

Quote from mjminfo

Yes. I would get an export window that lists all of my WP's and from there I have the possibility of choosing to export more than 1 , and to rename then if I want or keep the same name and export them to the global shared list

This is precisely what I tried to avoid, to limit the flooding of shared WP's by users (and to simplify somewhat the implementation).

Quote from mjminfo

No just my private WP's so I can see them at one time and choose which ones to export.
as it is I have to go from one to another in order to choose which ones to export, so if I want to export let's say the 1st one and the 15th one I have to go through all of them.

If I had the window I could highlight the number 1 and 15 and click on export

So, you want a list, and with multiple selection... not a trivial task, given that everything should be done from scratch with minimal support from the API... Also note that the current interface is 'circular' and the 15th WP is only two clicks at the left of the 1st (1 click to the home point and another click to skip it and reach the 'last' WP).

And anyway, this would still require a separate step for each of the selected WP's, to edit / confirm its shared name.

I still believe that it would be a fair amount of work for little gain, eventually.

Quote from mjminfo

the WP's globally shared by everyone.

So, a list of the WP's already exported by someone.

Sorry, there might be something important behind this, but I still fail to understand the exact request:

1) This is different from your original request:

Quote from mjminfo

add to the export more than 1 wp at a time ?

which I get as meaning the ability to export more than one WP at a time to the global pool.

2) A list of all shared WP's is already implemented: when you press the button to import a WP, you get precisely a list of all the shared WP's.

Quote from mjminfo

then we can choose to export 1 of ours to the Globally shared list or to import from the Gobal list into our wp's

which are two different operations on two different sets of WP's (the first on your private set to the global set, the second on the global set to your set).

Do you want a list which mixes your WP set and the global set?

Do you want a list of all WP's privately defined by anyone? I am not sure other players would agree on this...

As far as I know, such a plug-in does not exists, not it can exists right now, as the plug-in API does not support chest interaction yet.

Chances are the API will be extended (soon?) and it will be possible to support this kind of operations...