A nice feature IMO would be the capability for the "Owner" of a shared WP to be able to remove the shared WP from the "global/shared" list. The added ability for an "admin" to remove any "global/shared" WP would be nice too.
Please see here a proposal I made a few days ago; in fact, I am thinking about removing the shared WP's feature altogether...
Greetings.
I was using the plugin normally in the single player, but today I started a new map and the plugin was no longer "resource-free", "asked" for wood to add PLANKs to my inventory.
Should that happen?
I edited the "settings.properties" txt and I think it solved.
The plug-in defaults to "non-free"; if you re-installed it, chances are it reverted to default settings. Of course, in single player, it is not necessary to re-install the plug-in when a new map is created: plug-ins are common to all the local worlds.
Anyway, do I understand correctly that the problem is solved?
I meant real world time, imo it is easier to estimate how long I want something to last in real life than game time and get confused by conversion factors
LOL You are right about " I believe that either choice is going to suit someone and not someone else..."
Although I agree that it is easier to "estimate how long I want something.." in Real Life Time, I also think that the simulation rate SHOULD affect everything, including weather and therefore these should be in Game Time. The conversion is not that difficult for those who prefer Real Life time.
In fact, the difference between the two possibilities is just one multiplication to do or to skip; it is easy to make it a setting choice.
Event type Minimum time length maximum time length Rain 1min 4min Clear 10min 20min
It makes sense and it would be not very difficult to implement.
Question: Am I correct in assuming that you think in terms of real time duration ranges, rather than game time duration ranges? The implementation is practically the same -- there is only one scale factor not used or used --; the main difference would be that, in the first case, the timings would not be affected by the simulation rate, while in the second case they would. I believe that either choice is going to suit someone and not someone else...
Any explicit preference?
Question: If one were to set "changesPerDay" to something like 0.25 so that there are only changes to the weather every 4 days. Would the duration of any change/event also be 4 days long?
I didn't try, but I expect them to be 4 days long. We are speaking of in-game days, though, not real-time days.
Would it be possible to set the maximum (or a random duration between a min - max) duration for each of the weather events/types (default, clear, overcast, etc.)?
In principle, it would be possible, but it is not implemented (yet?). I assume this would override the common duration set via "changesPerDay".
I.e.: if the duration of a certain type of weather is set to, say, 0.5 days (fixed) or 0.25-0.75 days (range), that weather type would last the given amount of time (or a random value within the range), regardless of the duration set bu "changesPerDays". If all weather types have each a specific duration, the "changesPerDay" setting would become ineffective.
Thanks for the suggestions. However, I believe that the greatest current obstacle in construction is the way how rotations are obtained. I have described that extensively here and passingly here.
1. Unfrozen Positioning- While being able to freeze a construction element in place is very useful for alignment, I find it equally problematic. Because if I want something to accurately align I have to play a guessing game on where to freeze an item in place to be at the right amount of distance for the positioning xyz value points to line up where I want them to, and as you probably guess it's a very tedious thing. I also think it would help to be able to enable transparency/intersecting placement via command key instead of having the block/plank/pole auto-stacking.
I think I do not understand this point. Unfrozen positioning is already there basically: simply do not freeze it. The frozen positioning is very helpful in aligning and seamless connecting (as far as possible) elements. Which improvement do you envision, exactly?
(My usual work flow is 1) to freeze an element at the nearest block position -- using [G] / [RCtrl] / [G] -- to ensure a consistent 'origin' and then 2) move it by a specific number of steps -- see this post for details on block size, assumed real size and step sizes --; each step is likely to introduce rounding errors, and for this I try to use as few of them as possible and to start from the nearest 'fix', assuming that block positions are internally represented as integers and then suffer no rounding/truncation errors).
2. Coordinate Input: another suggestion is the ability to manually put in the xyz coordinates for your active construction item. Because this is an open world game I'd figure it would need to work by isolating a small area by highlighting blocks to work on (like with Blueprint creation). I don't know if inserting xyz values this could be a Command Control input or done via a unique type box opened up via keybinding. I'm not too confident if this one could work well
I am all for numeric input! However, the coordinate of which point of the plank/beam/log? Its origin? do you know/remember/can work out where the origin (or any other specific point) is in an element which has been rotated?
Currently, in the user interface, each of the X, Y, Z coordinate in RW is expressed as the index (possibly decimal) of block along the corresponding axis. Using decimal numbers for coordinates is likely going to introduce floating point errors again.
So the more precise way I can imagine looking from 'outside' of the code is to use the smallest step as measure unit. There are 400 position steps in a block. This would amount to specify a position as:
<block_index_X>|<step_index_X (0-399)>, <block_index_Y>|<step_index_Y (0-399)>,<block_index_Z>|<step_index_Z (0-399)>.
So, I share your impression that it could possibly not work very well either, particularly for sequences not following one of the coordinate axes (oblique sequences, stairs, spiral staircases, etc.).
3. Item Subtraction/'Hollowing'- Like with the terrain tools, have a setting in creative construction for your selected item to essentially cookie-cut out an area of an existing plank/beam/pole. This further expands possibilities and methods for unique creation; I know I would be absolutely enthralled to be able to just place a wood pole and align a smaller one to hollow it out and make fast and easy pots/cauldrons/pipes/rings (creating those manually are the bane of my existence)
This would definitely be a great addition! However, I do not expect it to happen any soon, or possibly ever. For the little I understand the way RW works, it would require an extensive, deep, structural rewrite of the code: possible, but not probable.
I would be content with more primitive shapes -- half log, quarter log / filled and hollow / ... -- and a greater range of size; this would at least allow to make rings, arcs, etc. much more easily than it is now.
@Miwarre I mean that RW run in real time, so that one day in RW World 24h. I hope you understand me ;D
Yes, I think I do. And this possibility has been there since a long time, via the setting I describe above.
But I have here found a plugin, that to do, what I mean ;D
RealTime (Plugin)
I saw the plug-in; I didn't try it, but I assume it does (possibly more easily) via code exactly the same thing done via the configuration setting.
a small question/comment, why when I try to use "/gps goto X" (where X an integer for the waypoint I want to use) the GUI pops up instead of me being teleported to the waypoint I selected?
As the description in the top of thread post says, /gps is the only command; it displays the GUI and from there everything is done via the GUI.
I find that a bit annoying since I don't want to have to click 100 buttons to get somewhere, typing a single line is much faster.
Typing a single line is surely faster, if you get it right at first; if you misremember the numbers (and get teleported who knows where), or make a typo or whatever, you have to redo it again.
If you frequent several multi-player servers or you have several single-player local worlds, you would have to remember the indices of each WP of each world. Sure, it would be possible to add another command to list the WP. Then one would start to need to remember the syntax and the orthography of each command and so on. I prefer to get out of all this.
As there are 15 WP's + Home and the GUI is circular, a WP is at most 8 clicks away (if one has used all the slots up) + plus one on the "Go to" button. It isn't so long...
Do you intend it to work that way and if yes would you consider changing it so that when I type "/gps" alone the GUI pops up but when I type "/gps goto X" I get teleported without the GUI popping up?
Well, my plan is to stick to the GUI, without duplicating existing functions via additional chat commands.
The whole stuff is waaaaaaaaaay more complex than is may look at first sight, see this comment of mines about feeding only, then there are all the other parts...
Hello all ;D
For very long time I asked red51 after a option for a real time on a server. He say that is not good for the players, because the server becomes higher laag, is that not more so ?
As far as I know, this option is there since quite a long time, at least since I use RW (more or less one year).
Of course, I do not know RW as @red51 does, but I cannot understand how the simulation time / real time ratio can affect the server lag. Are you sure you mean the same thing as the OP?
@Minotorious is right; a few details, for the sake of completeness.
The configuration item is XXX_time_speed and its value is how many real-time seconds an in-game minute lasts. The default is 1.75 (1 in-game minute lasts 1.75 real-time seconds); if you change it to 60, 1 in-game minute will last 60 real-time seconds = 1 real-time minute, and the game will run in real time.
Note this would not affect timed events; for instance trees will always take the same amount of (real time) time to grow or to bear fruits, regardless of this setting. In more detail:
A) Single player:
1) open with a text editor the file config.properties in your Rising World main folder
2) change the line saying game_time_speed=<whatever> into game_time_speed=60
B) Multi player:
1) open with a text editor the file server.properties in the Rising World Dedicated Server main folder
2) change the line saying settings_time_speed=<whatever> into settings_time_speed=60
Hoping this help...
If things are are distributed wisely in time, it may work.
Unfortunately, as far as I can tell, there is no way currently in the API to detect trees. And, surprisingly, they are not even stored in the World DB. How are they put in the world, then? Are they procedurally defined only? Only trees which should NOT be there (trees which have been cut) are stored in the DB? Who knows...
Fact is that at the moment there does not seem to be a way to implement this interesting suggestion!
@Miwarre Having scanned the thread you mentioned I see I may be wrong but either way the system is not good as it stands.
Agreed...
It seems that all that is required is free rotation and scaling of the beam about its centre (probably in discrete steps). It's not hard to do in itself and needn't be subject to rounding errors.
Rotations are harder than it may seem at first sight; rotations are in general not commutative, and this may lead to unexpected (but perfectly reasonable) results, if not understood correctly. Which makes important to make the system as clear and understandable as possible.
Also, rotations have an axis, in addition to a centre and there may be (in fact, usually there are) several choices about which are the 'X', 'Y' and 'Z' axes; at the bare minimum, once chosen an order (left-handed or right-handed, again 
), the 'X' axis may be the World X axis (W - E direction) or the X axis of the object being rotated.
"Free rotation" may be useful in some cases, but for architectural building, having known angles is important. For this reason, I like the current concept of rotation step (and even more, as the step is settable).
Lastly, rounding errors are 'built-in' in any floating point calculation step; they may be minimal and unnoticeable at sight, if steps are few; which is why reaching the desired orientation with as few steps as possible is also important.
I wouldn't think may people would want to rotate an object in two axes simultaneously so why not have a key (or three 'x', 'y' 'z') that sets the axis to rotate around and use the mouse to carry out the rotation (perhaps while holding a key to snap to certain angles). Just a thought!
Rotating is always around one axis; rotation around more than one axis makes no sense; the axis might be a non-coordinated axis (say, an axis midway between the 'X' and the 'Y' axes, where 'midway' may mean several different things), but there can be only one.
Your suggestion may come handy in some situations (I tend to be obsessed by numbers, so a "free-hand" rotation with the mouse would not usually appeal to me, but this is highly personal); it would not significantly change the obviousness -- or non-obviousness -- of the system, if what 'X', 'Y', 'Z' mean remains (apparently) fuzzy and hard to foresee as they are now.
So will you be removing just the sharing aspect of the waypoints or will you remove the entire waypoint feature?
Thanks for the precision. Only the sharing; personal WP's will remain as they are now, with all their features, except sharing. I have added to the OP a further clarification in this sense.
I do like the waypoint feature a lot. I don't mind losing the ability to share them though.
I do like WP's too! Thanks for exressing your position about sharing.
@vinehold: first of all, welcome to RW!
About the specific point (points?). Both you and @Minotorious are right:
1) on one hand, over time one become more and more familiar with the intricacies of the construction system
2) on the other hand, after 1300+ hours on RW, I still have often no idea what to expect from this or that rotation command and, if things are counter-intuitive or far from obvious, this could heavily affect new users experience and adoption of the game, as you rightly observe.
In particular, I am rather sure that at least rotations are 'strangely' implemented (see this longish thread where I exposed my doubts and concerns, but I have been unable to entice a constructive response) and IMHO this is a good part of the "complexity" or "non-obviousness" of the whole.
P.S.: I am also left-handed (but not 100%; being presumably older than you are, in my childhood I have been 'educated' to do many things with my right hand, like writing; and, even more incidentally, I do not think left-handedness is a "handicap", we are simply a disregarded minority); I don't know if this has any relevance; still, we both are left-handed and we both raise concerns about these aspects...
This is about proposing two changes for my GPS plug-in.
____________________
A) Removing the Shared WP's feature.
As I kind of expected, there have been critiques concerning the sharing WP's feature. On one side, there is the definite possibility of an uncontrolled increase of shared WP's, resulting in a huge list difficult to browse and making hard to identify what one would want to import into his own WP's. Someone has requested the sharing feature to be restrictable to admins only.
On the other side, some list management features (like deleting individual shared WP's) are in order.
It has also be noted -- rightly, I believe -- that this feature is a kind of 'poor man' version of the /tp plug-in, with less functionalities and less features and that that plug-in should be used in stead.
The summary, in my perspective, is that more code (with more debugging and maintenance) is potentially needed for a feature which would in any case have limitations and raise concerns, which amounts to a loss/loss situation.
For all these reasons, I am thinking about removing the whole sharing feature (personal WP's in themselves will remain, of course).
____________________
B) Adding a Track Player feature.
This is a feature which I found myself needing occasionally but repeatedly. In practice, it would amount to:
1) Player A would select another player, B, among the currently connected ones
2) Player A would have name, radial and distance to B's current position displayed in the place where data to a WP are displayed, as if B be a (moving) WP.
For efficiency, the display would be only updated when A moves, but not when A stands still (even if B moves in the meantime).
____________________
Comments from any interested user on either or both proposals are welcome!
A new 0.2.0 version of the Plugin Central plug-in is now available.
New:
*) Adapted to the latest release of RWGui (the previous Plugin Central version was not really compatible with it 
).
As a general (unwanted) advice, it is better not to rely on the wiki: it is very old and unmaintained; I believe -- but I can be wrong -- it is non-official (or no longer "official").
The programme is in alpha and, in addition to the rather probable presence of bugs, features can change, which also makes any documentation easily and quickly obsolete. The most reliable source of information are the change logs (here).
One could also suggest that advices from a forum user with almost 3000 posts, years of contributions and discussions (and not an English native speaker, as many of us, me included) may have some relevance and it is probably better try to find the positive aspects of them, before bashing them so harshly.
About the specific point, the last time I used the sleep-point+compass feature (which is months ago), I found it reliable, but honestly I do not remember many details of it.
A new 0.4.1 version of the PnB plug-in is now available.
New:
*) Fixed a bug with the radio buttons to select the type.
*) In creative mode, resources are free only if the permission file for the player has "freecrafting" set to true.
A new 1.3.1 version of the GPS plug-in is now available.
New:
*) Fixed a bug with the list of WP to share when no WP was defined.
