Posts by Miwarre

Thanks for the trick, @Chrisx84! I use to keep pressed both the [Tab] key and the movement key(s).

Feel free to comment on this thread about blueprint management!

F3 shows world coords in the top right corner of the lot of text displayed: look for text saying: "(Global: xxxx yy zzz)", xxx is the West coordinate (longitude; note that it increases westward not eastward), yy is the altidue, zzz is the North coordinate (latitude).

OR:

In multi-player, keeping the [Tab] key pressed shows a panel with all the players and the distance from yourself; move around trying to always decrease this distance and you'll reach your goal...

Don't worry: multi-player is quite enjoyable (someone would call it "relaxed") in RW currently. Mostly, everybody builds his stuff, mistreats admins and pays visit each other to see and learn how to do new stuff, with occasional trading. Non-PvP servers are definitely "relaxed" (still, you die, occasionally!).

(And, yes, I am regularly on @icon58 server ad I find it enjoyable)

If monsters really have to be (I am not a supporter of them, as it is well known), at least I expect them to be monstrous!

OR: I remember an old movie by the Monty Python when the "final boss" monster was a.... rabbit! A regular, cute, hairy rabbit. If fantasy shall be, might it be fantastic...

Quote from george1979k

I mainly and personally desire stuff that I cannot build in the game.

<tautology>You only desire what you cannot do!</tautology>

Quote from george1979k

We can build chairs,tables and all but it wouldn't be bad to have some added.!

Anything we build from scratch becomes, in a sense, part of the terrain: it can be built and it can be destroyed but it cannot be picked up, moved around and so on. This is the big difference I experience with built-in objects like furniture, lights, etc: they are really objects, what we make is fixed as it is.

Just to go on with furniture, as an example, I find the general style of the built-in furniture quite limited and limiting. And note, this is not a criticism: I understand that the game still has to grow, many other aspects -- much more important than a different chair -- are needed and require dev time and resources, it's ok.

However, I expect that whatever new furniture items will be added in the future will likely not fit my specific taste and/or the style of the building I like to build (my taste goes for XVII-XVIII century styles). Furniture is just an example, of course, the same goes for tools, block shapes (I crave for fluted columns or pilasters), terrain textures, etc.

This is why what I specifically desire is not a specific object or a specific style, but the possibility to model externally and include in the programme our specific objects, as objects (currently blueprint-added stuff are not objects, as I said above); in other words, an add-on framework.

Well, it is rather simple: if you look into your config.properties file, you'll see that, for instance, the KEY_UP short-cut is assigned to both input_move_forward (which moves your character forward) and input_up (which, presumably, moves the pieces around): if you press that key, how can the programme guess if you want to move yourself or a piece?

Try assigning to input_down, input_left, input_right and input_up the keys you want to use for moving the pieces around and see what happen.

Currently, it seems impossible. See also this thread.

Sorry for the non-Eglish native speaking perspective: BBQ? British Broadcasting Quorporation?

Quote from ArcticuKitsu

Makes me wonder how people would view having tipi's, and various other sorts of variations of this from around the world to choose from.

https://en.wikipedia.org/wiki/Tipi

Bedouin tents, Mongolian tents, among others. There's many to make note of :).

As I noted elsewhere (perhaps when speaking of ancient Egypt, but I do not really remember), this seems to me another perfect example for a (future!!!) modding/plug-in/add-on framework: no matter how many tent types the dev team may provide, some will not be there. It seems to me a better optimisation of resources if they just provide one (even just the one already existing) and then mods provide variants.

Also thinking that, if you have a, say, Mongolian tent, you probably would also like to have Mongolian harness, Mongolian dresses, decorative patterns, furniture (well... furniture...), weapons and so on. And an add-on pack is already outlined.

Suggestions:

1) Rename: it seems impossible to change the name of a blueprint displayed in-game; renaming the file does not work, as the original name is still shown in-game. Useful to correct mistakes and to re-organise/re-classify blueprints as more of the same kind are added.

2) Alphabetical list: blueprints within a page and pages within the journal seem to be shown in an arbitrary order; having them in alphabetical order (whatever variant of it, as long as it is documented) would be more user friendly.

3) Category combo box: when creating a new blueprint, the name of the category has to be typed each time and a simple typo (who never makes typos?) is enough to create a new, separate category; a combo box listing existing categories to choose from while allowing to type a new category name would speed-up the process and reduce errors.

Questions:

1) Deleting? Is the "Delete" function in the journal the only supported way to delete a blueprint? Deleting the file is not enough, as the deleted file is restored sooner or later (when? is it cached by RW or Steam?)

2) Moving? Which is the supported way, if any, to move blueprints from one category to another? Moving the file is not enough, as the file is restored in the old category too (a variant of the above). The process I use is:
*) Back-up the blueprints
*) From within RW, delete the blueprint(s) one wants to move
*) Shut RW down
*) From the OS, restore the blueprint(s) from the back-up into the new category folder(s)
*) Restart RW
a bit clumsy, isn't it?

Thanks, M.

Ok, I had a look at the config.properties file: among many other things, it includes two groups of keys:

1) input_move_backward, _forward, _left, _right used to move the character

2) input_down, _left, _right, _up used to act on things.

I suppose that, by switching those two groups of assignments, one can switch right-, left-hand operations. Anyone, for whom this is a relevant issue, wants to try if my assumptions are correct?

This is why I said: "at least for blueprints not including any block".

As @red51 pointed out in various occasions, this is a limitations with current block implementation, not with blueprints per se. I assume that, once blocks will be more freely manipulable, as announced, blueprints which include blocks will be more freely manipulable as well.

(default F key, at least in the English version)

If I understand correctly the OP, once the key for "Advance" is changed into [Up] arrow, it conflicts with the [Up] arrow used to size/move/rotate planks; and of course, same for similar keys.

I think that providing at least the text of the error message would help diagnosing the issue.

Possibly the server needs to be restarted? Possibly not the right .permissions file? Which one did you modify?

Free-form musing here, nothing actually meaningful expressed or implied!

As the list of the forum users is sorted by number of posts, while browsing it (just for fun, some spare time...) I noticed that at page 43 occurs the last member who posted anything and then 55 pages follow listing members who registered to the forum but never posted anything.

55 pages out of 98 is more than half and this seems to imply that more than half of the forum users (i.e. more than ca. 1500 out of 2913) took the trouble to register themselves without having anything to post. As the fora are fully readable without any need to register, I wonder why this happens so often.

Blueprint placement is indeed rather user-hostile currently. In fact a much more usable method is already in place for plank/beam placement. (aka New Construction System) and would make sense to apply it to blueprints too.

Most of @ArcaneDesmond suggestions are already implemented in it:

*) [RCtrl] to turn fixed mode on/off (currently blueprint fixed mode, once turned on, cannot be turned off)
*) Movement in 3D with [Arrows] (with configurable steps via setr/l/p)

Rotations are not implemented in plank/beam fixed mode placement (incidentally, why?) but, as resizing might not apply to blueprints, [Shift]+[Arrows] could be used for rotations in blueprint placements.

OR, even better: movement, sizing and rotations could (assumed to) be implemented in all modes -- free mode, grid mode, fixed mode -- for both plank/beams and blueprints and a consistent set of short-cuts could be used for all of them (I still believe that right now default short-cuts are not very consistent, see this post of mines about why this is important).

The various modes for the various types of elements may be implemented over time, but the short-cuts could be planned to be consistent right now.

EDIT - ADDENDUM:

In fact, most of what I describe above is already implemented in blueprint placement, at least for blueprints not including any block. The possibility to turn off fixed mode and a more consistent set of keyboard short-cuts would still be useful, though.

When working on small details, also setl and setp can be very useful.