Client config.properties auslesen (z.B. input_interaction)

Hi,

I found a alternative with a example with propertie by this :
(sorry for my litte english)

Properties props = new Properties();
File config = new File(getPath() + "/../../config.properties");
props.load(new FileInputStream(config.getCanonicalPath()));
String valueofkey = props.getProperty("input_interaction"); 
System.out.println("input_interaction=" + valueofkey );

@Zendoric: I don't think your example is going to work. The config.properties file being looked for is in a different machine (the client connecting to the server): no file operation on the server local file system is going to reach it.

So, the server has to ask the client to send this value and then forward it (possibly via a callback function) to the plug-in.

Just to add my cookie to the discussion, I would find it dangerous if a plugin could somehow access my filesystem when I connect to a server without my permission at least

If I consent to it then it is my fault if something goes wrong

Edit: I see on the Javadoc there is a Player.setOption(blabla) method so why not have a Player.getOption(blabla) method too to get such settings from the client?

Quote from Minotorious

Just to add my cookie to the discussion, I would find it dangerous if a plugin could somehow access my filesystem when I connect to a server without my permission at least

If I consent to it then it is my fault if something goes wrong

Edit: I see on the Javadoc there is a Player.setOption(blabla) method so why not have a Player.getOption(blabla) method too to get such settings from the client?

Well, in a sense, RW servers are already impacting heavily on your file system !

But, it seems to me nobody is suggesting RW clients should forward remote file system access to RW servers; I was suggesting (and you added relevant details) that the server can ask the client for a specific setting value and forward it to the plug-in.

This could follow the pattern of a Player.getOption(int value_ID, Callback<??>callback) method parallel to Player.setOption(), but it would require a callback as the operation is asynchronous and the answer from the client can come at any moment.

ah, I see what's wrong.

Being beginner on the development of plugin on RW until then in single player and my java being quite rusty, I was not yet pass to the stage on the role of access of the files on the server.
But something had escaped me when I realized it because it seemed to me that each player config file was not stored on the server but on each client machine. By the fact of It was so convenient for me not to intrude on the file system of the server.

However, I understand the reasoning on that.

Thank you for declaring the warning on this piece of code because I was going to use it to make a future plugin.

@Zendoric: you are right that the player config file is stored on the player client computer. However the plug-in is run by the server on the server host and, as such, has no direct access to the client file system (not should have it, as @Minotorious pointed out).

Quote from noci

gibt es eine Möglichjeit an diesen wert heran zu kommen, lesen reicht völlig.

Momentan leider noch nicht, aber mit dem nächsten Update wird eine player.getOption(String setting, Callback<String> callback); Funktion hinzukommen Wie @Miwarre schon vermutete, muss dafür ein Callback verwendet werden, da der Server diese Daten erst vom Client abfragen muss. Eine Abfrage könnte dann zB so aussehen:

player.getOption("input_inventory", (String key) -> {
    System.out.println("Inventory key is: " + key);
});

Quote from noci

Nebenbei ist mir aufgefallen das im Fokus von GuiTextField das disableClientsideKeys nicht mehr Funktioniert

Das stimmt, das wird im nächsten Update behoben!

Quote from noci

Und ich habe das gefühl unregisterKeys klappt nicht ganz oder ich habe hier (private final int[])useKeys = this.player.getRegisteredKeys(); was Falsch gemacht?

Auch das ist leider richtig... zwar müsste getRegisteredKeys() die korrekten Werte zurückgeben, clientseitig werden die Keys aber nicht richtig aus dem Mapping entfernt... auch das wird im nächsten Update behoben