Posts by Miwarre

An actual version is now available for download. See the top of the thread for details.

Uploaded version 0.2.0 which also supports triangular planks. See top of thread for details.

A Java Interface for (virtual) banking services - Proposal.

Background: The basic idea is that expecting one single plug-in to deal with everything having to do with money is likely to soon hit serious limits: somebody will always miss something, there might be different way of implementing single details, all the development burden will be on a single developer, and so on.

Proposal: Defining a Java interface which describes the services that a banking plug-in can implement and which separate plug-ins dealing with money in some way (shops, ATM, shipping services, subscription / renting services, ...) may use.

Each plug-in may be designed, developed and maintained separately, by different developers or teams; for specific services, even more than one implementation may be useful; and all the separate pieces will work together (plug-and-play), as they know what to expect from each other.

Interface: This is an initial version of such a Java interface. It defines points like:

*) Knowing the name and the symbol of the currency used by the 'bank'
*) Querying the 'bank' for availability of a given amount of money for a given player
*) Querying the current balance of the account of a player
*) Transfer money from one account to another, including special 'global accounts' for the bank itself and for the "World" (i.e. the whole server money system or "State")
*) Query transactions for a given account ('bank statement'), together with a format to held data for those transaction (new to ver. 0.2.0).
*) Reserve money from an account for future payment to another account
*) Ask an account (player) to authorise a payment request from another account
*) Establish recurrent payments from one account to another

Notes:
*) The interface does not implement any service: it is not its purpose! It defines method names, parameters, conditions and return values by which a 'bank' can expose its services to any other interested plug-in, so that the latter can know what to ask and how.
*) 'Banks' are not required to support everything; in particular, a 'bank' may choose not to support the last 4 items above (statement, reserve, pre-authorisation, recurring payments) and the interface will provide a do-nothing-and-return-an-error stub.
*) More services can be defined in the future, as well as more default implementations, if there is a demand.

Files: At the moment the following files are provided:

*) BankIntf.jar: the compiled interface.
*) BankIntf_src.zip: the whole source code of the interface.
*) BankIntf_doc.zip: the Javadoc of the interface in HTML format.

Setup: The setup steps to use the interface from a plug-in are described in the Javadoc itself.

Samples: A simple 'banking' provider plug-in implementing this interface and providing some basic services can be found here. An example of a consumer plug-in (i.e. a plug-in which uses the services provided by the interface if available)can be found here.

Important disclaimer: The whole matter is only for dealing with in-game, fictitious money. It is not geared toward, and it shall not be expected to deal with, real money, nor shall it be used to manage any amount of real money!!

Comments and suggestions are welcome!

Quote from red51

The head has a fixed offset, so it's not a problem to calculate it from the existing player position. Although this offset may change when the new playermodels are implemented... maybe we will add a "getHeadPosition()" or something like that for reasons of convenience

Any additional method is surely welcome. But for this specific goal a Player.getHeadPosition() is possibly not so necessary.

Unless you plan to allow player models to be really HUGE (the size of T-Rex, for instance), but plan to have them all in the range of the size of a human being, placing each "balloon" a fixed amount above the player ground position, for instance 2.5 ÷ 3 m (5 ÷ 6 blocks) would be enough for it to clear the player head top.

This would also have the added advantage of a constant relationship between player position and balloon position, making easier to see the position relationships.

From one side, any plug-in can implement a filter on a per-player basis (and several plug-ins/scripts limit specific features / access to specific groups of players).

On the other hand, limiting the availability of specific plug-ins for specific players seems difficult without some collaboration from each of the plug-ins themselves; which means that any plug-in that does not lend this collaboration would escape any filtering.

In summary: at first sight does not seems (easily? at all?) possible.

Quote from zfoxfire

Interesting .... Thanks for the insight. Something tells me you're already working on this. ;-p

Not really, I am busy with completing projects already in progress (not to mention that I am writing this from an on-the-fly Linux CD live, as the main HD of my PC has problems...) but, who knows (who' nose...) ...

Quote from zfoxfire

To accomplish this, we need to know the position of a player's face on the screen.

Not necessarily, if the "balloon" is implemented as 3D text, it just needs to be positioned above the player position, which is well known. and then added as a WorldElement to the world of each player nearby. It would be necessary to rotate it so that it always faces the on-looking player, but this is rather trivial trigonometry.

Quote from zfoxfire

I guess additional player methods needed would be something to get the distance between two players so we can determine whether the other person is within "hearing" range.

Neither. The distance can be easily calculated from the respective player positions, as volume decreases with the square of the distance, it is not even needed to calculate the 'real' distance (which requires an expensive square root): the square of the distance is fine.

Maybe, the whole may have some performance impact, as distance and rotation angle needs to be recalculated for each pair of players, whenever one of them moves.

No solid knowledge about this, anyway I am pretty sure that no script or 'extension' is required, but I suspect this 'effect' is influenced by the the permissions (if you can't fly, F2 does pretty nothing!).

Hear, hear! So rightly said, @icon58!

Quote from Ranaarvalis

Na wann kommt den der erste teil schon lange nichts gehört ???

Good question!

First, I am busy finalising a number of collateral / support elements.

Second, I noticed that several events / object interactions relevant for the protection are not supported by the API yet, so I will probably release an provisional, partial, version but I do not feel very pushed to do this ASAP.

Quote from Captian_Cornball

can this be integrated with a Money script?? im trying to do the same thing

As I said above, this is exactly my idea! To communicate, the money plug-in has to conform to a (simple) interface, useful for many other things too. I'll publish the details very soon (Thursday is vacation here and I plan to spend time on this).

Quote from ozmods

I presume you have stopped working on this plugin?

Not sure if you refer to my GPS plug-in quoted right above or to the plug-in which is the main topic of this thread.

In the first case, as I told in the GPS plug-in own thread, the released version is assumed to be the final version: no more big features, but only bug corrections and small adjustments. There is a (small) update on the way, which adds another format for the coordinate outputs and (hopefully) fixes the reloadplugins issue: due in a couple of days.

Yes, I too think all those points are very nice to have.

Except perhaps for snow-capped mountains: they would look fine, sure, but I do not think that any mountain we currently see in RW is high enough to regularly have snow (at least outside of the snow biome); at least here in Italy, in a middle-latitude situation, it is hard to see any snow below 1,200 m MSL, which would correspond to a height of about 2,500 block in RW. Of course, in colder regions the snow limit would be lower, but in warmer regions higher and it seems to me RW that the intermediate (non-desert and non-ice) biomes mimic a sort of temperate, middle-latitude, situation.

Of all the listed points, the degradable tools seem relatively simple(r) to implement, so perhaps it will come sooner than other effects, who knows...

Quote from Deirdre

After 2 weeks not being in singleplayer my waypoints and homepoint are cancelled. I haven't changed
anything.

Home and way points do not have any "deadline", they do not expire. I believe you did change something, either re-installing the plug-in (this shouldn't affect the points, but one never knows...) or creating a new (single player) world, as points are specific for each world.

Quote from Deirdre

The coordinates between F3 and GPS are different.
F3 are with minus coordinates and GPS plugin without minus.
This means different destinations.

This is explained in the top of the thread. The RW proprietary (F3) format for displaying coordinates (with West-positive longitude, followed by altitude and by North-positive latitude, all unlabelled) is rather non-standard and makes difficult orienting oneself. Also the F3 screen is only for debugging purposes and chances are it will be removed when development advances. So, I would not rely too much on it.

The GPS uses the most widely used format, all over the world and in most applications: North (positive) / South (negative) latitude, followed by East (positive) / West (negative) longitude and altitude, each properly labelled.

Nonetheless, I have an update of the GPS which allows to configure the output to match the F3 proprietary format. I will upload it "soon"...

A plug-in to send items you have to any other player.

Version 0.2.1

*) Updated to the latest RWGui version.
*) Some bug fixed

(The 0.2.0 version has never been published.)

Version 0.1.0

- Features

*) GUI-only: everything is done via a GUI. There is only one chat command (default /ups, but it can be configured) which displays this simple main menu:

*) Item(s) to send (with the "Send a parcel" menu command) are chosen from the 5 quick slots:

where any of the items in the quick slots can be selected and a quantity chosen up to the actually owned quantity (you can't send 64 iron ingots, if you only have 3!).

*) Any player can be chosen as recipient, even if not on line at the moment.

*) A cash-on-delivery amount can be entered. If greater than 0, the receiving player will be charged when collecting the parcel ***.

*) A shipping cost can be defined in the plug-in configuration, with partial costs for 1, 4, 16 and 64 items (sending the same number of items costs the same regardless of the nature of the items); the sending player is charged when pressing the "SEND!" button ***.

*) Parcels you sent and parcels sent to you can be browsed (separately with the "My shipments" and "My deliveries" menu command) with this dialogue box:

Parcels sent to you and not collected yet can be collected from this dialogue box.

*) All the interface texts can be translated to another language with a short text file dropped in the plug-in folder (no need to re-compile the plug-in); details in the locale/readme.txt file.
____________________

Important - Important - Important - Important:

***) The features marked above with a *** depend on a money plug-in being installed. Any money system could be used, as long as it implements the simple Java Interface available in this thread.

____________________

Important - Important - Important - Important:

In order to work, the plug-in requires the GUI back-end plug-in available in this thread.
____________________

- Commands

There is only one command: /ups (configurable in the plug-in settings.properties) which shows the above main menu.

Installation

*) Extract the files in the ZIP placing the whole ups folder into the plugins folder of RW (if the plugins folder does not exist, just create one). The resulting hierarchy shall be:

── RisingWorld
    ├── plugins
    │    ├── ups
    │    │    ├── locale
    │    │    ├── ups.jar
    │    │    └── settings. properties

*) If it is not already installed, the GUI plug-in available in this thread shall also be installed.

*) In order to make available the money management features, a plug-in implementing the Banking Interface shall also be installed; a sample plug-in implementing this interface can be found here.

Open points and known issues

*) Some types of items cannot be shipped (because the API does not currently allow to "re-materialise them at the other end of the Stargate" ) : they are shown in grey in the dialogue box and cannot be selected.

*) The names of the items are provided by RW itself; some of them are not very clear (like "ore" for a number of different materials) and some are not in the best possible English (shouldn't a space be there in "iron ingot"?). Short of recreating all names from scratch, I set up for using RW own ones, to which players are already familiar anyway.

*) Bugs may well exist! I did my best but foreseeing all the possible use cases and contexts is hard. Post here bug reports, with specific steps to replicate the issues and I'll try to correct them.

I really need steps or instructions to replicate the problem on my PC or I cannot fix it!

My thanks to @Captian_Cornball, who first had the idea of an UPS plug-in!

Quote from ArcticuKitsu

People claim that ETS2 is a junk game because SCS software won't update to DX11

Being a Linux user, I couldn't care less about DX!

The three things which bugs me more in ETS 2 are:

1) The reduced scale (I understand your point and the playability issues involved, but I would still prefer a real size scale).

2) How easy it is to earn money: earning almost the worth of a truck in a week (game time) is ludicrous! This is also related to the fact that you spend nothing to live, just for fuel, highway fares and repairs (and fines!), but nothing for eating, housing, family, etc., not even to rest in a hotel.

3) The stupidity of the car drivers!

Lastly, I would have preferred your other drivers did physically exist: I spent a night looking at my garage and I see no trace of them...

That said, ETS2 is still the game I spend more time on, after RW of course!!!

Quote from Groovaholic

Hi i may be blind as a bat but is there any way of changing the X position of the GPS to say just above your health bar? i tried to add a line into the settings.properties but I guess thats the wrong way to go about it as nothing happened.

"just above your health bar" looks like you are trying to move the Y position, not the X. To change the Y position, there is a "gpsYPos" setting in the settings.properties file.

If you really want to change the X (horizontal) position, well, this is not possible right now: horizontally, the GPS display is always centred on the screen.

There is an added complexity which stopped me (at least so far) to implement a precise position of the GPS display.

The screen H and W resolution (or the window H and W sizes, in windowed mode) of the player client may be different from player to player and in general a position which looks fine with one resolution may end up in a bad spot with another resolution.

As far as I know, a plug-in has no way to know the actual display sizes of a given player client.

Also, I don't know (and probably the dev team is not going to document it, as it may easily change in the future) how RW manages the different display sizes: is a certain GUI item (say, the health bar) positioned always at the same X and Y absolute pixel offset form the lower left corner? Or it is scaled by the resolution?

This is why I tried to place the GPS display in a usually empty, not obtrusive, spot.

Quote from red51

Makes sense With the next update, the "onEnable()" method will be called after all plugins have been loaded. To be on the safe side, we will also add an overridable "onLoad()" method, which will be called once the plugin is loaded (although in most cases you probably don't need the "onLoad()" method, since nearly all initialization stuff can still be done on the "onEnable()" method - for that reason, "onLoad()" will be non abstract, so your plugins don't have to override it)

Great, thanks!

Quote from Deirdre

Very nice. For people who are not allowed to use the console, very good feature.

This was precisely my idea. Thanks!

Quote from Deirdre

Is there any possibility to add a ground texture like gravel in this plugin?

No. The texturing is done (and can only be done) by RW itself; then, the plug-in is a medium to the RW own texturing and those are all the 192 textures which RW knows to use. Should RW add more textures in the future, they can be added to the plug-in.

[Aside: As discussed here, a future update may make built-in textures directly accessible to plug-ins for display; this would drastically reduce the size of this plug-in and the server-client bandwidth, as the plug-in would not need to contain a display copy of the textures and to send them to the player client for showing the GUI.]

Background:

When Plugin.onEnable() is called, the plug-in being enabled cannot be sure that all other installed plug-ins have been loaded and known to the system (as this depends upon the plug-in loading order which is largely unpredictable).

Then, it cannot check for another plug-in (required for some tasks and/or for additional plug-in features) to be present (well, it may, of course, but it might receive a 'false negative' if the required other plug-in is present but not loaded yet).

There are work-around, of course. So far, the best I could think of is to check for the 'other' plug-in presence in the PlayerConnectEvent, which is rare enough to not overload the server and guaranteed to occur after all plug-ins have been loaded.

Request:

A) The loop of Plugin.onEnable() calls is moved after all plug-ins are loaded.

OR

B) Another event call is added (onReady()?, onLoaded()?, ...), which is called -- once for each plug-in -- after all plug-ins have been loaded.

OR

C) Anything else along these lines!

Thanks.