-
Notifications
You must be signed in to change notification settings - Fork 579
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add wield3d #2097
Comments
There are at least two mods that provide this (from my memory):
From what I've seen they mostly do their job, without game breaking, but have some rough edges I will describe below:
I never had any problems with this on actual servers making it not practical.
Works partially, I did test it on Hometown just now, items, tools show up, but blocks are not, it seems. |
The biggest problem with wield3d currently is the 180 degree reversal glitch with b3d model attachments, see #1447 (comment) While we can get around that problem by tweaking the animation key-frames, as I have explained later in that issue and elsewhere, I would prefer to find a better solution. However, this may turn out to be our only option if the problem lays with the rendering engine.
Shouldn't be a problem in most cases, although the ability to specify attachment position/rotation would probably be helpful. wield3d does this by exposing a global table which is far from ideal.
Historically, stray objects have been a problem for this mod but I think this is less of a problem with recent versions. luanti-org/luanti#6786 would also probably be helpful in this regard.
Absolutely you should, however there is a MTE bug that causes the wield item to disappear when the attachment rotation changes, see stujones11/wield3d#2 Ultimately I would love to see something like wield3d included in the base game though I am not sure the mod should be added as-is. IMO it would be best incorporated into the the player_api mod where you already have access to the individual player objects. If someone wants to work on the code for this I am happy to make the necessary model changes to remove the 180 degree reversal. |
Just to add, I am massively in favour of seeing this added. |
This sounds more like my wieldview mod where the wield item is actually part of the 3d_armor model. Consequentially, this does not involve the use of entities nor does it suffer from attachment glitches, however, it is very limited in terms of item shape as it only works with items that can be extruded from their inventory image. Cubic nodes can be optionally displayed as tiles but this is off by default as it looks pretty lame, IMO. |
I think a good compromise would be to add a non-entity based wieldmod. Cube nodes can be represented with an extra mesh part where you map 1 tile to that wieldcube. Can't do stairs and slabs, but it'd still be a major improvement. An out-of-tree mod could then override that with an entity based one. |
I have to disagree, the 'extrusion' method used by wieldview is very costly in terms of additional rendering unless you use a simple flat 'sprite-like' wield item, which is a poor compromise IMO. We already have much more efficient item extrusion built into the engine so we might as well use it. Adding a single entity per-player should not cause any noticeable server lag, it's really no more costly than say hp gauges, for example. Of course, whatever way the feature is implemented it would need to optional anyway. |
I think it's better to use an entity here, and fix any bugs the engine throws at us |
@rubenwardy This reminds me, If this were to be included as s a separate mod then it should probably be done in much the same way as your gauges mod re-work as that solves many of the per-player entity problems in a more elegant way than my current wield3d implementation. |
Regarding the wieldview extrusion, there is another method that may (or may not) be more efficient but is restricted to a fixed low pixel resolution. In other words, it would not play well with hd texture packs. Essentially it's just a grid of cubes uv mapped to individual pixels. It works very nicely with the right textures but is far too restrictive. I just thought I would mention it for completeness :) |
We have a PR for optimisation of engine extrusion, it removes internal faces. |
I think in reality most servers are already using this in one form or another simply because that is what their player's expect. I reckon the FPS performance hit would be barely noticeable, even on low end devices like raspberry pi. |
Yes i'm not really worried because i can't really see how it could be intensive, but checking because i'm not very knowledgeable on how it is implemented. However, a note on the 'most servers' argument: Even if most do use a mod for this already, many also don't, and the mod was added by choice which is different to adding a feature as standard in our simplest MT game. 'Noticeable' is not a good way to judge lightweightness, noticeable is around 100ms which is a huge amount of time in code. But i think i know what you mean, it's insignificant even by code time standards. |
Okay, those are fair points, although I was not using the 'most servers' argument as a reason to add this mod, it was more as a reason why there will not be any performance hit in many cases :) Regarding the implementation, it is really very simple, we just 'attach' the wielditem object to the player's arm bone. In irrlcht that is simply a case of setting the player node as the parent of the wield node and it will handle the rest, entirely client side. The only additional overhead on the server side it that we currently need to poll each player's current wield item and only apply a new 'texture' and rotation to the wield entity when the item has changed. Note that the polling is necessary whether the wielditem is implemented as an entity or is part of the player model, hence why I believe there is no real benefit in the latter approach. |
Add this to roadmap https://github.com/minetest/minetest_game/projects/1 |
Just want to say that for rendering, delays are noticeable at much less than 100ms delay since the delay happens every frame. The 100ms number is supposed to be what feels noticeable for response to input. |
FWIW, I have updated my wield3d mod borrowing some ideas from rubenwardy's re-work of the gauges mod, as I suggested here #2097 (comment) This should hopefully make the mod much more robust and efficient in a busy multi-player environment. Using the player model I adapted for my 'SAM-Viewer' app (available here) appears to solve the 180 degree reversal issue, albeit not in a way I am completely satisfied with, it's the best I got right now. This can be used as a direct replacement for the current model (offset and scaling should be correct) There may still be a small amount of latency/inertia, especially when moving very fast but this is the case for all attachments that are not made directly to the 'root' bone. The only real remaining engine issue I am aware of is the third-person visibility problem, however, there is what seems to be a working fix here: luanti-org/luanti#8342 |
Closing due to #2710 |
Please, reopen. Not solved. |
Consider using my mod instead and see if it fixes the issue. As for MTG, this is closed due to the reasons stated by paramat. |
Your mo0d is cool but it does not resolve the issue. I will try to rework on my model as MTG model, but the bug is there, Blender export or Irlich. Plase, a dev can reopen? |
Minetest Game is in feature freeze, adding a wield item is out of scope |
That's more like a bug report then, and adding such a mod inside MTG isn't going to fix that. I have reported that bug already BTW (assuming that's what you mean by "ghost wielditem"): luanti-org/luanti#11991 |
Wield3d is quite an important mod for multiplayer, whether co-op or PvP.
The text was updated successfully, but these errors were encountered: