Posts by Miwarre

Good job @notabadminer! May I raise a few details?

1) Is there a reason for using the world database as database? I understand this simplify some things, but I would refrain from 'polluting' the world database as, for instance, if something goes wrong there is a risk of corrupting the whole world and who knows if in the future the dev team adds a new table with the same name of one of yours table?

2) I have not tried the plug-in yet, just browsed the code. Are you sure i18n works by simply dropping a language file in the plug-in directory? The code reads the language file from the resources and this requires the language file to be in the .jar.

3) If am not mistaken, the code reads each localised string from the resources each time it is needed. This seems a waste of storage and CPU usage. As currently there are only about 20 strings (and there might be a few more in the future but not hundreds and hundreds) and RW only supports two languages, I would pre-load all the strings at plug-in start in an array / container and then access the needed one from memory.

3b) Same for built-in default strings, which are all loaded each time one is needed: these are a rather obvious candidate for pre-loading.

4) I am not sure that localising commands is a good thing, as this may require that players learn new commands for the same things when switching from one server to another.

5) Also about commands, commands with very generic names like "/buy" and "/sell" are likely to clash with other plug-ins implementing some kind of buying and selling. My approach is to use a plug-in specific prefix for all commands, as for instance "/econ buy ...", "/econ sell ..."

@Galveston01 great job! You beat me: I was working on a Java port of my LUA TELevator script, but I got stuck in a number of details.

May I suggest you not to take for granted that the distance between the floors of an elevator is constant and, rather, allow to set the position of each floor (perhaps, all 3 coordinates of each floor, just in case...)?

Last night, Steam updated my local copy of the dedicated server, but I saw no announcement of it.

It was my local copy which, for whatever reason, didn't got updated at the time of the last 'official' update or there has really been a server update recently?

In latter case, any hint about what has been changed?

I am not sure if this is because of RW or because I hit some obscure (for me!) Java conundrum. I am facing some Class Not Found exception I cannot explain. It arose in a rather convoluted scenario; this is the simplest case I can arrive at still exhibiting the issue.

Context: 2 plug-ins:
- a Back-End plug-in defining a class (ClassA) to be used by other plug-ins: it is made of two source files: the main plug-in file and the additional ClassA source file
- a Front-End plug-in using ClassA

All tests have been done with a local dedicated server running on the same machine as the client (the client connects via local IP). I have made sure that the Front-End plug-in is loaded before than the Back-End, in case this matters, to be sure to have the most adverse condition (the consumer plug-in is loaded before the provider plug-in is available).

Back-End Plug-in main file (TestBackend.java; minimum possible code!):

package com.vistamaresoft.testbackend;
import net.risingworld.api.Plugin;
public class TestBackend extends Plugin
{
	@Override
	public void onEnable()
	{
	}
	@Override
	public void onDisable()
	{
	}
}

Back-End additional class file (ClassA.java): simply inherits from GuiPanel, adds a field and a simple get/set method pair:

package com.vistamaresoft.testbackend;
import net.risingworld.api.gui.GuiPanel;


public class ClassA extends GuiPanel
{
	private int	value;


	public ClassA()
	{
	}


	public int  getValue()             { return value;     }
	public void setValue(int newValue) { value = newValue; }
}

Front-End Plug-in source file (TestFrontend.java):

package com.vistamaresoft.testfrontend;
import com.vistamaresoft.testbackend.ClassA;
import net.risingworld.api.Plugin;
import net.risingworld.api.events.EventMethod;
import net.risingworld.api.events.Listener;
import net.risingworld.api.events.player.PlayerCommandEvent;
//import net.risingworld.api.gui.GuiPanel;


public class TestFrontend extends Plugin implements Listener
{
	@Override
	public void onEnable()
	{
		registerEventListener(this);
	}
	@Override
	public void onDisable()
	{
		unregisterEventListener(this);
	}
	@EventMethod
	public void onCommand(PlayerCommandEvent event)
	{
		String[] cmd = event.getCommand().split(" ");
		if (cmd[0].equals("/test") )
		{
			ClassA	classA	= new ClassA();
			classA.getValue();
			classA.setValue(1);
//			GuiPanel panel	= new GuiPanel();
//			panel.addChild(classA);
		}
	}
}

(note: commenting out the two last statements is intentional: see below)

With this sources, both plug-ins are loaded correctly and the onCommand method is executed correctly. This means that the definition of com.vistamaresoft.testbackend.ClassA is found and its methods located. So far, so good.

As soon as the two last statements are uncommented (with the respective import at the top), RW terminates at start-up with the error:
java.lang.ClassNotFoundException: com.vistamaresoft.testbackend.ClassA (well before line 31 is executed). The simple presence of a classA parameter in line 31 is enough for something failing in the class loading mechanism.

I tried several cases and the failure always happens when a plug-in contains a statement where an instance of a class defined in another plug-in (another package) is passed as a parameter to a method call. The called method can be a plug-in method or most API methods, there seems to be no difference.

Some API methods seem not affected, for instance event.getPlayer().setAttribute("test", classA); in the above code does not create problems.

Can anyone explain what is happening?

Thanks!

@Deirdre, me too, I understand your frustration and I think everybody agrees that current RW terrains are a compromise between different goals. But still, there is always another perspective, and the 'oddities' of the terrain might be an opportunity, not in the sense of a challenge (pain and fatigue are not my concept of "fun"!), but something which can be used and taken advantage of.

This is a project I am bringing forward (yes, with pauses!) since some time. The original terrain was at the border of a lake:

When I saw this spot, I immediately liked it a LOT! It is hilly, completely uneven, but there is a huge potential. This is the same spot 'after':

and a couple of shots from the garden:

I am lucky that I live in a hilly / mountainous area (in Italy near Genoa), I am accustomed to uneven terrains and I have in the eyes the many ingenuous solutions inhabitants have found to exploit them.

But generally, coming to terms with the terrain is an opportunity, deciding when to change it and when to adapt to it, accommodating the projects to it is something architecture has done since ever, And, in fact, I found landscaping in RW as much 'fun' as building, sometime even more fun!

Then, if you feel you need a pause, ok, you have contributed so much to the community that everybody cannot but be grateful! Probably, you will resume RW'ing with fresh forces and renewed eyes!

Oh, I see, thanks. I'll do without, then.

Thanks for the reply.

Quote from red51

If you try to add a custom GuiElement to the player screen (or what's the reason behind sub-classing the GuiElement class?), the client doesn't know how to display it. Currently every API GuiElement is covered by a "real" element in our underlying gui, so if you create a custom GuiElement in your plugin, the client doesn't know what to do

Yes, it makes sense.

Quote from red51

Instead of adding it to the player gui directly (by calling Player.addGuiElement()), you might add a method to your gui class instead (something like "addToPlayerGui(Player)" for example) which adds the particular gui elements manually.

This is more or less the way I have taken: I sub-class GuiPanel (the nearest type among the ones existing) to add specific child elements with specific relationships among them. A show(player) method adds the GuiPanel directly via Player.addGuiElement() and, in addition, a loop adds each child, again via Player.addGuiElement().

So far, it worked...

Quote from randymarsh

The only wall block missing to finish the top of the roof:

If you make the front (and and the back) wall wide an even number of blocks, you can use two sloped half-blocks side by side to make the tip of the walls.

GuiElement.setClickable() and GuiElement.isClickable() are not public (most other GuiElement methods are public). I assume there is a reason for this, but I cannot figure it out (also considering that all GuiElement sub-classes expose these methods) and this makes rather complex to set a generic GuiElement as clickable (or not).

Can somebody of the dev team elaborate a little on this point? Thanks!

It would be useful to have ways to enumerate all the children of a GuiElement in order of addition.

Whether this happens by giving access to the ArrayList containing the children (might be dangerous), through an iterator or through a method like GuiElement.getChild(int childIndex) is not very important, as long as a GuiElement can be sure to enumerate all its children in a known order (addition order is the most obvious).

For a use case, see the example in this thread.

Thanks.

As far as I can tell, GuiElement cannot be sub-classed from another package, as no constructor is public. I am curious to know which is the rationale behind this decision.

My use case for sub-classing GuiElement directly rather than one of its net.risingworld.api.gui sub-classes: I am trying to implementing some form of dialogue box (kind of...) which 'auto-layout' itself (to some extent) and I need a GuiElement sub-class with no visible output but able to position its children. I can build on GuiPanel, but I thought to avoid the overhead of an intermediate class whose capabilities I do not need.

Thanks!

Quote from ArcticuKitsu

We're simply creating & upgrading technology at an alarming rate that it's difficult to keep up.

Well, TRIM is there since at least 8 years: Windows started supporting it only recently, Linux started in 2008 but never got it right. On another side, OpenType is there since, how long? twenty years? And the applications really supporting it are very, very few.

Probably, technology is not advancing at an alarming rate at all (in fact, there is no real breakthrough since, mmm, decades?); probably, there is so much of it, on so many disparaged fronts and with so many tiny details than we cannot cope with it (and it is hard to be motivated to cope with it).

Quote from Deirdre

[...] we use the other coordinate script with x, y, z axes. My wish was something like that in a plugin, because of removing Lua-scripts soon.

So, if I understand correctly, you prefer that, instead of (219N, 274E) h100, it says: -274x, 100y, 219z. Correct? Separated with commas and with axis suffixes?

Do you prefer a separate plug-in or would it be ok adding an option to the GPS to display the coordinates in this other format rather than in "standard" coordinates? (the option would be server-wide, for all the players of the server)

1) I am finding it would be very useful to have a way to get the vertical and, above all, horizontal size of a GuiLabel (as also stated somewhere in the documentation, GuiElement.getWidth/Height() do not work with GuiLabels and always returns 0).

Is there any plan to implement those methods for GuiLabels too?

2) It would also be very useful to be able to retrieve the sizes both as relative and as absolute, regardless of the way they have been defined;
OR at lest
to be able to retrieve their absolute values even if defined in relative terms (ultimately, any GuiElement takes an absolute amount of pixel on screen; the opposite, retrieving the relative value of a size defined as absolute seems less frequent).

My use case is adapting the size of a container GuiElement (say, a GuiPanel) to the size of the contained elements.

@Deirdre: Thanks for the reply, but I am still unable to understand what you are asking for or complaining abut; more, I cannot understand IF you are asking or complaining.

I am glad you find my plug-in "very nice", thanks! Still there seems to be something missing or not entirely satisfactory with it; as I made it to be useful, I would like to understand how I could make it better and more suited the needs of the players.

Sorry to 'pollute' this German thread with my English reply; I hope it will not be too impolite, but with the community split between two languages, occasionally there are interesting discussions in one half which remain unknown to the other half.

Creative vs Survival:

Quote from Bogus

Ist auch ein Grund warum ich zur Zeit nicht soviel RW spiele. Ich mag nicht so gerne im Creativen Modus spielen, aber für den Survival Spieler hat RW noch nicht viel zu bieten,

I think everybody (the dev team included) will agree that the survival aspects of RW are yet under-developed and so far the focus has been on creation / construction. This may change in the future, as the game still has a long way to go.

I suspect however that the two perspectives (creative and survival) are very hard (almost impossible?) to fully develop both in the same context. Not only because time and dev resources are finite. But mostly for structural reasons: they require different abstractions, different game play timing and so on; the best we can reasonably expect is either a primarily survival game with notions of constructions or a primarily construction game with notions of survival.

Then everybody is entitled to her/his preferences and free to choose one game over another.

Terrain generation:

Quote from Deirdre

Egal wo ichs versucht habe, es ist einfach alles hügelig. [...] Wenn ich mir verschiedene Maps ansehe, war das vor dem Wasserupdate nicht so extrem.

This is my impression too (but I am not sure it was much different before). A few sparse considerations:

- I suspect each user may have different expectations about how the terrain should look, depending on the area (s)he lives in. According to landscapes I am familiar with, the natural terrain is very rarely really flat and exceedingly rarely for more than a few square meters.

- The voxel concept upon which RW is based, for all its advantages, also has disadvantages: flat is totally flat, the minimum difference in level is one block, the only possible continuous slope is 45° and so on. Natural terrain characteristics are rather different.

- Recently I spent some time in brushing up my familiarity with procedural terrain generation concepts and algorithms and I remain convinced that the way to go is still long to achieve reasonably sounding results. RW does a wonderful job of masking the schematics of the terrain with a gorgeous imagery, but the underlying grid is a very rigid 'cage'.

Summary: I expect we will have to live with (some of?) these limitations, enjoying the other aspects of the game.

Terrain 'decoration' (for lack of a better term) and properties:

Quote from Bogus

Also es gibt keine grossen freien flächen, klar kann man mit allen mögliche Seeds versuchen. Mir wäre es aber lieber, wenn man die Umgebungsvariablen näher bestimmen könnte. Also wieviele Bäume auf einer bestimmten Umkreis geben soll, wieviel Wasser die Welt enthalten soll usw.

I have to admit that, living in an area (Italy) which has been intensively anthropised since millennia, I have no idea of how a primeval terrain / forest / plain ... would / could / should look.

The current algorithm for vegetation seems to me rather casual; I would expect trees to group by species or varieties: a group (grove - wood - forest) of mainly spruces here, a group of mainly maples there and so on. What comes very near is the current pine forest biome, with a strong prevalence of one species and densely packed trees.

I also expect an 'original' (not attended to by human beings) terrain to have very little 'empty space' (except for extreme conditions like desert or ice): where trees do not grow (for whatever reason), bushes take over and only above a certain altitude, or only under specific climatic conditions, vegetation reduces to grass only.

But, of course, I may be totally wrong, I am no specialist of this kind of things.

Quote from Deirdre

There's also a very nice GPS plugin, but I prefer to orientate with coordinates.

Should I guess there is a question hidden in this?

The GPS plug-in uses "standard" latitude / longitude coordinates ( N / E ) everybody is more or less familiar with. The previous scripts, as well as the F3 display, use 'proprietary' negative_longitude / latitude coordinates ( W / N ).

Of course, this is mostly a matter of convention, but I remain convinced that the generalised use of "standard" notations, already known and familiar, is generally better (incidentally, I understand that, as the F3 display has mainly debugging purposes, it makes sense for it to be as close as possible to the internal data representation; this does not mean however that those representations should be used for all other purposes).

That said, I am not an integralist... Would you prefer an option for the GPS to display its coordinates according the the proprietary convention?

@nobotious: you have mail!

Thanks for the reply, @nobotious.

I know that it is mostly a new territory: we are all used to develop our script (previously) or plug-in (nowadays) completely, so that we have everything under control, we know all the details and so on. However, this inevitably leads to everybody re-inventing this or that wheel, to duplicate code doing the same task(s) in different plug-ins, to debugging each duplicate implementation of a task, to disparate 'look & feel' and so on.

These are the reasons why I am advocating a "collaborative development" in which a number of recurring tasks are implemented only once and the single maintainer of a single task implementation can focus and spend time on making it better, more robust and so on.

No hurry, though! Given the lack of interest (at least so far), my back-ends are still little more than proofs of concepts.