Posts by Miwarre

Yes, there is: blueprints which contain blocks cannot be rotated, only translated in block-sized steps, as blocks themselves cannot be rotated. If a blueprint does not contain any block, then it can be rotated.

Thanks for the update. In addition to VorNet itself, I find particularly interesting the possibility of intra-server communication and sync, for money to start with, but in future for other quantities/qualities/stats/... as well.

All my best wishes for this endeavour of yours!

Quote from yahgiggle

i like that you took our script or parts of it and changed it for your needs as long as users don't just copy and stick there names on it we are happy as

Thanks, @yahgiggle. I usually try to comply with license models and, at least, I try to acknowledge all the debts I know of. But occasionally I may oversight some important details or meet someone who is particularly picky. And, really, if you prefer I add more details about the original source -- for instance a persistent URL where to obtain your script from -- or anything else, simply tell me.

Quote from Chrisx84

duuuuuuuuuuuude better idea then what i was doing for vorvator. i happily concede the race to make a elevator script

It was not a race (hmmm... well... maybe a little bit, but only a little bit ). And anyway we still have to see if it works only 'in the lab' or also 'in the field'!

I also thought of 'recycling' the [1] to [5] keys to select the destination floor, much like the 'real' buttons of an elevator at least for the first 5 floors, hooking into the PlayerQuickslotChange event (in the source there is some code commented out).

But there seem to be problems with that event and I could not understand if it is me or an issue with the API framework. If anybody want to waste time in this...

"set r/l/p" condenses in one string three different commands: setr, setl, setp. They control how precise or coarse will be the effect of the placing commands (rotation, size, position) used by the New Construction System, the one used for instance to place wood planks.

setr stands for "set (precision of) rotation" and controls how precisely a piece will rotate for each rotation command, while placing for instance a plank or a beam. It has 4 settings "low" (45°) "default" (15°), "high" (5°), "veryhigh" (1°).

It is used by opening the console (NOT the chat, the console!) and typing for instance setr high and pressing Enter.

setl stands for "set (precision of) length" and controls how much a piece will become bigger or smaller for each sizing command. For the rest it is very similar to setr.

setp stands for "set (precision of) position" and controls how much a piece will move for each moving command. For the rest it is very similar to setr.

Does this help you somehow?

*) It adds the concept of a group (= elevator) of teleporting points (= levels) and groups are mutually exclusive.

*) Of course, it adds the management of these groups (creation, deletion, list).

*) Tele points are both sources to all other points and destinations from all other points within the same elevator at player's choice and command and not automatically point-to-point.

*) It adapts the UI to these concepts.

These are points I can think of on the spot. Sure, the point of departure has been the Portals script, which I acknowledged both in the source and in the post above. If your license model requires more conditions to fulfil, please describe them and I'll try to comply.

How can we help you, specifically?

You may check if the TELevator script I just posted suits your needs. Please be careful, as the script is still in beta and may have bugs; but the worse which may happen is to be teleported to hell... :evil: ...and who cares...

You may see if the TELevator script I just posted suits your needs. As the script is still in beta, I welcome suggestions.

Quote from Chrisx84

2) would be great but doors are about the size of our characters, 4 blocks high by 2 blocks wide.

Which is a bit small. Assuming the semi-official scale of 50cm for a block, it makes 2m tall and 1m wide. At least here we are accustomed to slightly taller and definitely wider doors.

And main entrance doors of buildings can be significantly bigger.

Another attempt at a script; it is still a very BETA version and bugs may lurk after any corner; however I hope it will be useful: tests, suggestions, comments and criticisms are welcome. Several parts of the code have been adapted from the Portals script by @yahgiggle and RichieS for the Rising Cities server.

Version 0.1 - Features

*) Implements the concept of elevator, which just a name and an id to which levels will belong.

*) Implements the concept of level, which is a physical cube in the world: it has a size and a position, belongs to an elevator and has a specific order within that elevator. The player has to be in one of this cubes for the elevator to work. From this level he can be teleported to any other level of the elevator with the command /floor n (where n is the destination level), but not to a level of another elevator, of course!

*) In addition to creating and deleting elevators and levels, it is possible to visually show and hide them and to have a list.

Commands

*) All the /elev ... commands can be reserved to admins only by setting adminsOnly=true in the file config.properties or left open to all players with adminsOnly=false.

*) Elevator IDs are generated automatically and are not necessarily supposed to be in sequence. The /elev list command also lists the elevator IDs.

*) Level numbers also do not need to be in sequence, but it is usually clearer to do so. Level do not even need to be one above the other in a column like in reality; if you like to be creative, the levels of an elevator can be in any position!

*) Level numbers start from 1. I apologise to the cultures which number the ground floor differently (including my own), but sticking to numbers make things much easier.

Installation

Extract the files in the ZIP placing the whole TELevator folder into the scripts folder of RW.
Edit the config.properties file, if you want to leave all the commands available to all players, rather than to admins only (the default).

Open points and known issues

*) The script has only been alpha-tested! There might be bugs of any kind! Please test it, if you are interested, and report issues in a way which allows me to reproduce them and be patient. Thank you!

*) The message displayed when starting the area selection for a new elevator level says: Select the area, stand on the platform and use "/elev createlevel" to save it. This refers to an older version of the script. Use the /elev newlevel command instead!.

*) The script uses a database relative to the script itself not to the world; this makes it less suited to single-player multi-world contexts, as the names, positions and numbers of elevators and levels will be common to all worlds. However, I am reluctant to pollute the world database with extraneous data.

*) When the player first appears in the world, it may takes a few seconds and/or the player has to move at least a little bit before the script recognises the player position. This depends on how data are filled by RW and there is little I can do about

Enjoy! M.

Damn! Chris beat me! I already have a TELevator script in the factory but, being right now ill-ish because of a flu, I cannot work on it at full speed.

Quote from zfoxfire

Miwarre brings up the point about having to start over with building. The issue is that at present, player info is build into the world. So if you want to server hop or start a new local game, you have to start over but at present, you start over with the a few iron tools so its pretty easy to get set up quickly. When character customization comes out then it might be smart to separate the player from the world. It is going to become especially important to do that if we get a skill system and have to unlock recipes or start out with only stones and sticks to build with.

For now it doesn't matter much because the player is nothing more than a storage container and we already start with good tools from the get go but I can see it becoming a problem later on.

Hear, hear! I totally agree and in fact I raised the opportunity of some kind of character persistence across world sometime ago. Sure, right now it doesn't matter so much, but it will once several of the features hinted at here and there will be implemented.

Addendum:

if a setup like the following is enough for your goals, I think it can be implemented:

*) N floors with a solid platform on each (in a column if you want to simulate a real elevator, but it is not required)
*) once the player is on a platform, a chat command like "/floor 1" teleport to the corresponding floor platform

Far from sure, but I suspect there might be ways to create spots you can interact with (with the [F] key) and acting like elevator buttons.

A similar request has been posted here in the same time frame.

Yes, with multiple floors, you would need multiple portals; in fact with n floors you would need n-1 portals on each floor to reach any other floor; I understand it is not what you are asking for nor the best solution; it may be temporary trick, though.

I understand you have all the fora to browse and this takes time; several of your last points have already been raised (electricity and photovoltaic panels among other), in particular, the "civilisation evolution" or "progress" concept has been discussed at length (perhaps at too much length!).

This concept has many supporters and it has for sure its positive aspects, but I have already discussed elsewhere why I believe it would be difficult to implement in a sensible manner (in all the other games with a similar concept, it ultimately fall into the category I call of "magic in disguise") and why it would also have drawbacks. In a very short summary:

1) One of the greater forces behind civilisation 'progress' is not technology advance or scientific discoveries -- which still have their places --, but population growth. It is mostly the population growth which allows for diversified jobs and skills and for the increase of quality and quantity levels of object production. And this is very difficult to simulate in a sensible way in a single-player or limited-multi-player context (i.e. without recurring to magic in disguise).

2) RW is centred on a multi-world paradigm: you create a world and play with it; then you create another to try something different and so on And/or you join a server and then another, because a friend plays there or for whatever reason and so on. How many times are you ready to repeat always the same civilisation steps from Stone Age to Post-Modernity before it would become utterly boring?

That said, YEAH! I really love this game too and I am very grateful to the developers!

As far as I know (which might be not very far!), there is no way to translate a world element (or a group of world elements) in order to simulate the raising/sinking elevator as a visible object.

If a gradual teleport (opposed to instantaneous teleports, currently implemented) raising/sinking the player from one floor to another in the void, I think it can be implemented, except for one detail: suppose to raise a player from ground to floor 1; while the teleport is running, it would sustain the player in the void, but as soon as it reaches the target floor and stops, how to avoid the player would fall back to ground level?

Cannot be simulated with the existing Portals script? Not exactly what you are asking for but, in the meantime, it already exists.

UPDATE: A version of this script as Java plug-in using the new plug-in API is available here. I suggest to use it instead of this older version.
___________

This is my first attempt at a script of some complexity. I hope it will be useful: tests, suggestions, comments and criticisms are welcome.

Version 0.1 - Features

*) Displays current player heading as a standard navigation route and position in 'standard' geographic coordinates (N E) and block altitude:

Note that internal RW positive W longitude is converted into a more common positive E longitude.

*) Define a Home position and display radial, side (to the left or to the right of the player) and distance to it:

*) Define up to 9 waypoints and display radial, side and distance to any of them in turn:

*) Teleport to home and to any defined waypoint. Teleporting to waypoints can be disabled for servers which do not like players popping up everywhere. In fact, it is disabled by default; edit allowTpToWaypoints = false at the begining of gps.lua into allowTpToWaypoints = true to enable.

*) The scripts comes with English UI. However, UI tetxts are all grouped in a single file (messages.lua) to make translations easier.

Commands

Installation

Extract the files in the ZIP placing the whole GPS folder into the scripts folder of RW.

Open points and known issues

*) The script uses a database relative to the script itself not to the world; this makes it less suited to single-player multi-world contexts, as the positions of home and waypoints will be common to all worlds. However, I am reluctant to pollute the world database with extraneous data.

*) When the player first appears in the world, his/her heading is displayed as 000°; the value changes to the correct radial as soon as the player moves. This depends on how data are filled by RW and there is little I can do about

*) If the player changes of heading without actually moving, particularly while flying, RW does not always notify the script which cannot update the displayed heading. The heading is updated as soon as the player moves.

Enjoy! M.

EDIT: the originally attached ZIP file contained an already filled database. Users which downloaded it are advised to re-download and re-install it. The old ZIP can be identified because it has no version numbers at the end of the name. Thanks.

Quote from zfoxfire

Pehaps when animal AI is reworked, we will find them in herds too.

Thinking of it, most of animals I have direct experience of -- humans included -- go in herds, flocks, gaggles, schools, or whatever. Almost only apical predators go in small family groups

Quote from zfoxfire

I hope to see scarcity of animals and fruits and veggies

Indeed, right now they occur too often. I think that less frequent animals make more sense once there is the possibility to domesticate and breed them, or there is the risk to spend too much time in hunting at the expenses of other tasks. It is true that collecting & hunting populations spend a lot of time in these tasks, but
1) in these populations, however small, still there are more persons than in a single player game or in the average RW server, allowing for some 'multitasking';
2) at least here in the Mediterranean area, we overcome this collect/hunt stage several thousands of years ago; I hope RW will not be stuck into a pre-historic simulation.

I still have to find a domestication process which makes sense without being too frustrating; I hope the dev team will come with some great idea for this.

Quote from moonsand7

Miwarre and fox, who insist that this game should remain relaxed.

Well, call it "relaxed" if this seems appropriate to you, but -- as far as I see it -- it is not a matter of relaxation, rather a matter of making/having sense, of things which do not look openly random and added just 'for fun' or 'because other games do them'.

Threats add to the involvement and escaping/reducing/managing them makes for added goals and motivations. They are fine, if they make sense and, at least to my perspective, random monsters do not. Threats which add depth to the planning, which affect mid-to-long term decisions and so on.

Then, yes, I am not a fan of games which rely on reflexes and aim, possibly because I am not great in either! Then, as many have already said, everyone is entitled of his own preferences and tastes. If a measure of configurability and modding will be possible (without splitting too much the community, as @moonsand7 rightly pointed out), perhaps more than one single perspective can be accommodated.