Posts by Miwarre

Attached is a small, sample plug-in which adds two GuiLabels for a player (chat command /testadd) and removes either label using .destroy() (chat commands /testremovea and /testremoveb).

As far as I can tell, it destroys BOTH labels when attempting to destroy either of them. Am I missing something?
(Incidentally, using .destroy() seems to destroy ALL added GuiElements, even those added by other plug-ins).

The ZIP includes both the .jar and the sources.

Disclaimer: the plug-in is not particularly robust; DO NOT USE in production!

Quote from Lonelobo

I dont think this game is limited at the graphics output atm, my system is literly doing almost nothing and i still get low fps. And i know its alpha atm and so non/almost non optimaizations are in place.

And more or less this would affect the intermediate dev stages, whichever the programming language chosen.

Quote from Lonelobo

java is also know for not alowing 100% system usage thanks to its virtual machine.
Also C++ in combo with sfml (for example) are also great cross-platform not to mention vulkan for taking things the next level.

Sure, there might be alternative (if I am not mistaken, SFML only supports 2D graphics, though). Still, in many cases, they require separate compilation, debugging, deployment and distribution for each platform, something which might be beyond the resources of a small dev team.

Quote from Lonelobo

And the core engine jmonkey is written in opengl & c++ i think?

As far as I know, JME is mostly (or entirely?) in Java.

That said, I am not arguing that Java is the panacea of all the problems; unfortunately, there is no such a think. More modestly, that it is not such a strange choice, as sometime someone seems to imply.

Oh my!!!

I got it! The problem was that I supposed WorldElement.getPosition() returned a copy of the position vector and I used something like this:

Vector3f pos = model.getPosition();
pos.y += (up ? +10 : -10);
model.moveTo(pos, 1.0f);

But apparently the returned vector is a reference to the internal WorldElement position vector itself, so modifying it is not a good think! On the other hand, the following works correctly:

Vector3f pos    = model.getPosition();
Vector3f newPos = new Vector3f(pos.x, pos.y + (up ? +10 : -10), pos.z);
model.moveTo(newPos, 1.0f);

(not the most efficient way, but the clearest, I think).

I apologise for the time you have spent on this! I should have thought more beforehand, but I have been probably confused by the lack of something like the C++ const qualifier in Java...

Hmmm... things are getting more and more "interesting"...

I made a very simple, test plug-in and, indeed, everything works as advertised. In a slightly more complex one, however, I see no effect effect of Wordl3DModel.setPosition(), .setRotation() and .moveto(). I am still trying to understand where the difference is.

The docs say: "destroy() Destroys this element, i.e. remove it from all players."

1) Does it also remove the element from its parent (if any)?

2) Does it also destroy its children (if any)?

In other words, if I have, say, a parent GuiPanel with several children and I call its (of the parent) destroy(), may I assume that no reference remain of it and of all its children in the API? (Of course, references may remain which I have made myself and it would be the responsibility of the plug-in to clear them).

Or it is necessary to call the destroy() method of each child?

Quote from Galveston01

No, I need those routes for implementing collision in my SimpleCars Plugin. The model isn‘t made by me and it is customizable by the users. Of course, I can force every model to pass those routes in their Config (*.car) file, but it would be nicer to get it progrmmatically
Alternatively it would allready help to simply get the models width and height.

I see. I don't think there is any *supported* way to do this now. I would investigate what the CollisionShape.getData() method (in either overload) returns: it is marked as "used internally", undocumented and then subject to change, but, who knows...

Quote from Lonelobo

Also a realy small question: why did u (@red) programmed this game in java and not c++

Of course, I can only speak for myself and the RW dev team will answer this point but, while I am a C++ developer more than anything else, I arrived at the same conclusion of the RW dev team (this was before I knew of RW): Java has some important strong points over other languages, for instance regarding portability across platforms; the Java VM is practically identical in all platforms and ensures a highly constant context.

Arguments could be made for Java being slightly less efficient than C++, but the literature has shown that the gap is reducing and might be marginal in applications where the graphic output is going to be the bottle neck.

Add the availability of nice (and platform-independent!) libraries like LWJGL or JMonkey and the choice seems easy.

There are alternatives but, for instance, the most fashionable nowadays, i.e. Unity, is actually a messy behemoth with heavy cross-platform issues.

Version 1.0.0 is available!

This fixes (hopefully...) the recent bugs and adds the missing function: a way to enter the name of a new way-point via the control panel. I have also added a small caption to the GSP data window with a hint on how open the GPS control panel.

This will be the last version of this plug-in: I'll fix bugs (one never knows...), but I will not add any new feature.

Please see the first post of this thread for details and download link.

Thanks!

Not sure to understand: presumably 'you' made the model, so 'you' should know, don't 'you'?

Quote from red51

So finally I did some tests about that, unfortunately I wasn't able to reproduce the issue I tested all scenarios, i.e. setting position/rotation before adding the model, setting position/rotation after adding the model, calling moveTo() before/after adding the model etc.

Although I just tested it in singleplayer (and LAN). Do you run it in multiplayer eventually? I didn't test the behaviour when there is a latency between the server and the client.

Otherwise I have no idea why it doesn't work on your side... only thing I noticed is that the speed in the moveTo Method is quite slow, so when providing 0.01, the element barely moves. I guess we may change that. But everything else worked as intended.

Can you maybe provide a test-case or alternatively send me the code via PM?

Display More

Thanks for spending time on this, I appreciate. For moveto() speed I tried 1, 0.1 and 0.01 and there is no difference: no movement at all.

I did all my tests in mulitplayer on a local dedicated server (as it is easier to set a debug session with it). I'll try in single player AND I'll provide a sample plug-in.

I am having issues when using Player.hasAttribute() early in the plug-in execution. For instance, this simplified example plug-in calls that method in several player event handlers:

public class Test extends Plugin implements Listener
{
    static final public String    key_testAttr        = "com.vms.testAttr";
    @Override    public void onEnable()
    {
        registerEventListener(this);
    }
    @Override    public void onDisable()
    {
        unregisterEventListener(this);
    }
    @EventMethod
    public void onPlayerConnect(PlayerConnectEvent event)
    {
        Player    player    = event.getPlayer();
        if (!player.hasAttribute(key_testAttr))         // <= EXCEPTION!
            player.setAttribute(key_testAttr, true);
    }
    @EventMethod
    public void onPlayerChangePosition(PlayerChangePositionEvent event)
    {
        Player	player	= event.getPlayer();
        if (!player.hasAttribute(key_testAttr))
            player.setAttribute(key_testAttr, true);
    }
    @EventMethod
    public void onPlayerSpawn(PlayerSpawnEvent event)
    {
        Player player = event.getPlayer();
        if (player == null)
            return;
        if (!player.hasAttribute(key_testAttr))
            return;
        player.sendTextMessage("It did work");
    }
    @EventMethod
    public void onPlayerCommand(PlayerCommandEvent event)
    {
        Player        player    = event.getPlayer();
        String[]    cmd        = event.getCommand().split(" ");
        if (cmd[0].equals("/test"))
        {
            boolean attr    = player.hasAttribute(key_testAttr);
            player.sendTextMessage("hasAttribute: " + attr);
        }
    }
}

This generates the following exception in the onPlayerConnect() when a player logs into the server:

java.lang.NullPointerException
        at pluginapi.objects.PlayerAPI.hasAttribute(SourceFile:194)
        at com.vistamaresoft.test.Test.onPlayerConnect(Test.java:16)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at pluginapi.PluginEventHandler.triggerEvent(SourceFile:169)
        at z.l.execute(SourceFile:93)
        at v.b.run(SourceFile:24)

This exception is apparently caught somewhere in the call chain, as it does not crash the server.

In this sample plug-in, the same Player.hasAttribute() method called in other event handlers does not raise any exception.

HOWEVER, in other plug-ins with more complex (and presumably lengthy) player initialisation (on connect or on spawn), I get an exception in the PlayerChangePositionEvent handler, which is apparently called before the PlayerSpawnEvent handler. This exception DOES crash the server.

Uses of that method in or after the PlayerSpawnEvent handler has been called seem to work correctly.

In all these cases, if I replace the offending call to Player.hasAttribute() with if (player.getAttribute(key_testAttr) == null) (semantically equivalent) no exception is raised.

This may be a work-around, but it seems like something strange is happening.

@anfaenger: thanks for the report.

In fact, I just discovered that there are further problems since the update and I am still trying to debug them. For the moment being, I am suspending the release of the plug-in until they are fixed.

I think that the presence of a previous older version or not should make no difference and you have simply been unlucky in one case and lucky in the other case, as the problems are not clear yet but have probably to do with timing and sequence of initialisations.

I am sorry for the inconvenience and I am trying to fix it as soon as possible.

@red51: I did test the inter-plug-in call and it works flawlessly! From plug-in A, I could call:

1) a non-static method of plug-in B by retrieving it with Plugin.getPluginByName() and calling the method of the returned object
AND
2) a static method of plug-in B with the usual syntax Class.method() (of course, no need of Plugin.getPluginByName() in this case).

In both cases, the API located the correct target plug-in. The only, obvious, requirement is at develop/compile time: add the .jar of the target plug-in B in your project

Who didn't forget a push or even a commit some time? Let him be the first to cast a byte...

(cast to what?)

Quote from red51

Unfortunately I wasn't able to look into this issue yet But I will finally do that within the next days.

Thank you for your reply (and, yes, I knew I was kind of pushing, but this point is a show stopper for me at the moment).

Quote from red51

About the moveTo method: When removing the model before it arrived at the final destination, and then re-adding it, it will jump to the final destination instantly. Right now the moveTo() only happens clientside (so the server only see's the final destination)

Ok, this explains the jump and makes sense. The question is that, unless I have overlooked something very obvious, I can have either the jump (with the remove-then-add-back trick) or no movement at all (with no 'tricks'), with nothing in between. I tried speeds 1, 0.1 and 0.01, hoping one of them would be in the right range to see some movement, but so far with no luck.

Quote from red51

If it's necessary to have a exact position serverside, we will implement it of course

If this means that only the player originating the movement will see it, this might be a problem for a model visible to all players. As far as I can imagine things right now, a very precise movement sync across the different players is not necessary, but a general consistency among the various points of view might be important.

An example can be doors: I do not think an opening door starts and ends rotating exactly at the same frame (or tick or whatever) for all the players looking at it, nor that it has exactly the same intermediate angle at any frame for all the players. Still, it seems that all the players see generally the same process generally at the same time (of course, network latency has a part in that, unavoidably).

This is the kind of consistency which would be useful to have. Whether this can be achieved by broadcasting all the intermediate positions to all clients or just the moveto() parameters letting each client to interpolate by its own or in whichever other mean, you surely have more elements to decide that I do.

As we are wishing, however, a detail which would be useful, is some sort of notification to let the plug-in know once the moveto() is over.

Thanks!

Am I the only one to experience this issue? Or the only one failing to understand something too obvious to be stated?

Version 0.3.1 Available!

No new features, only increased robustness and some more checks on parameters, as after yesterday RW update the order in which plug-in methods are called may be different and plug-in initialisation may occur differently.

See the first post of this thread for details and download.

Enjoy!

Probably I found something.

Yes, ultimately my plug-in is causing the crash, but it seems that the new update changed the order in which plug-in functions are called, so initialisation no longer occur in the sequence I expected and some plug-in functions are called before everything is set up.

Expect a plug-in update soon.

Quote from red51

Since attributes are shared, it's indeed important to make sure that another plugin does not overwrite your attribute. The best thing would be to use a proper naming convention (i.e. just something like the package name etc)

Well, so far I have prepended each attribute key with the plug-in name, feeling that the full package name would be too long and a waste of memory to be repeated for each key (for instance, my GPS uses 7 attribute keys for each player), but it may make sense, after all.

Quote from red51

It should be possible indeed, but in case it still doesn't work, please let us know

I'm going to test it rather soon (right now I'm debugging a strange NullPointerException with my GPS after the update) and I'll let you know, but I am confident.

Quote from lenko

I have changed with another plugin in a txt file. Then enter "rp" in the console. This was followed by the crash. The log I have sent to the @red, who told me that it s.gps plugin probably lies.

Ah! So, if I understand correctly, the crash occurred in a "reloadplugins" context; this is an important piece of info. I'll try this out.