Posts by Miwarre

If I am not horribly mistaken, @red51 once said that 1 block is "more or less 50cm" in a post that I'll try to find.

As I collected the below info to help my working with plank & beam constructions, I thought they might be useful to other too. All linear sizes assume the semi-official size of 1 block = 50 cm.

setp (SET Position increment)

1 setp unit = 0.125 cm

setl (SET Length increment)

1 setl unit = 0.5 cm (= 4 x setp unit)

setr (SET Rotation increment)

1 setr unit = 1°

Plank thickness: 2 x setp default steps = 2,5 cm.

@red51: of course, both modeless and modal 'dlg boxes' (between quotes!) have their uses and might be useful. I think to have shown above that I expect plug-ins GUI's to be more often more suited to modeless rather than to modal.

It is true that mouse interaction with modeless 'dlg boxes' might be tricky to implement. given the current mouse management in RW. I still believe, however, that keyboard interaction could be implemented rather easily and efficiently along the lines we discussed here.

Keyboard interaction may be considered old-style, but practically all plank / beam construction in RW is made through keyboard and nobody seems to complain.

Eclipse here, as I already use it for other projects.

Oh yes! I didn't think of the library "trick"; I am still not accustomed to the fact that a plug-in can use the full Java machinery!

A pug-in instance getter would also be useful indeed. Thanks!

Sorry for answering in English, but I do not know German (I used Google Translate to understand (understand?) the questions).

Quote from PatrickBronke

1. Wie sag ich dem Plugin, wo sie sich auf dem Server befindet?

Das Plugin ist auf C:\RCPlugin\RCPlugin.java
Die Config ist in C:\RCPlugin\temp\config.txt

I assume this is still to decide. I expect the directory where plug-ins have to be placed to be fixed: something like "/<main_RW_server_directory>/plugins" and the config file will have to be placed in some directory relative to that one.

Quote

3. Wie lese/bearbeite ich eine Config?

With any text editor, which does not add any format code (or other type of code) to the text. Text editors of IDE's are usually fine.

Quote

2. Kann man auch prüfen, ob die Config existiert und wenn nicht, dass sie automatisch eine erstellt?

It depends on how do you plan to access the config file itself. For instance, if you use the java.io.FileInputStream() function to access the file, the function would raise a FileNotFoundException exception if the file does not exist.

Quote

z.B. In der config.txt steht:

Java

Willkommen_Text="Willkommen auf dem Server"

Der Text soll angezeigt werden, wenn jemand den Server betritt

Mit dem Befehl /editwelcome <Text> soll der bearbeitet werden.

Wie macht man das am besten und am einfachsten?

Display More

I am not sure to understand this. Can you elaborate?

A couple of scenarios:

*) A shop (or, in general, economic) plug-in may need to regulate access to its resources in some ways duplicating or competing or contrasting with an area protection plug-in. In the best of possible worlds, the former plug-in could query the presence of other plug-ins covering similar tasks and co-operate with them, by query them or whatever.

*) A package of specific 3D objects (say, a collection of buildings, or of vehicles, or whatever) may be released. Several plug-ins may include them in their own assets (duplicating resources and making maintenance of the 3D object harder) or the package may be a plug-in itself and other plug-ins may 'ask' it for assets to use.

Just two examples, other could surely be made. The bottom line is that, now that the new API is still fluid, it might be wise to start thinking of ways, protocols, ... by which plug-ins can co-operate and inter-operate.

Quote from yahgiggle

The problem i see with this is how do you get that guiPanel to show in the first place

I see at least two scenarios, regardless the interface is a GuiPanel overlaid on the screen or a 3D object with some text on it within the scenery:

1) the interface is related to a specific world point or area: the catalogue of a shop, the floor selector of an elevator ( ), the story of a quest giver, etc; some proximity detector code in the script of the shop/elevator/quest could easily detect the player position and show the interface on coming and hiding it on leaving.

2) the interface is not area-specific: then some command is needed (like the chat commands right now) to trigger its initial display; if the interface items are selectable, they may trigger some action, including updating the contents of the interface itself to show different statuses or contexts or menus (a navigable interface). In principle, instead of the many commands for each script common today, a plug-in could have a single text command, showing the top level menu of that plug-in and from there go on through selections in the interface itself: less things to remember and less occasions for typos.

If a plug-in manager is implemented and if a generic "main interface entry point" is decided (like a onMainMenu event), it would even be possible to have a list of running plug-in, select one and have its "main menu" displayed ,without any textual command at all.

Quote from zfoxfire

I jump back and forth between different languages and forget those little things.

Quote

Java

public commandInterpreter(float x, float y, boolean relativeposition) {
        super(x, y, relativeposition);
    }

Quote

I don't know what you mean by the text being repeatedly set.

Sorry, perhaps "repeatedly" is not appropriate: the label text is set in several points of the code, and one would assume that the purpose is to show this text.

Quote

[...]determine what text is printed to the screen.

Well, I cannot see any point where the GuiLabel is actually displayed. The text IS set, but never shown, as far as I can see.

Quote

What do you mean by select them ?

As I described elsewhere (but I do not remember where... ). "Taxi" could be listed in the GuiPanel with a big 'T' (upper case, coloured, bold, whatever) and the press of the [T] key intercepted, triggering the correspondent code. Similarly for the other commands.

Quote

What memory issue do you see?

Human memory, player memory, not RAM! No (or less) need to remember command orthography, to pay attention to typos and so on.

Just had a cursory look. A few comments:

1) Purely stylistic, but usually classes have initial upper case while variables have initial lower case. So, the class consoleListener and the class commandInterpreter would usually be spelt class ConsoleListener and class CommandInterpreter.

Also the variable commandInterpreter CI; would be better spelt CommandInterpreter cI;. This has some consequences, as when the variable is used later as in CI.parseString(tokens); the 'instict' would be to see the invocation of a static method parseString() of a hypothetical class CI.

2) In line 12 of the CommandInterpreter constructor, the parameters passed are not used, rather literal values used in their stead; if the use of literals is intentional, then it is useless to pass any parameter to the constructor.

3) The CommandInterpreter class is derived from GuiLabel and its text is repeatedly set, but the label itself is never shown on the screen of any player; am I missing something?

4) Do I understand correctly that the GuiLabel origin of CommandInterpreter is used only to display generated text? Why not using it also to display the command themselves? And perhaps even to select them by intercepting a few strategic key presses, without relying on memory?

@zfoxfire: no, no defs reversed.

Now, think of an elevator: you enter it, the elevator button panel appears. No need for the game dynamics to stop, in fact, I would find it disturbing; the elevator panel is there but you can continue to play the game, perhaps just to exit the elevator without going anywhere with it.

Or think of my GPS plug-in: you set the display of one waypoint and move toward it, then you bring up the GPS panel to move to the next waypoint; why should the game stop? (and in fact it would not stop: you would stop to react to it, but the world would go on around you, which I personally would find disturbing in most cases.)

Perhaps, your ATM example is different. Yet, examples could be made to show the contrary: assume you are pursued by a gang of zombies (YEAH! Zombies! :evil: ), you stop at the shop to buy a set of wood poles (or whatever is used against zombies, perhaps wood poles are for vampires, nor familiar with either kinds...): you are 'frozen' interacting with the modal dlg box, but the zombies are approaching and you cannot do anything... worrying, isn't it? Admittedly contrived, but I believe it shows my point.

@zfoxfire: while visually adding some GUI widgets (buttons, even drop lists or combo boxes) to the current API to build an appearance of dialogue boxes might not be such a tremendous amount of work, interacting with them is another thing entirely.

Remember that currently there is no mouse cursor in 'normal' RW work, so there would be no way to point and click those widgets. I can speculate that providing a mouse cursor would require a rather deep architectural change.

Also because for almost all the usages I can think of, those 'dialogue boxes' would better be modeless, rather than modal, and would require the co-existence of a double mouse model: like the current one (no mouse cursor as the mouse moves the view) when you look at the scenery and another with a mouse cursor to point and click widgets when you look at the 'dialogue box'; of course assuming the programme can guess what you are looking at!

This rather long discussion between @red51 and me was mostly focused on a way to provide a sensible first step to allow some kind of interaction between the user and API objects (GUI panels included) within the framework of the Java plug-in API as it is now or with limited changes.

Thanks. Good news, as always!

I'm glad we are eventually reaching some common ground! (possibly the usual excuse about native language can be brought in again: English is not my mother tongue and, IIRC, is not yours either...)

Quote from zfoxfire

Maven would address only these following points you brought up[...]

A plugin manager/UI is the last part of the puzzle.

Indeed!

Quote

I think we are just using our terminology differenty a "gui" is something launched from a desktop interface such as Windows that is graphical. A UI is the "gui" of Rising World where you play normally.

I assume there are formal definitions out there, but for me, informally, a UI is a User Interface, i.e. any mean allowing an interaction between the user and a device/application/.... Possibly, even the hands of a clock are a user interface too, but I prefer to think that a UI should allow both output to AND input from the user, so the hands are not enough to qualify as a UI, buttons/knobs to set the clock time (or to control other clock functions, like the alarm) are also needed.

A GUI is a Graphical UI, i.e. a UI to a software application allowing output/input of more kinds than purely textual.

Quote

A gui like you launch from a desktop is out of the question since not all servers offer a gui. Windows always has a gui but dedicated Linux servers offer only a command line.

Like you said, some rented game servers do not offer a console option. This immediately rules out the option of a command-line tool

Possibly some trick could be devised to circumvent this limitation, but surely it risks to be hacky and to raise more problems than it would solve.

Quote

It seems like RCON is the way to go.[...] However it needs a few improvements.
[...]

This was my impression too. That RCON could benefit from improvements is understandable, as it is not a really finished product yet. We can expect it will grow and improve with the growing needs.

Quote

Assuming loading/unloading plugins is dangerous while users are logged in and world is modifiable, offer a "maintenance mode" [...]

Single-player is a lesser problem; a plug-in manager runnable from the first screen, when no world is loaded (and no 'server' is actually running) could be perfectly acceptable for users and would avoid any issue from world access concurrency.

Dedicated server is more tricky. As you said, plug-ins may (well, in the near future) change the world in many ways and altering it 'under the feet' of the users may have collateral effects. OTOH, plug-in update / turn over is not done every day and a responsible server owner can alert the players beforehand; server down time is always negative for the users; should RW allow at least some kinds of maintenance / set-up / fine tuning without necessarily turning off the server, this would be a big plus comparing with competitors.

It is a point to keep in mind.

Quote

B2)
So regarding quality control, I would assume that JIW is not going to offer quality control.[..]

I do not expect JIW to assume any responsibility about this. Still some form of control could be automated, looking for used classed and methods, and may stop automatic acceptance for plug-ins which, just to make some example, try to 'phone home' or to export info or whatever. It would be far from fool-proof, but it might be a point to keep in mind.

Quote

B3)
I'm not following you on this. I interpret it to mean we should limit who the mods are distributed to. My believe is that the limitation is only on who can upload, not who can download.

There might be statistical purposes and there might be reasons to limit the download only to registered users or something similar.

In development:

1. Port to Java of my LUA script GPS, which implements on-screen coordinates and heading (according to common navigation practices), home and other waypoint position with teleport and on-screen display of distance and heading.

• 1 developer
• Status: code complete, waiting for the API implementation for debugging

2. Port to Java of my LUA script TELevator, which implements the concept of elevator; currently elevators are implemented via teleporting, the plan is to have 'real' elevators, with visible, moving, 3D objects.

• 1 developer
• Status: code being worked on

@Jaob: about money and economy in RW, have you read this thread? It contains several interesting contributions and thoughts.

Quote from zfoxfire

not sure if the API supports mouse events however.

Not that I know. Support for key stroke interaction (as with the [F] key for doors and smelters) has been discussed at length here, but I have no idea if it is already implemented in this API version.

Quote from Carm3D

Okay I've created a little test .obj and texture image to go with it. If someone can tell me how to add it to the game, I'll try making something more elaborate. See attached file.

As @zfoxfire said here:

"The API was just published last week and it still isn't implemented in game"

Right now, the API is only for documentation and to help authors to familiarise with it; the programme itself still has nothing of it. Actual implementation should come "in a few weeks".

Quote from zfoxfire

Whatever plugin manager comes to RW must have an option to run from the command line for.

Not sure to understand. For what?

Quote

Commands from the game console is fine too but many of us running servers do management by shutting down the server and manipulating files from command line.

It seems to me that some initial consensus has been reached here (including @red51!) that in-game commands affecting the set-up of a dedicated server are too risky.

Additionally, not all ready-to-run RW servers which can be rented by final users provide a command line; many only provide FTP access or a web-based equivalent.

As the server itself, as far as I can see, currently allows no user input (it only has stout/stderr output which are printed to the console only if the server does not run in background), a way has to be added to allow it, either by an external manager console or by extending RCON or by whatever other mean deemed appropriate.

Note that this does not need to be limited to plug-in management; it may also (or primarily!) be used for configuration / tuning of other server aspects as well. In any case, the server itself should be modified to react to this input.

I understand quite well that this is not a priority now; however, I believe a user-friendly way of managing a dedicated server would make RW to stand a part from the most obvious competitors and would help enlarging the installed base.

Quote

I stand by my last posts about using Maven as a the best repo option for distributing plugins[...]

I looked at both links you quoted and, sorry, but this is not my idea of a complete plug-in downloader / installer. This might very well be the back-end of it, then the real downloader/installer should come.

You know how to make use of it; I also can surely quickly learn how; a number of current and potential RW users will also be surely at ease. However, I expect many users would look at those web pages and ask: "Well, now what?" No disrespect intended, mind; I am not saying that they are dumb or whatever, not by any mean; they might very well be much better than me at modelling or building or 'surviving' or whatever, they simply have different priorities, different experiences and expertises.

My idea of a plug-in downloader / installer is a tool which:
*) displays a list of installable plug-ins (possibly accessing a Maven-driven back end, I have no objections on this, but the decision is not mine), checking which plug-ins are already installed in the server and possibly the version of each;
*) if a GUI is possible, the user clicks on a plug-in or, if only a text interface is possible, plug-ins are IDentified in some way and the user enters the number (or ID of whatever sort) of the required plug-in;
*) the tool accesses the back end, downloads the appropriate file(s) into the appropriate server directory, performing any additionally required step, if any;
*) if everything goes ok, it tells the server to enable the plug-in, otherwise displays an error message.

Quote from Jaob

I would add the possibility to search for plug-in updates (so a repository with version control is needed). One annoying task for server admins is to update installed plugins manually, so a list which plug-ins need an update with the choice to update them automatically would be nice.

Good point. OP updated.

Quote

In my opinion this is the most important question at the moment I'am not sure right now, if its worth the trouble.
A plug-in manager just makes sense at all if there are enough plug-ins to manage. If someone rewrite the existing lua scripts there are maybe four or five plug-ins. I'am not sure if there will be enough new plug-ins in future for a plugin-manager to makes sense.

The number of plug-ins is surely limited today. However, I would not be surprised if it should increase significantly in the near future. The more the API will be able to do, the more ideas will come to plug-in authors and the more plug-ins we will have.

Of course, it also greatly depends on how widely used RW will be; but plug-ins may help even in this aspect, originating a kind of 'virtuous loop'.

So, I am aware that right today a plug-in manager is not a priority, not only because there are not so may plug-ins, but also because there are more important aspects of the game to bring forward.

Still, I believe it is useful to start thinking about it.

Quote

Most plug-ins will be developed for servers (you actually could use them in singleplayer but e.g. "areaprotection" doesn't make sense at all). Player who would like to play on a server with plug-ins don't have to download the plug-ins (unlike Minecraft which has several Modmanager), so in my opinion a plug-in manager would be used mainly by server owners. Most server owner knows how to install plug-ins manually and because there aren't enough plug-ins it's not complicated to update them (e.g. with a little .sh script).

Yes and no: many ready-to-run game servers provided by companies out there have no actual access to a console shell from where you can launch a .sh file.

Also, any automatable (spelling?) task still requires a well-known repo to access and some known protocol to query it.

Collecting and organising thoughts and hints dispersed in recent threads, this thread is to discuss a specific feature set of a future plug-in manager (or a separate form of it), namely:

*) accessing a list of published plug-ins from one (or more?) well-known source(s)
*) accessing a list of plug-ins updated since installation ('@Jaob' suggestion)
*) downloading selected plug-ins
*) installing them into the local / dedicated server
*) uninstalling / removing

A) This requires some pieces of infrastructure / code:

A1) a repository where to store published plug-ins (plenty of examples/resources for this, but a selection has to be made)
A2) a protocol to access data / files from the repo (again, plenty of existing choices and a selection has to be made)
A3) a way for plug-in authors to publish/upload their plug-ins into the repo
A4) a UI for final users to select the required plug-in(s) for downloading / installing

B) Also, a number of policy decisions are required:

B1) If the publishing / uploading is open to anyone and/or if some registration / authentication is required
B2) If the "system" (i.e. ultimately JIW staff) enforces some kind of quality control or not
B3) If there are controls on who is downloading what or not (and, in case, which kinds of controls)
B4) If the plug-in manager is the only supported/documented way of installing plug-ins (restricting manual addition of files to a well-known directory will be difficult, but installation might require additional steps than simply dropping files; or not!)

And eventually, the grand decision:

B0) Does this make sense at all?

In particular, point A4 above might be of some import in particular for remote, dedicated servers, for which console access (via SSH or other) is not necessarily available. A general solution will require implementing some kind of UI for managing a remote dedicated server (for plug-ins, but also for other purposes, of course), which is not a trivial task.

As plug-ins can be used on local installations, but make most of their sense on dedicated multi-player servers, whether implementing this whole machinery is worth the trouble or not requires careful evaluation.

Awaiting comments, integrations, suggestions...