Posts by Miwarre

Quote from Deirdre

Who will rewrite the already known Lua scripts in Java?
Already existing scripts in Lua.

Areaprotection = ´Red51 and team

world edit = ? maybe Lord Fobar, yahgiggle and ...?

setting plants = ? maybe yahgiggle?

compass, ie. change to coordinates (2 existing versions) = maybe yahgiggle, or red51 with his coordinate script?

teleport script = ?

home point = ?

Afaik the others are not updated by their creators.
It would be really good to know because this are indeed the most important scripts.

Display More

Of course, I cannot say for the other, but my published plug-ins (GPS including compass, position, waypoints and home, and TELevator, implementing elevators via teleporting) will be surely ported to the new Java framework, as soon as it will be working on servers.

Probably they will also be updated and enriched in some way, taking advantage of the new possibilities (for instance, if possible at all, I'll try to do without teleporting for the TELevator plug-in, using a 'real' moving platform and a 'real' elevator button panel).

I took some time to think again on this point. I was probably a bit too excited about the novelty! Thinking again, practically all the cases I can think of where this 'trick' would be useful can be dealt with in way or another via 'regular' API calls (existent or 'coming soon').

There are possibly (probably?) cases not coming to my mind right now, but we will cross that bridge when we arrive at it.

It seemed a clever -- albeit hacky -- way to speed up plug-in development but, after the discussion and the suggestion posted by @red51 in other threads, it looks possibly not so urgent.

Sorry for the noise! M.

Quote from red51

Every chunk that has been modified will be generated, so even if no player is nearby, the world.getChunk(x, y, z) method will return a chunk object (or null if no chunk was generated).

Ok, my sentence was too cryptic, meaning: only chunks which -- at some moment -- are been visited by at least one player are generated. Actually, your observation seems to imply that only chunks which have been modified by a player are generated. In either case, there are chunks which would fall in the range of a mapping tool and which are not generated (at least not yet, at the moment the mapping tool needs them), particularly if the mapping tool extends in the depth direction too.

Quote

Basically the server is able to generate a chunk at any position (independent of the players), we just need a convenient way to do that.We can either:

• change the world.getChunk(x, y, z); method, so it always returns a chunk, even if it's necessary to create a new chunk
• add a new world.createChunk(x, y, z); method which creates a new chunk and returns the newly created chunk

I assumed the world.getChunk(x, y, z); method already works in the way you describe (option 1.).

If this is not set in stone yet, I would speculate that option 2. would allow some better optimisation (if the plug-in is well-thought and the author cares, of course), as it would allow the plug-in algorithm to decide if the chunk is really needed or not (either according to some heuristics or to the plug-in settings) and spare the generation of not indispensable chunks (even at the expense of some duplicate call: getChunk() first and then createChunk() if necessary).

This assuming that chunk generation is a rather expensive procedure.

Quote from zfoxfire

a cave would be anywhere your position is below the known surface level of that postion and chunk

Which seems to me another way of expressing the same definition I was proposing above...

Quote from red51

Hmm... what do you mean exactly? Of course the inside of a cave is filled with air, but everything else (below the surface and behind cave walls) is solid rock

I think @zfoxfire is concerned by the 'airy' appearance of the space between the surface and the cave boundary when you fly in it. But all those in-between block are actually solid, aren't they?

Quote from red51

Something similar was actually planned, it will be added soon

Great! Looking forward for the next instalment!

Quote from red51

A "PlayerInteractEvent" will be introduced at least for the custom models. Not sure about regular objects, right now opening up the crafting menu at a workbench is handled clientside. It would be possible to trigger such an event, but it would not be possible to cancel the event (i.e. prevent the player from accessing the workbench) But if it is really required we could change this behaviour.

Which raises another question: when in the work-flow event handlers are called? Even assuming somewhere along the flow there is difference between events started server-side (e.g., an NPC spawn) and events started client-side (e.g.: opening a door), are the handler called before the action is carried out, after it or independently (i.e. asynchronously / in different threads)?

Currently, the client checks with the server after [F] is pressed on a door and before actually opening it (otherwise, it would not be possible to block door opening); OTOH, the handlers for the quick slot change event are called much after the change happened (one or two seconds after the change with client and server running on the same machine!).

I understand the delays that always checking with the server would introduce, but this already happens in several cases, even for events more frequent than opening a workbench, like entering a chunk. One could believe that the behaviour should be made uniform as much as possible and the cases where this is impossible (or would be highly counter-productive) listed explicitly in the docs.

Anyway, I think the major reason for handling in a script an interaction-with-object event is to prevent it from being carried out; if it is not possible to block it, having the handler looses much of its importance.

Quote from ArcaneDesmond

In the game Minecraft there's a mod to tweak biomes it's called Biomes O' Plenty. There's a tree called a Sakura and I would like to add it to Rising World ...

"Sakura" is just Japanese for "cherry" and there is already a cherry tree in RW...

I know the rule says "one post, one topic" but these two points are rather tightly related.

1) a PlayerInteractsEvent to be fired when the player interacts with some object ([F] key). I could not find it even in the LUA API. Among other things, it could be useful for controlling access to objects like workbenches, furnaces, etc. in protected areas (it may subsume the current LUA event "PlayerObjectStatusChange").

2) a World3DModel::SetInteracts(boolean) method to activate the possibility to interact with a custom 3D model. Interaction should not do anything specific on the model itself, 'simply' show the hammer cursor and trigger the above event on [F] pressed. Plug-ins could process the event to implement specific functionalities.

Quote from zfoxfire

Indeed that would be a hack which is why I highly doubt if we will be given the power to pass a console command through an api as an actual string. That could create a vulnerability if someone was to find a way to exploit the console itself. Rather, each command function will need to be available in the API with its own method.

Indeed! Having all commands available as proper plug-in methods would be the target to aim at. But, if this is going to take some time, a temporary solution could be useful.

If console commands were discovered to have a security hole, this would be a problem with the console in the first place, as anyone has access to it, while only server owners can install plug-ins.

Quote from red51

Well, this depends on your modeling program. It's probably not possible to have a 1:1 scale[...]

Having models scalable is fine, dynamically scalable in real time is great!

Still, many objects have an inherent size: a Citroën C3 has a definite length/width/height, a table is usually 90-110 cm high, a violin is 56-58 cm long... It would be easier if the model could be designed with a ratio between modelling units and RW world units known in advance, rather than relying in a case-by-case trial and error process.

Also because it has to be expected that model designers and model users (be the latter plug-in authors or final users) to be different persons, possibly even different teams, and some kind of 'standard' for RW 3D model interoperability would be rather important.

Does your observation about modelling programme implies that the ratio will be different for different model file formats? Still, it should be known (or know-able) for each file format...

Quote from red51

Here is the question: What is a cave? Or how do you find out that there is a cave? What's the difference between a cave or a hole in the ground, or a ravine for example?

This is the question indeed! :evil:

It is going to be subjective. At the very minimum, I would qualify as a cave anything which has air block(s) below solid blocks. At least this matches the usual meaning of the Italian equivalent of cave. In this case it is not relevant if it has an opening toward the 'outside' or not.

If you want to stick to a more strict definition, which requires no openings, then some 'winding' algorithm is probably needed to detect the closure, which, in 3D is not simple. Definitely not something to do in real time while the player is wandering around the world, though!

Also, the chunks need to be generated before they can be analysed and I suspect only the visible/nearby chunks are normally generated, not subterranean chunks (until someone digs or flies to them). This is going to require additional server/db work to generate the data for analysis. So, mapping might turn out to be a heavy task... (as in real world, anyway).

A Proposal which hopefully should not require extensive changes and should mostly leverage existing code.

A way to issue a console command from a script; it could be a method of the Plugin class (or whatever you think appropriate) taking a string with the console command to execute (and possibly a Player object, as some console commands apply to the issuing player) and forwarding the command string to the console interpreter.

The goal is to support commands which are not possible (yet?) via the regular framework and, more in general, commands which could be automated to simplify the life of server owners/admins.

The implementation may be rather bare bones: just a boolean as return value (did/didn't get through), no error report, no particular validation, etc...; it may be already qualified as temporary and not supported in the future, etc...

It is a kind of a hack, I know, but it could save the day in some cases...

Thanks for the reply! I imagined I was overlooking some detail, a lot of docs to wade through (which is fine, VERY FINE!).

Quote from red51

The ModelInformation object is basically just the reference to the 3D model. The class to create a model in the world is the World3DModel (just like 3D texts etc), you can assign the ModelInformation to it by calling the setModel(ModelInformation) method.[...]

Damn! I didn't scroll down to 'W'!

Quote from red51

That could be added. Maybe create a new topic about that in the plugin section, so this suggestion does not get lost

I'll do it; I didn't want to pollute the forum with duplicate posts.

Quote from red51

If it's explicitly about changing the playergroup, that can be done this way:

Java

Player player = Plugin.getServer().getPlayer("Miwarre");
player.setPermissionGroup("moderator");

Another detail I overlooked! Thanks!

Quote from Deirdre

Das Problem ist wohl, wer schreibt die Scripts.

One could assume that the original author of a script will take care of porting the script to the new framework. If the originla author is no longer around and there are no license issues, 'important' scripts will surely find a pious soul porting them.

FAAAAR from sure, but the Chunk:terrainData[] array could have the info you are after, assuming air has a different 'block ID' from anything else, it should be possible to locate air blocks at whatever position.

[Post removed and reposted to the Plugin Feature requests section]

Just had a look at the docs. Looks VERY promising with a lot of useful additions. THANKS!

Assuming the events present in the old LUA framework and currently absent in this preliminary version will be added (for instance, placing/removing/destroying of anything other than blocks), the only area remaining somehow grey is custom 3D models.

There are functions to load a 3D model from disk, which return a ModelInformation object, but no obvious way to place the model itself in the world: did I overlook something?

Question: if I am not mistaken, it seems the current concept of a script-relative database no longer exists. Does this means that all script-dependent data will reside in the world database? There are possibly reasons for this (efficiency? connection pooling?) but some care should be taken to avoid table name clashing: many scripts use a table equally named, for instance, "players"?

Steam reviewers seem to have a different idea, though, as the programme oscillates between "Mixed" and "Mostly negative".

The procedurally generated planets might be fine, I cannot tell without trying myself (and I'm not going to spend 60 € on a game with so bad reviews), but the fly scenes in the videos on Steam are ridiculous: going from ground level to out of the atmosphere in less than 3 seconds implies such an acceleration that anybody in the aircraft would be dead on the spot. Also the way they manoeuvre around planets seems to imply a total lack of gravity. This is not even sci-fi, it is simply techno-fantasy...

Quote from ArcticuKitsu

Well, maybe I'm bringing in something foreign, yet Rising Word is a game already breaking boundaries that I'm wondering if there'll even be neutral happy-evil type music. Nothing happy, nothing angry, or dark....Just somewhat neutrally moody, if that makes sense.

Like Bach's Kunst der Fugue or Die Musikalisches Opfer, for instance. Or Palestrina's Masses. Or a good deal of XV - XVI c. polyphony. Or...

Quote from yahgiggle

For the size i would guess 1:1 but red would have to confirm that as i said im just guessing lol

1:1 may mean several things: 1 design unit = 1 block, 1 design unit = 1 setl default unit, 1 design unit = 1 setl veryhigh unit, etc...

Quote from yahgiggle

for the grace period i have been told by red that there will be at lest some months that both frameworks will work, this giving us all time to replace our lua scripts

Great; this sounds very reassuring!

Two easy (hopefully!) questions for @red51:

1) Which will be the the default scaling factor for custom 3D objects? In other words, a size of 1 object unit, scaled at 1:1, will correspond to which RW world size?

2) There will be some "grace period" for the replacement of LUA scripts with Java scripts? Either a period of coexistence of both frameworks or a period of during which programmers have enough documentation to convert existing scripts before they stop working?

Thanks, M.

Quote from diegomarino80gongo

nice, what is the content of update so?

Hi Diego, have a look here.