Laylem reports: some blocks in shop are fixed ... #2956

Closed
opened 2022-11-03 02:04:27 +01:00 by yourland-report · 3 comments

Laylem reports a bug:

some blocks in shop are fixed orientation, some are shop orientation. See here in shanish shop: look at the ivory and chests

Player position:

{
	x = 1584.1340332031,
	y = 1.5,
	z = 1123.0660400391
}

Player look:

{
	x = -0.60559695959091,
	y = -0.69566208124161,
	z = 0.38640204071999
}

Player information:

{
	protocol_version = 41,
	major = 5,
	minor = 6,
	version_string = "5.6.1",
	ip_version = 6,
	min_rtt = 0.16699999570847,
	max_rtt = 1.62600004673,
	avg_rtt = 0.17700000107288,
	min_jitter = 0,
	max_jitter = 1.4520000219345,
	avg_jitter = 0,
	connection_uptime = 8557,
	lang_code = "",
	patch = 1,
	formspec_version = 6,
	state = "Active",
	serialization_version = 29
}

Player meta:

{
	fields = {
		repellant = "0",
		["ocean_build.last_warning"] = "1.66072e+09",
		["signslib:pos"] = "(-946,-7,-1995)",
		played_time = "1226999",
		yl_commons_thankyou = "43",
		partychat = "main",
		died = "28",
		hud_state = "on",
		arenalib_infobox_arenaID = "0",
		["unified_inventory:bags"] = "return {\"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\"}",
		yl_commons_player_created = "1659420654",
		["ocean_build.ocean_built"] = "11",
		inflicted_damage = "409062",
		["3d_armor_inventory"] = "return {\"3d_armor:boots_crystal 1 1920\", \"3d_armor:chestplate_crystal 1 1920\", \"3d_armor:helmet_crystal 1 1920\", \"3d_armor:leggings_crystal 1 1920\", \"shields:shield_rainbow 1 768\", \"\"}",
		crafted = "37981",
		punch_count = "19897",
		xp = "261620",
		yl_church = "return {[\"last_death\"] = {[\"y\"] = 12, [\"z\"] = 1801, [\"x\"] = -842}, [\"last_heal\"] = 1662278340, [\"last_death_portal\"] = 1665804266}",
		jointime = "1659420654",
		bitten = "0",
		yl_commons_player_joined = "1667428939",
		["stamina:level"] = "12",
		digged_nodes = "252254",
		["stamina:poisoned"] = "no",
		placed_nodes = "61270",
		["stamina:exhaustion"] = "132.5"
	}
}

Log identifier


[MOD] yl_report log identifier = BEaPRRlX7GP8kQVPdQoCm1vRxQMe2403

Profiler save:

profile-20221103T010427.json_prettyEE

Status:

# Server: version: 5.6.1-yl | game: Minetest Game | uptime: 3d 1h 14min 28s | max lag: 2.38s | clients: Issac-carterson, Bailiff, Ernesto, Insomniacs_Yello, brok, Fishy22, Ha7rpy, Laylem, flux, Parrish, jackofthebean000, Sokomine, daydream, shanish2, fur, shanish

Teleport command:

/teleport xyz 1584 2 1123

Compass command:

/give_compass Construction BEaPRRlX7GP8kQVPdQoCm1vRxQMe2403 D2691E 1584 2 1123
Laylem reports a bug: > some blocks in shop are fixed orientation, some are shop orientation. See here in shanish shop: look at the ivory and chests Player position: ``` { x = 1584.1340332031, y = 1.5, z = 1123.0660400391 } ``` Player look: ``` { x = -0.60559695959091, y = -0.69566208124161, z = 0.38640204071999 } ``` Player information: ``` { protocol_version = 41, major = 5, minor = 6, version_string = "5.6.1", ip_version = 6, min_rtt = 0.16699999570847, max_rtt = 1.62600004673, avg_rtt = 0.17700000107288, min_jitter = 0, max_jitter = 1.4520000219345, avg_jitter = 0, connection_uptime = 8557, lang_code = "", patch = 1, formspec_version = 6, state = "Active", serialization_version = 29 } ``` Player meta: ``` { fields = { repellant = "0", ["ocean_build.last_warning"] = "1.66072e+09", ["signslib:pos"] = "(-946,-7,-1995)", played_time = "1226999", yl_commons_thankyou = "43", partychat = "main", died = "28", hud_state = "on", arenalib_infobox_arenaID = "0", ["unified_inventory:bags"] = "return {\"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\"}", yl_commons_player_created = "1659420654", ["ocean_build.ocean_built"] = "11", inflicted_damage = "409062", ["3d_armor_inventory"] = "return {\"3d_armor:boots_crystal 1 1920\", \"3d_armor:chestplate_crystal 1 1920\", \"3d_armor:helmet_crystal 1 1920\", \"3d_armor:leggings_crystal 1 1920\", \"shields:shield_rainbow 1 768\", \"\"}", crafted = "37981", punch_count = "19897", xp = "261620", yl_church = "return {[\"last_death\"] = {[\"y\"] = 12, [\"z\"] = 1801, [\"x\"] = -842}, [\"last_heal\"] = 1662278340, [\"last_death_portal\"] = 1665804266}", jointime = "1659420654", bitten = "0", yl_commons_player_joined = "1667428939", ["stamina:level"] = "12", digged_nodes = "252254", ["stamina:poisoned"] = "no", placed_nodes = "61270", ["stamina:exhaustion"] = "132.5" } } ``` Log identifier ``` [MOD] yl_report log identifier = BEaPRRlX7GP8kQVPdQoCm1vRxQMe2403 ``` Profiler save: ``` profile-20221103T010427.json_prettyEE ``` Status: ``` # Server: version: 5.6.1-yl | game: Minetest Game | uptime: 3d 1h 14min 28s | max lag: 2.38s | clients: Issac-carterson, Bailiff, Ernesto, Insomniacs_Yello, brok, Fishy22, Ha7rpy, Laylem, flux, Parrish, jackofthebean000, Sokomine, daydream, shanish2, fur, shanish ``` Teleport command: ``` /teleport xyz 1584 2 1123 ``` Compass command: ``` /give_compass Construction BEaPRRlX7GP8kQVPdQoCm1vRxQMe2403 D2691E 1584 2 1123 ```
AliasAlreadyTaken was assigned by yourland-report 2022-11-03 02:04:27 +01:00

![](https://gitea.your-land.de/attachments/8e082f8d-0ed4-4283-ade6-1a3e5dfebafc)
Member

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:

  1. to accurately depict what is for sale in the shop
  2. to reduce client-side load (creates FPS lag)
  3. to reduce server-side load (creates other lag)
  4. to look good when viewed from the front

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,

  • "sprite" is a flat texture always facing the player
  • "upright_sprite" flat texture with a fixed orientation
  • "wielditem" is how an item looks when a player holds it

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 or wield_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 or inventory_image defined). this is still used the there are multiple possible exchanges for the same item in the shop. there is no single_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 or inventory_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 the single_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 or inventory_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 or inventory_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 an upright_sprite w/out clipping through it, and it causes less processor load

minor 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.

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: 1. to accurately depict what is for sale in the shop 2. to reduce client-side load (creates FPS lag) 3. to reduce server-side load (creates other lag) 4. to look good when viewed from the front 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, * "sprite" is a flat texture always facing the player * "upright_sprite" flat texture with a fixed orientation * "wielditem" is how an item looks when a player holds it server-side, these all have the same load [1](#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](#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` or `wield_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](#3). there is currently no way to generate that image and use it as a texture in a sprite or vertical_sprite [4](#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` ![](https://gitea.your-land.de/attachments/f1c7acc2-89b7-4839-9f23-d02dbd868135) 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` or `inventory_image` defined). this is still used the there are multiple possible exchanges for the same item in the shop. there is no `single_sprite` because that would clip into the shop when viewed from weird angles, and not look good. B. `quad_upright_sprite` ![](https://gitea.your-land.de/attachments/3b55646b-00cf-49f8-b062-7355c1f80764) this is used if there are two, three, or four distinct items for sale, and they all have a `wield_image` or `inventory_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 the `single_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) ![](https://gitea.your-land.de/attachments/c4fa7076-fd7f-479b-9796-e6d04daeb587) this is a wielditem drawtype used to represent a single item which is a node and has no `wield_image` or `inventory_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` or `inventory_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 an `upright_sprite` w/out clipping through it, and it causes less processor load minor optimizations i've thought of while writing this explanation: * [when rendering 4 entities, if 1 or 2 requires a wielditem drawtype and 2 or 3 can use a sprite drawtype, compose a quad upright sprite w/ those, w/ the wielditem(s) separate.](https://github.com/fluxionary/minetest-smartshop/issues/44) * [single_upright_sprite should be used when all sub-images are identical](https://github.com/fluxionary/minetest-smartshop/issues/45) ##### 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.
Member

i should provide images demonstrating all of the tedious details, maybe tomorrow, maybe it's too much work. poke me if you care.

i should provide images demonstrating all of the tedious details, maybe tomorrow, maybe it's too much work. poke me if you care.
flux added the
1. kind/documentation
4. step/at work
labels 2022-11-08 00:24:55 +01:00
flux added this to the flux's TODO list project 2022-11-08 00:25:00 +01:00
AliasAlreadyTaken was unassigned by flux 2022-11-08 00:25:07 +01:00
flux self-assigned this 2022-11-08 00:25:07 +01:00
flux added
5. result/fixed
and removed
4. step/at work
labels 2022-11-30 17:01:57 +01:00
flux removed this from the flux's TODO list project 2022-11-30 17:02:00 +01:00
flux removed their assignment 2022-11-30 17:02:05 +01:00
flux closed this issue 2022-11-30 17:02:10 +01:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: your-land/bugtracker#2956
No description provided.