Laylem reports: some blocks in shop are fixed ... #2956
Labels
No Label
1. kind/balancing
1. kind/breaking
1. kind/bug
1. kind/construction
1. kind/documentation
1. kind/enhancement
1. kind/griefing
1. kind/invalid
1. kind/meme
1. kind/node limit
1. kind/other
1. kind/protocol
2. prio/controversial
2. prio/critical
2. prio/elevated
2. prio/good first issue
2. prio/interesting
2. prio/low
3. source/art
3. source/client
3. source/engine
3. source/ingame
3. source/integration
3. source/lag
3. source/license
3. source/mod upstream
3. source/petz
3. source/testserver
3. source/unknown
3. source/website
4. step/approved
4. step/at work
4. step/blocked
4. step/discussion
4. step/help wanted
4. step/needs confirmation
4. step/partially fixed
4. step/QA main
4. step/QA NOK
4. step/QA OK
4. step/question
4. step/ready to deploy
4. step/ready to QA test
4. step/want approval
5. result/cannot reproduce
5. result/duplicate
5. result/fixed
5. result/maybe
5. result/wontfix
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#2956
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Laylem reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
this is intended, but i agree that the reasoning isn't apparent.
there are 4 different kinds of shop entities, which handle 4 different situations.
the goals, in order of importance, are:
because players on a lot of large servers densely cluster smartshops in small areas, reducing client-side lag is a very important consideration.
there are 3 relevant drawtypes for entities, that result in them appearing in fundamentally different ways. quoting (loosely) from the lua api docs,
server-side, these all have the same load 1
client-side, things are more complicated. if the cost (FPS drop) of rendering a single "sprite" entity is 1, then "upright_sprite" is 2-3, and wielditem is 3-10 2. the exact scale may vary from GPU/CPU to GPU/CPU, these numbers are from my informal tests used to get a general sense of the problem.
the naive solution, then, would be to use a single "sprite" item to represent all the items in a shop - that optimizes the load on both the client and the server. however, it can't display all items in a reasonable way.
if a non-node item lacks a
inventory_image
orwield_image
value, it shows up as an error. but a node gets special treatment by the engine if it lacks those - the node is rendered in 3d, and converted into an image in perspective 3. there is currently no way to generate that image and use it as a texture in a sprite or vertical_sprite 4, so there is no way to represent some nodes in a shop w/out using an entity w/ the wielditem drawtype to represent them (mesh and nodebox nodes are major examples of this).additionally, trying to show a single item (large), or 2-4 items (in a grid) simultaneously, does not look good w/ a basic
sprite
drawtype. either the sprite would have to be centered well in front of the shop, or it would clip into the shop node itself, and look terrible.so, we end up w/ a very complicated set of variations meant to make most shops look good and also cause the least lag possible.
there 4 shop entity variants are:
A.
single_upright_sprite
this is used when we only need to display one item, and that item can be rendered as a sprite (i.e. it has a
wield_image
orinventory_image
defined). this is still used the there are multiple possible exchanges for the same item in the shop. there is nosingle_sprite
because that would clip into the shop when viewed from weird angles, and not look good.B.
quad_upright_sprite
this is used if there are two, three, or four distinct items for sale, and they all have a
wield_image
orinventory_image
. minetest texture modifiers are used to create a single image out of all of them. an upright sprite is used for the same reason as thesingle_upright_sprite
- it'd either have to exist far in front of the shop, or will clip through it.C.
single_wielditem
(in this image, the upper left item, the armor stand)this is a wielditem drawtype used to represent a single item which is a node and has no
wield_image
orinventory_image
D.
single_sprite
(everything that isn't the upper left item in the above)this is used when there is an item w/ a
wield_image
orinventory_image
, when the shop also has to display a wielditem. because it is 1/4 the size, it can be centered closer to the shop than anupright_sprite
w/out clipping through it, and it causes less processor loadminor optimizations i've thought of while writing this explanation:
1
within a margin of error.
2
and possibly higher, though that doesn't arise in practice.
3
there's a way to get nodes to actually rotate in your inventory if you select them i think? i've never enabled that.
4
without writing your own 3d model composer in the minetest texture modification language, which would probably be more complicated than any existing minetest mod on its own - or exposing that via the existing APIs (which would be sweet, but not something i'd {{EXPOSITION LOST
postscript
perhaps players should have a say in how the shop items are displayed? perhaps, but i think the # of players who want to deal w/ the complexities of managing that doesn't merit the amount of effort i'd have to put in to create such a feature.
i should provide images demonstrating all of the tedious details, maybe tomorrow, maybe it's too much work. poke me if you care.