basic builders' flight #3453

Closed
opened 2023-01-04 16:55:30 +00:00 by flux · 47 comments
Member

for 1.1.118 (#3401), we want builders' flight. this is a highly desired capability, but it needs a lot of consideration for balancing.

this issue is about creating an temporary approximation of builders' flight, that will try to provide a temporary solution until a proper status effect API can be implemented.

goals:

  • create a simple, stand-alone status effect which will grant players the "fly" privilege, so long as specific conditions are met
  • fly will only work within a player's protection area, with other restrictions TBD
  • builders fly will require use of a consumable item (TBD)
  • there will be a toggle-able HUD to display the remaining time, and warnings when the conditions aren't met

possibly there are other things i'm not thinking about. as there's not a current issue for this feature, i'm creating one for discussion.

for 1.1.118 (#3401), we want builders' flight. this is a highly desired capability, but it needs a lot of consideration for balancing. this issue is about creating an temporary approximation of builders' flight, that will try to provide a temporary solution until a proper status effect API can be implemented. goals: * create a simple, stand-alone status effect which will grant players the "fly" privilege, so long as specific conditions are met * fly will only work within a player's protection area, with other restrictions TBD * builders fly will require use of a consumable item (TBD) * there will be a toggle-able HUD to display the remaining time, and warnings when the conditions aren't met possibly there are other things i'm not thinking about. as there's not a current issue for this feature, i'm creating one for discussion.
flux added the
1. kind/enhancement
4. step/at work
labels 2023-01-04 16:55:30 +00:00
flux self-assigned this 2023-01-04 16:55:30 +00:00
flux added this to the flux's TODO list project 2023-01-04 16:55:31 +00:00
flux added the
4. step/discussion
label 2023-01-04 16:55:39 +00:00
Author
Member

question: should builders' flight persist between server crashes/restarts?

question: should builders' flight persist if a player logs off and logs back on?

question: should builders' flight persist between server crashes/restarts? question: should builders' flight persist if a player logs off and logs back on?
Author
Member

i'm imagining a situation where a player was flying, the server crashed, they rejoin, and then they fall to their death. not fun.

i'm imagining a situation where a player was flying, the server crashed, they rejoin, and then they fall to their death. not fun.
Member

if a player flies out of their area, they will receive a warning and fly will be revoked after 15(?) seconds.

Dangerous. Players who flew up high might get into panic mode and then fall down.

the item will grant fly for some fixed period of time (20 minutes?)

That's extremly short. For that, you'd probably be down to a steel ingot as payment.

question: should builders' flight persist between server crashes/restarts?
question: should builders' flight persist if a player logs off and logs back on?

Yes. Imagine the server crashing or the player having to log off while in flight. And then comming back and beeing high above the ground.

i'm imagining a situation where a player was flying, the server crashed, they rejoin, and then they fall to their death. not fun.

Aah. Should have read all comments first :-)

Do you know the beacons from Pandorabox? The beam there does not hurt but acts like a rope which you can climb up. And beacons can have the effect of granting fly withhin a range of 10-50m around them. If the player leaves the area by accident and in fly mode, he's moved back into the area so that nothing happens.

If we could get the beacon-fly-function from Pandorabox that'd be pretty helpful.

The player's area may not always be the optimal...range...for builders' flight. In some situations (Haven) it's too small. It helps with building, but the other important factor of flight - to be able to pull back and take a look at your creation from diffrent views - won't work.

In other situations the area might be quite big. Most of us add players to the entire city area. That as such is not a problem either - that way players will get a better overview, can plan better, and enjoy the landscape.

What I worry about more are Voice attacks. Fighting them with fly would be kind of unfair. Especially to the other players who came to help and are not registered locals.

Builders' flight might also be used to harvest crystals in caves. Perhaps places below say -128 ought to be excempt from builders' flight.

> if a player flies out of their area, they will receive a warning and fly will be revoked after 15(?) seconds. Dangerous. Players who flew up high might get into panic mode and then fall down. > the item will grant fly for some fixed period of time (20 minutes?) That's extremly short. For that, you'd probably be down to a steel ingot as payment. > question: should builders' flight persist between server crashes/restarts? > question: should builders' flight persist if a player logs off and logs back on? Yes. Imagine the server crashing or the player having to log off while in flight. And then comming back and beeing high above the ground. > i'm imagining a situation where a player was flying, the server crashed, they rejoin, and then they fall to their death. not fun. Aah. Should have read all comments first :-) Do you know the beacons from Pandorabox? The beam there does not hurt but acts like a rope which you can climb up. And beacons can have the effect of granting fly withhin a range of 10-50m around them. If the player leaves the area by accident and in fly mode, he's moved back into the area so that nothing happens. If we could get the beacon-fly-function from Pandorabox that'd be pretty helpful. The player's area may not always be the optimal...range...for builders' flight. In some situations (Haven) it's too small. It helps with building, but the other important factor of flight - to be able to pull back and take a look at your creation from diffrent views - won't work. In other situations the area might be quite big. Most of us add players to the entire city area. That as such is not a problem either - that way players will get a better overview, can plan better, and enjoy the landscape. What I worry about more are Voice attacks. Fighting them with fly would be kind of unfair. Especially to the other players who came to help and are not registered locals. Builders' flight might also be used to harvest crystals in caves. Perhaps places below say -128 ought to be excempt from builders' flight.
Member

Builders flight should be possible in areas, that belongs since a longer period of time to the player, to prevent a little bit against harvesting items somewhere and it should only work in own master areas, not in subarea.

For just to fly around and looking from above, I would like to have that little fairy from Arabellas playground. So visitors can enjoy the beauty of nice built cities from that angle. A vote may be necessary for this before.

Builders flight should be possible in areas, that belongs since a longer period of time to the player, to prevent a little bit against harvesting items somewhere and it should only work in own master areas, not in subarea. For just to fly around and looking from above, I would like to have that little fairy from Arabellas playground. So visitors can enjoy the beauty of nice built cities from that angle. A vote may be necessary for this before.
Member

That little fairy from Arabella is a good idea! That way visitors can be directed to particulary beautiful places without having to search for themshelves.

That little fairy from Arabella is a good idea! That way visitors can be directed to particulary beautiful places without having to search for themshelves.

I would suggest doing it similar to the crane mod.

Im gonna call it "flyprivblock"

  • no crafting recipe only available from admin shop for easier price balancing and removing later
  • start with a high price, you can always lower it with less complaints than raising it
  • grants fly in a fixed radius/cube around the flyprivblock, less problems with area borders and balances a bit between small and big city areas
  • if player leaves fly range send a warning + timer
  • if timer is up move player back into range, maybe even back above the flyprivblock
  • it should be time based but toggable so it doesnt feel wasted if you only needed it for 2mins but save also the flight time left to prevent cheating
  • HUD and sound based warning before it runs out
  • if player is still flying at the end tp player above the flyprivblock, to prevent fall damage
  • only placeable & usable in owner protected area older than X hours
  • diggable allows to move it if necessary especially in big areas
  • add particle effect to player while using it to prevent false positive cheatclient reports, something like the grappling hook rope between player and flyprivblock would match and not ruin screenshots in most cases
I would suggest doing it similar to the [crane mod](https://content.minetest.net/packages/joe7575/towercrane/). Im gonna call it "flyprivblock" - no crafting recipe only available from admin shop for easier price balancing and removing later - start with a high price, you can always lower it with less complaints than raising it - grants fly in a fixed radius/cube around the flyprivblock, less problems with area borders and balances a bit between small and big city areas - if player leaves fly range send a warning + timer - if timer is up move player back into range, maybe even back above the flyprivblock - it should be time based but toggable so it doesnt feel wasted if you only needed it for 2mins but save also the flight time left to prevent cheating - HUD and sound based warning before it runs out - if player is still flying at the end tp player above the flyprivblock, to prevent fall damage - only placeable & usable in owner protected area older than X hours - diggable allows to move it if necessary especially in big areas - add particle effect to player while using it to prevent false positive cheatclient reports, something like the [grappling hook rope](https://content.minetest.net/packages/doctor_ew/grappling_hook/) between player and flyprivblock would match and not ruin screenshots in most cases

Almost forgot

  • If its clear how YL devs want it to work copy it into an book, make an ingame vote and ask players for feedback books
Almost forgot - If its clear how YL devs want it to work copy it into an book, make an ingame vote and ask players for feedback books
Author
Member

Do you know the beacons from Pandorabox?
...
I would suggest doing it similar to the crane mod.
...
Im gonna call it "flyprivblock"

yes. see the discussion of on #2888 about tower cranes. overall, i dislike this mechanic as too restrictive - if i want to build a large tower, i want to be able to get all around it, and not worry about placing nodes in specific areas, the "flyprivblock" nodes getting in the way, or having trouble moving between different "flight areas". the whole idea of builders flight, imo, was that it let builders have freedom inside their own areas, and to keep them from flying in arbitrary areas.

no crafting recipe only available from admin shop for easier price balancing and removing later

i'd prefer it be craftable, so it can be part of the server economy.

What I worry about more are Voice attacks

i think that builders' flight should be globally disabled during events, the same way that using orbs of time currently is disabled. care will need to be taken to not drop players out of the sky in a rough manner when the voice attacks.

it should only work in own master areas, not in subarea.

i'm on the fence about this. i agree that sometimes this is desired, but sometimes not. i think such a limitation needs to be put on hold until we've got a better system for tagging areas and specifying callbacks for them.

For just to fly around and looking from above, I would like to have that little fairy from Arabellas playground.

for a similar idea, see #2862

it should be time based but toggable so it doesnt feel wasted if you only needed it for 2mins but save also the flight time left to prevent cheating

the fly priv is inherently toggle-able, but unfortunately there's no way to tell whether a player is actually using it.

this is one reason why i don't want to make the potion last too long - it then becomes too valuable to use for short periods.

add particle effect to player while using it

i like that :)

If its clear how YL devs want it to work copy it into an book, make an ingame vote and ask players for feedback books

i'd rather continue to work on the effect and discuss things here. later, we can install it on the test server, and invite other players to give feedback.


current limitations on builders' flight, which may be removed or modified after continued discussion:

  • the flight item is the ethereal flight potion, but with its functionality completely rewritten. the crafting recipe is left at the default for the moment.
  • flight time per potion is 20 minutes (the length of an in-game day). you can "top up" before you run out, but you max out at 20 minutes, so you don't benefit from drinking a bunch at once.
  • the remaining time only decreases while a player is logged in.
  • the remaining time persists across server restarts and crashes.
  • a player can fly in a slightly larger volume than their protected area (currently 5 nodes).
  • a player can only fly in an area that's at least 1 hour old
  • a player can only fly between y=-500 and y=500
  • if a player flies outside of the allowed area, they are returned to their last known good position, with a warning
  • when flight is disabled (e.g. player runs out of flight time), the player's physics are modified so that they glide safely to the ground, w/ little control over the path of their descent.
  • staff cannot drink flight potions, so that they don't accidentally get rid of their flight priv.
> Do you know the beacons from Pandorabox? > ... > I would suggest doing it similar to the crane mod. > ... > Im gonna call it "flyprivblock" yes. see the discussion of on #2888 about tower cranes. overall, i dislike this mechanic as too restrictive - if i want to build a large tower, i want to be able to get all around it, and not worry about placing nodes in specific areas, the "flyprivblock" nodes getting in the way, or having trouble moving between different "flight areas". the whole idea of builders flight, imo, was that it let builders have freedom inside their own areas, and to keep them from flying in arbitrary areas. > no crafting recipe only available from admin shop for easier price balancing and removing later i'd prefer it be craftable, so it can be part of the server economy. > What I worry about more are Voice attacks i think that builders' flight should be globally disabled during events, the same way that using orbs of time currently is disabled. care will need to be taken to not drop players out of the sky in a rough manner when the voice attacks. > it should only work in own master areas, not in subarea. i'm on the fence about this. i agree that sometimes this is desired, but sometimes not. i think such a limitation needs to be put on hold until we've got a better system for tagging areas and specifying callbacks for them. > For just to fly around and looking from above, I would like to have that little fairy from Arabellas playground. for a similar idea, see #2862 > it should be time based but toggable so it doesnt feel wasted if you only needed it for 2mins but save also the flight time left to prevent cheating the fly priv is inherently toggle-able, but unfortunately there's no way to tell whether a player is actually using it. this is one reason why i don't want to make the potion last too long - it then becomes too valuable to use for short periods. > add particle effect to player while using it i like that :) > If its clear how YL devs want it to work copy it into an book, make an ingame vote and ask players for feedback books i'd rather continue to work on the effect and discuss things here. later, we can install it on the test server, and invite other players to give feedback. -------------------- current limitations on builders' flight, which may be removed or modified after continued discussion: * the flight item is the ethereal flight potion, but with its functionality completely rewritten. the crafting recipe is left at the default for the moment. * flight time per potion is 20 minutes (the length of an in-game day). you can "top up" before you run out, but you max out at 20 minutes, so you don't benefit from drinking a bunch at once. * the remaining time only decreases while a player is logged in. * the remaining time persists across server restarts and crashes. * a player can fly in a slightly larger volume than their protected area (currently 5 nodes). * a player can only fly in an area that's at least 1 hour old * a player can only fly between y=-500 and y=500 * if a player flies outside of the allowed area, they are returned to their last known good position, with a warning * when flight is disabled (e.g. player runs out of flight time), the player's physics are modified so that they glide safely to the ground, w/ little control over the path of their descent. * staff cannot drink flight potions, so that they don't accidentally get rid of their flight priv.

Wow, so many ideas :D

Fo reference, this was the intial set of ideas for a builders flight mechanic:

Onetime use item, which allows player to fly under certain conditions

- flight only in exclusively owned area
- tied to area id (removing/moving/add subarea/... removes the connection)
- only one builders flight per person at the same time, no two areas
- no flight around factions and quest areas (need explanation, sudden development of AA missiles by goblins is rather unlikely)
- player in area check every 3 seconds, immediately losing fly priv when outside
- timebased (4320 played minutes VS 3 real life days)
- cost (either very expensive or only obtainable via quest)
- attention to toggles: using the item while builders flight is active must do nothing, neither use up the item nor suddenly turn of flight

Of course many of those ideas have drawbacks of their own:

"flight only in exclusively owned area" means only one builder can fly in an area if there are no other areas on the same place. One masterarea, no subareas. Means: If two builders want to cooperate, they need to decide on who flies and who doesn't.

DURATION:

Where I am entirely not certain is the duration. If we make it RL time based, people might feel forced to make the most of it, trying to squeeze in as much building into this time as possible, ignoring or rescheduling RL needs. If we make it ingame time based, people might want to avoid logging in to not use up their precious minutes. Creative works under a punchclock regime doesn't sit well with me, but so far I didn't find a suitable alternative.

From the ideas you presented:

question: should builders' flight persist between server crashes/restarts?

Yes. That's why it needs to wait for yl_settings, so we can alter it when a player is not online.

question: should builders' flight persist if a player logs off and logs back on?

Yes. Else a player might have a disconnect midair and then plummet to the ground.

Player moved back safely into the area when going outside

Builders' flight might also be used to harvest crystals in caves. Perhaps places below say -128 ought to be excempt from builders' flight.

This might put players at a disadvantage who build their base in the deep on purpose, like dwarves. (Ok, dwarves are not known to happily float anyways, but out of fairness they need to have the same chances)

Builders flight VS Voice

If we disable builders flight during Voice attacks, people could build a Voice detector. Imagine a player having builders flight enabled flying over a pressure plate with a craftable command block attached. As soon as Voice-attack starts, the player will fall and the craftable command block will do its thing.

Builders flight should be possible in areas, that belongs since a longer period of time to the player, to prevent a little bit against harvesting items somewhere and it should only work in own master areas, not in subarea.

Those are two ideas in one: Limit to areas that existed for a while, limit to masterareas. I think builders flight must be expensive enough so that people do feel a certain pressure not to use it for the sake of a few ores.

For just to fly around and looking from above, I would like to have that little fairy from Arabellas playground. So visitors can enjoy the beauty of nice built cities from that angle. A vote may be necessary for this before.
The player's area may not always be the optimal...range...for builders' flight. In some situations (Haven) it's too small. It helps with building, but the other important factor of flight - to be able to pull back and take a look at your creation from diffrent views - won't work.

Builders flight is not intended to solve a general flying/sightseeing problem. The fairy needs dangerous maptools blocks to work, I can't have that in a player city. maybe APercy's Airship Service could solve that.

flyprivblock

Regarding the flypriv BLOCK: I'd rather not have "technical" blocks like protectors or flyprivblocks.

grants fly in a fixed radius/cube around the flyprivblock, less problems with area borders and balances a bit between small and big city areas

Not tieing it to an area will result in people flying everywhere. That's a clear no. Having a fixed radius/cube could be a nice balancing mechanic between areas sizes, but defeats the purpose of a city.

HUD and sound based warning before it runs out
if player leaves fly range send a warning + timer

I like, we just need to pay attention to general UI - where do we place such information and can it be used for general timer+warning mechanics like area_ban

if player is still flying at the end tp player above the flyprivblock, to prevent fall damage

Hints a t a general problem. What do we do with afk players, when the timer runs out? If we let them fall, they will most liekly die. I'd like to avoid teleport and feather fall mechanics though, they can easily be abused. Next best option might be to send them to spawn or home, but that's also some autoteleport.

particle effects

Certainly a nice bonus :D

the whole idea of builders flight, imo, was that it let builders have freedom inside their own areas, and to keep them from flying in arbitrary areas.

This is the basic idea, yes.

The solution was meant to include triggering mechanics and resulting mechanics. Those are necessary not only for builders flight, but also for yl_quests and others. That's why I do not want a temporary or even hardcoded builders flight which can only be used on YL.

current limitations on builders' flight, which may be removed or modified after continued discussion:

I'm aware this is a much sought-after mechanic, but let's specify first and implement later. I don't want to waste valuable programming time on a thing that might turn out impossible.

the flight item is the ethereal flight potion, but with its functionality completely rewritten. the crafting recipe is left at the default for the moment.

If we use the ethereal flight potion, we depend on the funny ideas TenPlus1 keeps adding to their mods. That's why I'd prefer a different item. So far it only has an icon in yl_commons :P
Until we're certain about mechanics and reception, I'd prefer it to not have a crafting recipe.

flight time per potion is 20 minutes (the length of an in-game day). you can "top up" before you run out, but you max out at 20 minutes, so you don't benefit from drinking a bunch at once.

That may lead to accidental uses. Also, let's have the time configurable.

the remaining time only decreases while a player is logged in.

That's up to debate and is one of the major questions. See the DURATION paragraph

the remaining time persists across server restarts and crashes.

Definite yes.

a player can fly in a slightly larger volume than their protected area (currently 5 nodes).

No. If they can still fly outside their protection, they do not have any indication regarding the border. +5 blocks is much harder to tell than the area border.

a player can only fly in an area that's at least 1 hour old

This requires a change to areas: record creation date. Such a change is planned anyways, other mechanics and some staff tasks will also benefit from it.

a player can only fly between y=-500 and y=500

This might put players at a disadvantage who build their base in the deep on purpose, like dwarves. (Ok, dwarves are not known to happily float anyways, but out of fairness they need to have the same chances) Same goes for people who build on mountains.

if a player flies outside of the allowed area, they are returned to their last known good position, with a warning

This and the next proposal revolve around the question, whether builders flight should be a dangerous tool which needs to be used with caution or a comfortable tool moving YL in the direction of creative servers.

I very much prefer the former, in the intial draft a player would get a warning and start falling immediately. If he managed to wriggle back into his area, flight would hopefully return in time and he'd have to take measures to not hit the ground at terminal velocity.

However lag may have a player accidentally fly out of their area. While I prefer survival over creative, we must give players a chance to correct when something is wrong.

when flight is disabled (e.g. player runs out of flight time), the player's physics are modified so that they glide safely to the ground, w/ little control over the path of their descent.

Not in favour, but not a clear "no" yet. We don't want to add gliders/feather fall/... with builders flight.

staff cannot drink flight potions, so that they don't accidentally get rid of their flight priv.

Thanks. That's a good one, I know of at least one who'd occasionally die if not.

Wow, so many ideas :D Fo reference, this was the intial set of ideas for a builders flight mechanic: ``` Onetime use item, which allows player to fly under certain conditions - flight only in exclusively owned area - tied to area id (removing/moving/add subarea/... removes the connection) - only one builders flight per person at the same time, no two areas - no flight around factions and quest areas (need explanation, sudden development of AA missiles by goblins is rather unlikely) - player in area check every 3 seconds, immediately losing fly priv when outside - timebased (4320 played minutes VS 3 real life days) - cost (either very expensive or only obtainable via quest) - attention to toggles: using the item while builders flight is active must do nothing, neither use up the item nor suddenly turn of flight ``` Of course many of those ideas have drawbacks of their own: "flight only in exclusively owned area" means only one builder can fly in an area if there are no other areas on the same place. One masterarea, no subareas. Means: If two builders want to cooperate, they need to decide on who flies and who doesn't. DURATION: Where I am entirely not certain is the duration. If we make it RL time based, people might feel forced to make the most of it, trying to squeeze in as much building into this time as possible, ignoring or rescheduling RL needs. If we make it ingame time based, people might want to avoid logging in to not use up their precious minutes. Creative works under a punchclock regime doesn't sit well with me, but so far I didn't find a suitable alternative. From the ideas you presented: > question: should builders' flight persist between server crashes/restarts? Yes. That's why it needs to wait for yl_settings, so we can alter it when a player is not online. > question: should builders' flight persist if a player logs off and logs back on? Yes. Else a player might have a disconnect midair and then plummet to the ground. > Player moved back safely into the area when going outside > Builders' flight might also be used to harvest crystals in caves. Perhaps places below say -128 ought to be excempt from builders' flight. This might put players at a disadvantage who build their base in the deep on purpose, like dwarves. (Ok, dwarves are not known to happily float anyways, but out of fairness they need to have the same chances) > Builders flight VS Voice If we disable builders flight during Voice attacks, people could build a Voice detector. Imagine a player having builders flight enabled flying over a pressure plate with a craftable command block attached. As soon as Voice-attack starts, the player will fall and the craftable command block will do its thing. > Builders flight should be possible in areas, that belongs since a longer period of time to the player, to prevent a little bit against harvesting items somewhere and it should only work in own master areas, not in subarea. Those are two ideas in one: Limit to areas that existed for a while, limit to masterareas. I think builders flight must be expensive enough so that people do feel a certain pressure not to use it for the sake of a few ores. > For just to fly around and looking from above, I would like to have that little fairy from Arabellas playground. So visitors can enjoy the beauty of nice built cities from that angle. A vote may be necessary for this before. > The player's area may not always be the optimal...range...for builders' flight. In some situations (Haven) it's too small. It helps with building, but the other important factor of flight - to be able to pull back and take a look at your creation from diffrent views - won't work. Builders flight is not intended to solve a general flying/sightseeing problem. The fairy needs dangerous maptools blocks to work, I can't have that in a player city. maybe APercy's Airship Service could solve that. > flyprivblock Regarding the flypriv BLOCK: I'd rather not have "technical" blocks like protectors or flyprivblocks. > grants fly in a fixed radius/cube around the flyprivblock, less problems with area borders and balances a bit between small and big city areas Not tieing it to an area will result in people flying everywhere. That's a clear no. Having a fixed radius/cube could be a nice balancing mechanic between areas sizes, but defeats the purpose of a city. > HUD and sound based warning before it runs out > if player leaves fly range send a warning + timer I like, we just need to pay attention to general UI - where do we place such information and can it be used for general timer+warning mechanics like area_ban > if player is still flying at the end tp player above the flyprivblock, to prevent fall damage Hints a t a general problem. What do we do with afk players, when the timer runs out? If we let them fall, they will most liekly die. I'd like to avoid teleport and feather fall mechanics though, they can easily be abused. Next best option might be to send them to spawn or home, but that's also some autoteleport. > particle effects Certainly a nice bonus :D > the whole idea of builders flight, imo, was that it let builders have freedom inside their own areas, and to keep them from flying in arbitrary areas. This is the basic idea, yes. The solution was meant to include triggering mechanics and resulting mechanics. Those are necessary not only for builders flight, but also for yl_quests and others. That's why I do not want a temporary or even hardcoded builders flight which can only be used on YL. > current limitations on builders' flight, which may be removed or modified after continued discussion: I'm aware this is a much sought-after mechanic, but let's specify first and implement later. I don't want to waste valuable programming time on a thing that might turn out impossible. > the flight item is the ethereal flight potion, but with its functionality completely rewritten. the crafting recipe is left at the default for the moment. If we use the ethereal flight potion, we depend on the funny ideas TenPlus1 keeps adding to their mods. That's why I'd prefer a different item. So far it only has an icon in yl_commons :P Until we're certain about mechanics and reception, I'd prefer it to not have a crafting recipe. > flight time per potion is 20 minutes (the length of an in-game day). you can "top up" before you run out, but you max out at 20 minutes, so you don't benefit from drinking a bunch at once. That may lead to accidental uses. Also, let's have the time configurable. > the remaining time only decreases while a player is logged in. That's up to debate and is one of the major questions. See the DURATION paragraph > the remaining time persists across server restarts and crashes. Definite yes. > a player can fly in a slightly larger volume than their protected area (currently 5 nodes). No. If they can still fly outside their protection, they do not have any indication regarding the border. +5 blocks is much harder to tell than the area border. > a player can only fly in an area that's at least 1 hour old This requires a change to areas: record creation date. Such a change is planned anyways, other mechanics and some staff tasks will also benefit from it. > a player can only fly between y=-500 and y=500 This might put players at a disadvantage who build their base in the deep on purpose, like dwarves. (Ok, dwarves are not known to happily float anyways, but out of fairness they need to have the same chances) Same goes for people who build on mountains. > if a player flies outside of the allowed area, they are returned to their last known good position, with a warning This and the next proposal revolve around the question, whether builders flight should be a dangerous tool which needs to be used with caution or a comfortable tool moving YL in the direction of creative servers. I very much prefer the former, in the intial draft a player would get a warning and start falling immediately. If he managed to wriggle back into his area, flight would hopefully return in time and he'd have to take measures to not hit the ground at terminal velocity. However lag may have a player accidentally fly out of their area. While I prefer survival over creative, we must give players a chance to correct when something is wrong. > when flight is disabled (e.g. player runs out of flight time), the player's physics are modified so that they glide safely to the ground, w/ little control over the path of their descent. Not in favour, but not a clear "no" yet. We don't want to add gliders/feather fall/... with builders flight. > staff cannot drink flight potions, so that they don't accidentally get rid of their flight priv. Thanks. That's a good one, I know of at least one who'd occasionally die if not.

Do you know the beacons from Pandorabox?
...
I would suggest doing it similar to the crane mod.
...
Im gonna call it "flyprivblock"

yes. see the discussion of on #2888 about tower cranes. overall, i dislike this mechanic as too restrictive - if i want to build a large tower, i want to be able to get all around it, and not worry about placing nodes in specific areas, the "flyprivblock" nodes getting in the way, or having trouble moving between different "flight areas". the whole idea of builders flight, imo, was that it let builders have freedom inside their own areas, and to keep them from flying in arbitrary areas.

Sure its restrictive but the area approach also.
Build that large tower in a corner of an area and you can only fly freely on the 2 sides inside the area, on the 2 outside you can´t or only in the suggested buffer zone(5 nodes by your suggestion). Gets even more restrictive if you build that tower across area borders.
In the end players will try to avoid that by always using the max area size instead of protecting what they need and soon after you get more and more requests for area merging and city areas etc.

With a flyprivblock you wouldn´t have that corner or border problem and how restrictive it is only depends on the range granted which is easier to balance globally and also easier to understand for players.

no crafting recipe only available from admin shop for easier price balancing and removing later

i'd prefer it be craftable, so it can be part of the server economy.

the temporary version should be non craftable, the final builders flight should be craftable.

What I worry about more are Voice attacks

i think that builders' flight should be globally disabled during events, the same way that using orbs of time currently is disabled. care will need to be taken to not drop players out of the sky in a rough manner when the voice attacks.

globally is way too much, doesnt make sense that a player in 10k distance to Voice has to stop building and wait till an attack is over especially if even most small attacks take around 15min.

it should be time based but toggable so it doesnt feel wasted if you only needed it for 2mins but save also the flight time left to prevent cheating

the fly priv is inherently toggle-able, but unfortunately there's no way to tell whether a player is actually using it.

But that the player is flying.

If its clear how YL devs want it to work copy it into an book, make an ingame vote and ask players for feedback books

i'd rather continue to work on the effect and discuss things here. later, we can install it on the test server, and invite other players to give feedback.

I didn´t say stop discussing here just that as soon as YL devs know how they want to do it they should get feedback from ingame. Not all players comment or read on gitea/discord/irc.

> > Do you know the beacons from Pandorabox? > > ... > > I would suggest doing it similar to the crane mod. > > ... > > Im gonna call it "flyprivblock" > > yes. see the discussion of on #2888 about tower cranes. overall, i dislike this mechanic as too restrictive - if i want to build a large tower, i want to be able to get all around it, and not worry about placing nodes in specific areas, the "flyprivblock" nodes getting in the way, or having trouble moving between different "flight areas". the whole idea of builders flight, imo, was that it let builders have freedom inside their own areas, and to keep them from flying in arbitrary areas. Sure its restrictive but the area approach also. Build that large tower in a corner of an area and you can only fly freely on the 2 sides inside the area, on the 2 outside you can´t or only in the suggested buffer zone(5 nodes by your suggestion). Gets even more restrictive if you build that tower across area borders. In the end players will try to avoid that by always using the max area size instead of protecting what they need and soon after you get more and more requests for area merging and city areas etc. With a flyprivblock you wouldn´t have that corner or border problem and how restrictive it is only depends on the range granted which is easier to balance globally and also easier to understand for players. > > no crafting recipe only available from admin shop for easier price balancing and removing later > > i'd prefer it be craftable, so it can be part of the server economy. the temporary version should be non craftable, the final builders flight should be craftable. > > What I worry about more are Voice attacks > > i think that builders' flight should be globally disabled during events, the same way that using orbs of time currently is disabled. care will need to be taken to not drop players out of the sky in a rough manner when the voice attacks. globally is way too much, doesnt make sense that a player in 10k distance to Voice has to stop building and wait till an attack is over especially if even most small attacks take around 15min. > > it should be time based but toggable so it doesnt feel wasted if you only needed it for 2mins but save also the flight time left to prevent cheating > > the fly priv is inherently toggle-able, but unfortunately there's no way to tell whether a player is actually using it. But that the player is flying. > > If its clear how YL devs want it to work copy it into an book, make an ingame vote and ask players for feedback books > > i'd rather continue to work on the effect and discuss things here. later, we can install it on the test server, and invite other players to give feedback. I didn´t say stop discussing here just that as soon as YL devs know how they want to do it they should get feedback from ingame. Not all players comment or read on gitea/discord/irc.

i didn't read everything here but...some thoughts:

  • add 'builder' as class with
    • fly ability in own area but no time limit (stupid idea)
    • more durable & efficient tools (+50% ?)
    • less hunger from crafting (-75% ?)
i didn't read everything here but...some thoughts: - add 'builder' as class with * fly ability in own area but no time limit (stupid idea) * more durable & efficient tools (+50% ?) * less hunger from crafting (-75% ?)

grants fly in a fixed radius/cube around the flyprivblock, less problems with area borders and balances a bit between small and big city areas

Not tieing it to an area will result in people flying everywhere. That's a clear no.

You missed the context, placing the flyprivblock would be limited to an area which is X hours old and owned by the same player, which then allows the player to fly in a fixed range(either radius or cube) around that flyprivblock.

Having a fixed radius/cube could be a nice balancing mechanic between areas sizes, but defeats the purpose of a city.

@Alias what I don´t understand is why City owners should be able to fly through their whole city while players with a normal max sized area should start falling right away if they cross the area border just a bit because you dont want them to have atleast a tiny buffer around the area.

> > grants fly in a fixed radius/cube around the flyprivblock, less problems with area borders and balances a bit between small and big city areas > > Not tieing it to an area will result in people flying everywhere. That's a clear no. You missed the context, placing the flyprivblock would be limited to an area which is X hours old and owned by the same player, which then allows the player to fly in a fixed range(either radius or cube) around that flyprivblock. > Having a fixed radius/cube could be a nice balancing mechanic between areas sizes, but defeats the purpose of a city. @Alias what I don´t understand is why City owners should be able to fly through their whole city while players with a normal max sized area should start falling right away if they cross the area border just a bit because you dont want them to have atleast a tiny buffer around the area.

grants fly in a fixed radius/cube around the flyprivblock, less problems with area borders and balances a bit between small and big city areas

Not tieing it to an area will result in people flying everywhere. That's a clear no.

You missed the context, placing the flyprivblock would be limited to an area which is X hours old and owned by the same player, which then allows the player to fly in a fixed range(either radius or cube) around that flyprivblock.

I see. Even with the explanation though it sounds like we're creating a subarea of an already existing and query-able area, which results in people having to use builders flight in the center of their area if they want to fly in all of it.

Having a fixed radius/cube could be a nice balancing mechanic between areas sizes, but defeats the purpose of a city.

@Alias what I don´t understand is why City owners should be able to fly through their whole city while players with a normal max sized area should start falling right away if they cross the area border just a bit because you dont want them to have atleast a tiny buffer around the area.

Good point. Even my "all city" plan is pointless when a city consists of more than one area. Or Builders who didn't ask staff to merge their private areas are also at a disadvantage.

The idea of using areas is that the mechanic is well-known, players can adapt to the borders. This +5 grace limit sounds nice, but either needs to be visualized additonally to the areas or the player must guess when they're out. Areas already display when someone is out.

> > > grants fly in a fixed radius/cube around the flyprivblock, less problems with area borders and balances a bit between small and big city areas > > > > Not tieing it to an area will result in people flying everywhere. That's a clear no. > > You missed the context, placing the flyprivblock would be limited to an area which is X hours old and owned by the same player, which then allows the player to fly in a fixed range(either radius or cube) around that flyprivblock. I see. Even with the explanation though it sounds like we're creating a subarea of an already existing and query-able area, which results in people having to use builders flight in the center of their area if they want to fly in all of it. > > Having a fixed radius/cube could be a nice balancing mechanic between areas sizes, but defeats the purpose of a city. > > @Alias what I don´t understand is why City owners should be able to fly through their whole city while players with a normal max sized area should start falling right away if they cross the area border just a bit because you dont want them to have atleast a tiny buffer around the area. Good point. Even my "all city" plan is pointless when a city consists of more than one area. Or Builders who didn't ask staff to merge their private areas are also at a disadvantage. The idea of using areas is that the mechanic is well-known, players can adapt to the borders. This +5 grace limit sounds nice, but either needs to be visualized additonally to the areas or the player must guess when they're out. Areas already display when someone is out.
Member

the flight item is the ethereal flight potion, but with its functionality completely rewritten. the crafting recipe is left at the default for the moment.

That potion is pretty expensive iirc.

flight time per potion is 20 minutes (the length of an in-game day). you can "top up" before you run out, but you max out at 20 minutes, so you don't benefit from drinking a bunch at once.

That's almost no time at all when building.

"flight only in exclusively owned area" means only one builder can fly in an area if there are no other areas on the same place. One masterarea, no subareas. Means: If two builders want to cooperate, they need to decide on who flies and who doesn't.

Rather annoying, yes. I see no reason for this limitation.

This might put players at a disadvantage who build their base in the deep on purpose, like dwarves. (Ok, dwarves are not known to happily float anyways, but out of fairness they need to have the same chances)

Down to -500 ought to be enough to cover the needs of Dwarves as well. Granted, homes in caverealms caves would be difficult..but then, I havn't really seen a good working town in one so far either. They're too big.

Regarding the flypriv BLOCK: I'd rather not have "technical" blocks like protectors or flyprivblocks.

They have the advantage of beeing very visible and manually placed by the player ingame. Those blocks may facilitate handling builders' flight for many players.

I very much prefer the former, in the intial draft a player would get a warning and start falling immediately. If he managed to wriggle back into his area, flight would hopefully return in time and he'd have to take measures to not hit the ground at terminal velocity.

Hmm. No. This very much sounds like the intention to murder some players and getting away with it. Just play a bit with the tower crane. Especially with small plots it's easy to accidentally leave the range of the own area. What you suggest would make the feature usesless.

add 'builder' as class with
fly ability in own area but no time limit (stupid idea)
more durable & efficient tools (+50% ?)
less hunger from crafting (-75% ?)

Also a nice idea to tie it to a special class. But which other classes would be there? And: We want players to build nicely (and more). To not have members of other classes be able to do so would be counterproductive.

Also, tools are already good enough. Especially when building, a diamond pick is quite fine, and tools last much longer than when gathering ressources.

Hunger..exists, but then...we do need a sink for all that farmed food...

Perhaps switching...abilities...depending on what the player currently does could help more in this case? I.e. when building and using builders' flight, there's little reason to fight monsters. It's not entirely zero as there are annoying ghosts around that occasionally need a tap, but those encounters are rare.

So how about: No XP (or even negative ones!) and/or drops from killing monsters while using builders' flight? That'd limit abuse while fighting voice troups.

There might also be a special fight mode in which placing/digging blocks/crafting doesn't give any XP (or negative XP). There's usually limited need to build when fighting voice troups, and only a few blocks are sometimes placed for prisons, lava, getting to the focus etc. Fighting against monsters might yield a bit (!) - maybe 5-10% - more XP in such situations.

That of course requires that players are able to turn builders' flight and fight mode on and off.

It might be tempting to use special armor for builders's flight, but...even while flying and building, there are situations when it's necessary to fight hostile mobs that invaded your area from the outside.

Perhaps Alias' wishes for restricting the flight strictly to the player's area comes from the fear that the player otherwise might invade his neighbours' territory. I don't think that's a big problem in general...nothing worth sacrificing facilitating building for.

> the flight item is the ethereal flight potion, but with its functionality completely rewritten. the crafting recipe is left at the default for the moment. That potion is pretty expensive iirc. > flight time per potion is 20 minutes (the length of an in-game day). you can "top up" before you run out, but you max out at 20 minutes, so you don't benefit from drinking a bunch at once. That's almost no time at all when building. > "flight only in exclusively owned area" means only one builder can fly in an area if there are no other areas on the same place. One masterarea, no subareas. Means: If two builders want to cooperate, they need to decide on who flies and who doesn't. Rather annoying, yes. I see no reason for this limitation. > This might put players at a disadvantage who build their base in the deep on purpose, like dwarves. (Ok, dwarves are not known to happily float anyways, but out of fairness they need to have the same chances) Down to -500 ought to be enough to cover the needs of Dwarves as well. Granted, homes in caverealms caves would be difficult..but then, I havn't really seen a good working town in one so far either. They're too big. > Regarding the flypriv BLOCK: I'd rather not have "technical" blocks like protectors or flyprivblocks. They have the advantage of beeing very visible and manually placed by the player ingame. Those blocks may facilitate handling builders' flight for many players. > I very much prefer the former, in the intial draft a player would get a warning and start falling immediately. If he managed to wriggle back into his area, flight would hopefully return in time and he'd have to take measures to not hit the ground at terminal velocity. Hmm. No. This very much sounds like the intention to murder some players and getting away with it. Just play a bit with the tower crane. Especially with small plots it's easy to accidentally leave the range of the own area. What you suggest would make the feature usesless. > add 'builder' as class with > fly ability in own area but no time limit (stupid idea) > more durable & efficient tools (+50% ?) > less hunger from crafting (-75% ?) Also a nice idea to tie it to a special class. But which other classes would be there? And: We want players to build nicely (and more). To not have members of other classes be able to do so would be counterproductive. Also, tools are already good enough. Especially when building, a diamond pick is quite fine, and tools last much longer than when gathering ressources. Hunger..exists, but then...we do need a sink for all that farmed food... Perhaps switching...abilities...depending on what the player currently does could help more in this case? I.e. when building and using builders' flight, there's little reason to fight monsters. It's not entirely zero as there are annoying ghosts around that occasionally need a tap, but those encounters are rare. So how about: No XP (or even negative ones!) and/or drops from killing monsters while using builders' flight? That'd limit abuse while fighting voice troups. There might also be a special fight mode in which placing/digging blocks/crafting doesn't give any XP (or negative XP). There's usually limited need to build when fighting voice troups, and only a few blocks are sometimes placed for prisons, lava, getting to the focus etc. Fighting against monsters might yield a bit (!) - maybe 5-10% - more XP in such situations. That of course requires that players are able to turn builders' flight and fight mode on and off. It might be tempting to use special armor for builders's flight, but...even while flying and building, there are situations when it's necessary to fight hostile mobs that invaded your area from the outside. Perhaps Alias' wishes for restricting the flight strictly to the player's area comes from the fear that the player otherwise might invade his neighbours' territory. I don't think that's a big problem in general...nothing worth sacrificing facilitating building for.

grants fly in a fixed radius/cube around the flyprivblock, less problems with area borders and balances a bit between small and big city areas

Not tieing it to an area will result in people flying everywhere. That's a clear no.

You missed the context, placing the flyprivblock would be limited to an area which is X hours old and owned by the same player, which then allows the player to fly in a fixed range(either radius or cube) around that flyprivblock.

I see. Even with the explanation though it sounds like we're creating a subarea of an already existing and query-able area, which results in people having to use builders flight in the center of their area if they want to fly in all of it.

the flyprivblock wouldn´t create any area thats why I tried to avoid that word and used range/radius/cube etc 😉
I think an example might be the easiest way to explain it with some dummy values.

Example
A player named "Dumbo" wants to build a tower so he buys a flyprivblock.
After that he returns to his home area at 0,0,0 which covers -32,0,-32->+32,+64,+32 that was created a RL week ago.
He can´t place the flyprivblock in unprotected or in an area protected by someone else, only in an area owned by him that is atleast 1 RL day old. But inside his area he can place it wherever he likes and it allows him to fly for 30mins in a 20x20x20 cube around the flyprivblock, if he leaves that "flycube" he gets a warning with a short timer and after the time is up he gets tped back to the flyprivblock.
So Dumbo places his flyprivblock at 10,1,10(flycube=0,-9,0->20,11,20) and activates it, after 10mins he is done with the tower base and deactivates it with 20mins left.
Now Dumbo digs that flyprivblock and places it on the next tower level at 10,11,10(flycube=0,1,0->20,21,20), he builds the next tower level in 14mins and deactivates the flyprivblock with 6mins left.
Dumbo moves the flyprivblock again 10 nodes up to build the second level and activates it, after 1min he gets a warning the he has only 5mins left and again at 2min and 1min left.
In the last minute he gets a countdown HUD displayed but he wants to finish so he just ignores it. Because he is still flying he gets tped back to above the flyprivblock.
He digs the flyprivblock but because it ran out of time it just deletes itself and he has to get a new one to finish his tower

> > > > grants fly in a fixed radius/cube around the flyprivblock, less problems with area borders and balances a bit between small and big city areas > > > > > > Not tieing it to an area will result in people flying everywhere. That's a clear no. > > > > You missed the context, placing the flyprivblock would be limited to an area which is X hours old and owned by the same player, which then allows the player to fly in a fixed range(either radius or cube) around that flyprivblock. > > I see. Even with the explanation though it sounds like we're creating a subarea of an already existing and query-able area, which results in people having to use builders flight in the center of their area if they want to fly in all of it. the flyprivblock wouldn´t create any area thats why I tried to avoid that word and used range/radius/cube etc 😉 I think an example might be the easiest way to explain it with some dummy values. ***Example*** A player named "Dumbo" wants to build a tower so he buys a flyprivblock. After that he returns to his home area at 0,0,0 which covers -32,0,-32->+32,+64,+32 that was created a RL week ago. He can´t place the flyprivblock in unprotected or in an area protected by someone else, only in an area owned by him that is atleast 1 RL day old. But inside his area he can place it wherever he likes and it allows him to fly for 30mins in a 20x20x20 cube around the flyprivblock, if he leaves that "flycube" he gets a warning with a short timer and after the time is up he gets tped back to the flyprivblock. So Dumbo places his flyprivblock at 10,1,10(flycube=0,-9,0->20,11,20) and activates it, after 10mins he is done with the tower base and deactivates it with 20mins left. Now Dumbo digs that flyprivblock and places it on the next tower level at 10,11,10(flycube=0,1,0->20,21,20), he builds the next tower level in 14mins and deactivates the flyprivblock with 6mins left. Dumbo moves the flyprivblock again 10 nodes up to build the second level and activates it, after 1min he gets a warning the he has only 5mins left and again at 2min and 1min left. In the last minute he gets a countdown HUD displayed but he wants to finish so he just ignores it. Because he is still flying he gets tped back to above the flyprivblock. He digs the flyprivblock but because it ran out of time it just deletes itself and he has to get a new one to finish his tower
Author
Member

I do not want a temporary or even hardcoded builders flight which can only be used on YL.

hm. if we don't create a temporary solution, how will this ever be ready for 1.1.118? that will require finishing yl_settings and yl_roles, and doing yl_statuseffects properly. i'm hoping we can get something going in the short-term that will allow me to finish some of my builds which are hard to get right cuz it's hard to see them from the right angle (and also, tall towers on top of a mountain)

yl_settings

currently, it's using mod_storage. i know this isn't ideal, as it makes the data effectively unreachable w/out a proper API, but i'm also coding an API. also, it'll be trivial to swap out the underlying storage layer for yl_settings when that's ready.

in the intial draft a player would get a warning and start falling immediately.

got it, builders flight should be dangerous, i was designing it mostly around the wants of a player like Sokomine, who dislikes sudden unexpected death. i'll refrain from implementing (most of) the safety features for the moment.

DURATION:

got it, builders flight is meant to be a long-term (3 IRL days) temporary ability, not a short-term (20 minutes) one. i still think the counter shouldn't tick down while the player is not logged in, but i'm open to either situation, particularly w/ the understanding that builders flight is dangerous.

If we disable builders flight during Voice attacks, people could build a Voice detector.
...
doesnt make sense that a player in 10k distance to Voice has to stop building

if events had a locus (or several), we could prevent builders flight w/in e.g. 1000 nodes of the locus, and not affect unrelated players.

they do not have any indication regarding the border

i could easily implement something that makes the edge of an area "shimmer" when a player is close to it. this might use an entity similar to the worldedit area borders, or like the node-based visualization of the highly protected nodes on Blocky Survival. there's also just the current areas HUD. however, none of these solutions work well w/ lag

+5 blocks is much harder to tell than the area border.

harder programmatically, or for the player? in my proposal, i was originally trying to avoid a player accidentally falling to their death for any reason. it sounds like some amount of danger is intended, so let's forget that constraint. it certainly will be harder for a player to tell if they are exactly 6 nodes outside a protection area vs. inside the area, given the ares HUD. however, that HUD is affected by lag. the "shimmering border" mentioned above could either be at the protection boundary, 1 node outside of it, or 5 nodes outside of it, there's no added complexity there. also, it's trivial to check whether a player is 5 nodes outside a protection area, w/out introducing any programmatic complexity. minetest's AreaStore allows querying for intersecting areas as easily as querying for areas at a specific node position, and the areas mod makes use of AreaStore (more or less, it also keeps a lot of redundant data around for some reason, but that's tangential). the algorithmic and computational complexity of the queries are also essentially the same, there's no reason to avoid doing such checks on such grounds.

only one builder can fly in an area if there are no other areas on the same place. One masterarea, no subareas.

this is the the thing i dislike the most about Alias's proposal. i very much want to be able to use builders flight in my area w/out evicting everyone else from my city. i also want to allow someone like granum (who has disappeared, but whatever) to build in my area using builders' flight. if i want to share my area w/ others, i shouldn't be prevented from flying.

This requires a change to areas: record creation date.

mods are free to add their own metadata to protection areas. my ad-hoc builders-flight implementation overrides relevant parts of the areas API to record a "last modified" time. my code declares an area as "old enough" if the metadata is missing, or if it's present and is for an old enough date. players could cheat the system for the first hour the mod is installed, but not effectively.

> I do not want a temporary or even hardcoded builders flight which can only be used on YL. hm. if we don't create a temporary solution, how will this ever be ready for 1.1.118? that will require finishing yl_settings and yl_roles, and doing yl_statuseffects properly. i'm hoping we can get something going in the short-term that will allow me to finish some of my builds which are hard to get right cuz it's hard to see them from the right angle (and also, tall towers on top of a mountain) > yl_settings currently, it's using mod_storage. i know this isn't ideal, as it makes the data effectively unreachable w/out a proper API, but i'm also coding an API. also, it'll be trivial to swap out the underlying storage layer for yl_settings when that's ready. > in the intial draft a player would get a warning and start falling immediately. got it, builders flight should be dangerous, i was designing it mostly around the wants of a player like Sokomine, who dislikes sudden unexpected death. i'll refrain from implementing (most of) the safety features for the moment. > DURATION: got it, builders flight is meant to be a long-term (3 IRL days) temporary ability, not a short-term (20 minutes) one. i still think the counter shouldn't tick down while the player is not logged in, but i'm open to either situation, particularly w/ the understanding that builders flight is dangerous. > If we disable builders flight during Voice attacks, people could build a Voice detector. > ... > doesnt make sense that a player in 10k distance to Voice has to stop building if events had a locus (or several), we could prevent builders flight w/in e.g. 1000 nodes of the locus, and not affect unrelated players. > they do not have any indication regarding the border i could easily implement something that makes the edge of an area "shimmer" when a player is close to it. this might use an entity similar to the worldedit area borders, or like the node-based visualization of the [highly protected nodes](https://github.com/BlockySurvival/bls_custom/blob/master/custom_items/highly_protected_node.lua) on Blocky Survival. there's also just the current areas HUD. however, none of these solutions work well w/ lag > +5 blocks is much harder to tell than the area border. harder programmatically, or for the player? in my proposal, i was originally trying to avoid a player accidentally falling to their death for any reason. it sounds like some amount of danger is intended, so let's forget that constraint. it certainly will be harder for a player to tell if they are exactly 6 nodes outside a protection area vs. inside the area, given the ares HUD. however, that HUD is affected by lag. the "shimmering border" mentioned above could either be at the protection boundary, 1 node outside of it, or 5 nodes outside of it, there's no added complexity there. also, it's trivial to check whether a player is 5 nodes outside a protection area, w/out introducing any programmatic complexity. minetest's AreaStore [allows querying for intersecting areas](https://github.com/minetest/minetest/blob/d603619ad3cc0e5f7ac942e41469462be43e2f5d/doc/lua_api.txt#L6691-L6696) as easily as querying for areas at a specific node position, and the areas mod makes use of AreaStore (more or less, it also keeps a lot of redundant data around for some reason, but that's tangential). the algorithmic and computational complexity of the queries are also essentially the same, there's no reason to avoid doing such checks on such grounds. > only one builder can fly in an area if there are no other areas on the same place. One masterarea, no subareas. this is the the thing i dislike the most about Alias's proposal. i very much want to be able to use builders flight in my area w/out evicting everyone else from my city. i also want to allow someone like granum (who has disappeared, but whatever) to build in my area using builders' flight. if i want to share my area w/ others, i shouldn't be prevented from flying. > This requires a change to areas: record creation date. mods are free to add their own metadata to protection areas. my ad-hoc builders-flight implementation overrides relevant parts of the areas API to record a "last modified" time. my code declares an area as "old enough" if the metadata is missing, or if it's present and is for an old enough date. players could cheat the system for the first hour the mod is installed, but not effectively.
Author
Member

@AliasAlreadyTaken what to do about accounts that have the "fly" priv, but which are not staff? here is a list:

  • 9T9
  • Admin2
  • bluattire
  • Drag-YT
  • Farming
  • Haven
  • Ina_1
  • Ivanhoe
  • Magic
  • Maravillosa
  • Opensourcegamaing
  • Plaetzchen
  • Queenfire234312
  • Road
  • set
  • SloMo
  • Sokomine3
  • Xonon
@AliasAlreadyTaken what to do about accounts that have the "fly" priv, but which are not staff? here is a list: * 9T9 * Admin2 * bluattire * Drag-YT * Farming * Haven * Ina_1 * Ivanhoe * Magic * Maravillosa * Opensourcegamaing * Plaetzchen * Queenfire234312 * Road * set * SloMo * Sokomine3 * Xonon
Author
Member

a problem w/ the idea of disabling flight near a voice attack - if the voice attacks an area, nearby players may unexpectedly fall from the sky.

a problem w/ the idea of disabling flight near a voice attack - if the voice attacks an area, nearby players may unexpectedly fall from the sky.
Author
Member

i've created a PR w/ the work i've done so far: your-land/yl_statuseffects#1

i've created a PR w/ the work i've done so far: https://gitea.your-land.de/your-land/yl_statuseffects/pulls/1

Cool! I switched to branch builders_flight for testing purposes on the testserver.

On another note: many of the people who still have fly priv shouldn't. There's no way we can give people NOT the real fly priv and still achieve flight?

Cool! I switched to branch builders_flight for testing purposes on the testserver. On another note: many of the people who still have fly priv shouldn't. There's no way we can give people NOT the real fly priv and still achieve flight?
Author
Member

On another note: many of the people who still have fly priv shouldn't. There's no way we can give people NOT the real fly priv and still achieve flight?

there needs to be a way to distinguish "builders' flight" from "granted flight". currently, the builders' flight code can't distinguish between the case of "player was granted flight" and "builders' flight ran out, but the server crashed before we could revoke it".

probably the simplest thing would be to do would be to add another privilege to either (1) indicate that "flight" is "builders' flight" and not "granted flight" (2) indicate that "flight" is "granted flight" and shouldn't be messed w/ by the builders' flight code.

> On another note: many of the people who still have fly priv shouldn't. There's no way we can give people NOT the real fly priv and still achieve flight? there needs to be a way to distinguish "builders' flight" from "granted flight". currently, the builders' flight code can't distinguish between the case of "player was granted flight" and "builders' flight ran out, but the server crashed before we could revoke it". probably the simplest thing would be to do would be to add another privilege to either (1) indicate that "flight" is "builders' flight" and not "granted flight" (2) indicate that "flight" is "granted flight" and shouldn't be messed w/ by the builders' flight code.

probably the simplest thing would be to do would be to add another privilege to either (1) indicate that "flight" is "builders' flight" and not "granted flight" (2) indicate that "flight" is "granted flight" and shouldn't be messed w/ by the builders' flight code.

I wouldn´t mess with the original fly priv to avoid problems with other mods, builders flight should get it´s own "tempfly" priv.

> probably the simplest thing would be to do would be to add another privilege to either (1) indicate that "flight" is "builders' flight" and not "granted flight" (2) indicate that "flight" is "granted flight" and shouldn't be messed w/ by the builders' flight code. I wouldn´t mess with the original fly priv to avoid problems with other mods, builders flight should get it´s own "tempfly" priv.

I like how the particles look :)

there needs to be a way to distinguish "builders' flight" from "granted flight". currently, the builders' flight code can't distinguish between the case of "player was granted flight" and "builders' flight ran out, but the server crashed before we could revoke it".

That's why we need yl_settings

Or we need to split into "real_flight" and "builders_flight" priv, both of which would grant the fly priv, but can be revoked and granted while the player is not online.

I like how the particles look :) > there needs to be a way to distinguish "builders' flight" from "granted flight". currently, the builders' flight code can't distinguish between the case of "player was granted flight" and "builders' flight ran out, but the server crashed before we could revoke it". That's why we need yl_settings Or we need to split into "real_flight" and "builders_flight" priv, both of which would grant the fly priv, but can be revoked and granted while the player is not online.

2023-01-08 17:18:03: ERROR[Server]: Invalid field number (expected number got string).
2023-01-08 17:18:03: ERROR[Server]: stack traceback:
2023-01-08 17:18:03: ERROR[Server]: [C]: in function 'hud_add'
2023-01-08 17:18:03: ERROR[Server]: ...est/bin/../mods/yl_statuseffects/builders_flight/hud.lua:30: in function 'update_hud'
2023-01-08 17:18:03: ERROR[Server]: ...est/bin/../mods/yl_statuseffects/builders_flight/api.lua:22: in function 'set_remaining_time'
2023-01-08 17:18:03: ERROR[Server]: .../../mods/yl_statuseffects/builders_flight/globalstep.lua:22: in function 'func'
2023-01-08 17:18:03: ERROR[Server]: ...inetest_test/bin/../builtin/profiler/instrumentation.lua:107: in function <...inetest_test/bin/../builtin/profiler/instrumentation.lua:100>
2023-01-08 17:18:03: ERROR[Server]: .../mt/5.6.1/Minetest_test/bin/../builtin/game/register.lua:431: in function <.../mt/5.6.1/Minetest_test/bin/../builtin/game/register.lua:417>

2023-01-08 17:18:03: ERROR[Server]: Invalid field number (expected number got string). 2023-01-08 17:18:03: ERROR[Server]: stack traceback: 2023-01-08 17:18:03: ERROR[Server]: [C]: in function 'hud_add' 2023-01-08 17:18:03: ERROR[Server]: ...est/bin/../mods/yl_statuseffects/builders_flight/hud.lua:30: in function 'update_hud' 2023-01-08 17:18:03: ERROR[Server]: ...est/bin/../mods/yl_statuseffects/builders_flight/api.lua:22: in function 'set_remaining_time' 2023-01-08 17:18:03: ERROR[Server]: .../../mods/yl_statuseffects/builders_flight/globalstep.lua:22: in function 'func' 2023-01-08 17:18:03: ERROR[Server]: ...inetest_test/bin/../builtin/profiler/instrumentation.lua:107: in function <...inetest_test/bin/../builtin/profiler/instrumentation.lua:100> 2023-01-08 17:18:03: ERROR[Server]: .../mt/5.6.1/Minetest_test/bin/../builtin/game/register.lua:431: in function <.../mt/5.6.1/Minetest_test/bin/../builtin/game/register.lua:417>
Author
Member

I wouldn´t mess with the original fly priv to avoid problems with other mods, builders flight should get it´s own "tempfly" priv.

there's no such thing. if a player wants to fly, they have to have the fly priv. it's client-side. similarly, noclip and fast.

> I wouldn´t mess with the original fly priv to avoid problems with other mods, builders flight should get it´s own "tempfly" priv. > there's no such thing. if a player wants to fly, they have to have the fly priv. it's client-side. similarly, noclip and fast.
Author
Member

2023-01-08 17:18:03: ERROR[Server]: Invalid field number (expected number got string).

hmmmm i copied that from xp_redo, i thought it was supposed to contain a color. will remove it, i don't think i need to set a color.

> 2023-01-08 17:18:03: ERROR[Server]: Invalid field number (expected number got string). hmmmm i copied that from xp_redo, i thought it was supposed to contain a color. will remove it, i don't think i need to set a color.

I wouldn´t mess with the original fly priv to avoid problems with other mods, builders flight should get it´s own "tempfly" priv.

there's no such thing.

Are you sure? Now Im curious what that fly priv is in your own next sentence.

if a player wants to fly, they have to have the fly priv....

> > > I wouldn´t mess with the original fly priv to avoid problems with other mods, builders flight should get it´s own "tempfly" priv. > > > > there's no such thing. Are you sure? Now Im curious what that fly priv is in your own next sentence. >if a player wants to fly, they have to have the fly priv....
Author
Member

Are you sure? Now Im curious what that fly priv is in your own next sentence.

the privilege named "fly" is magic. unlike other privileges, the server tells the client whether a player has "fly", along w/ "fast" and "noclip". the client uses this to allow/bar the player from using fly/fast/noclip modes. this is why hacked clients allow players to fly when they should not, by ignoring what the server says and just saying "we have this privilege".

there is no way to create a second privilege which also controls these powers. they are hard-coded into the client, the server, and the network protocol.

> Are you sure? Now Im curious what that fly priv is in your own next sentence. the privilege named "fly" is magic. unlike other privileges, the server tells the client whether a player has "fly", along w/ "fast" and "noclip". the client uses this to allow/bar the player from using fly/fast/noclip modes. this is why hacked clients allow players to fly when they should not, by ignoring what the server says and just saying "we have this privilege". there is no way to create a second privilege which also controls these powers. they are hard-coded into the client, the server, and the network protocol.
Author
Member

noting that today i finished an update which (1) makes the HUD usable (2) actually limits the amount of time a player can fly (see https://github.com/minetest/minetest/issues/13129)

noting that today i finished an update which (1) makes the HUD usable (2) actually limits the amount of time a player can fly (see https://github.com/minetest/minetest/issues/13129)

Are you sure? Now Im curious what that fly priv is in your own next sentence.

the privilege named "fly" is magic. unlike other privileges, the server tells the client whether a player has "fly", along w/ "fast" and "noclip". the client uses this to allow/bar the player from using fly/fast/noclip modes. this is why hacked clients allow players to fly when they should not, by ignoring what the server says and just saying "we have this privilege".

Great, we agree on that.

there is no way to create a second privilege which also controls these powers. they are hard-coded into the client, the server, and the network protocol.

See thats the point, I never said to create a priv to control flying just that builders flight should get its own "tempfly" priv.
But I will happily explain it more lengthy later to avoid confusion others.

> > Are you sure? Now Im curious what that fly priv is in your own next sentence. > > the privilege named "fly" is magic. unlike other privileges, the server tells the client whether a player has "fly", along w/ "fast" and "noclip". the client uses this to allow/bar the player from using fly/fast/noclip modes. this is why hacked clients allow players to fly when they should not, by ignoring what the server says and just saying "we have this privilege". Great, we agree on that. > there is no way to create a second privilege which also controls these powers. they are hard-coded into the client, the server, and the network protocol. See thats the point, I never said to create a priv to control flying just that builders flight should get its own "tempfly" priv. But I will happily explain it more lengthy later to avoid confusion others.
Author
Member

See thats the point, I never said to create a priv to control flying just that builders flight should get its own "tempfly" priv.

ah, that sounds like what i wrote in this comment: #3453 (comment)

> See thats the point, I never said to create a priv to control flying just that builders flight should get its own "tempfly" priv. ah, that sounds like what i wrote in this comment: https://gitea.your-land.de/your-land/bugtracker/issues/3453#issuecomment-37638
Member

The limits Alias imposed here seem far too restrictive for me. Dying just because of not noticing that the area ends there? Or that the time runs out? Builders ought to be able to concentrate on building, not on timers running out.

Flying during the build process first and foremost saves time because no scaffolding needs to be built. If players die randomly due to too many limitations, they have to get back to their build place, have to grab their bones and re-sort their inventorym because it's chaotic after a death. The time advantage may get lost entirely.

The limits Alias imposed here seem far too restrictive for me. Dying just because of not noticing that the area ends there? Or that the time runs out? Builders ought to be able to concentrate on building, not on timers running out. Flying during the build process first and foremost saves time because no scaffolding needs to be built. If players die randomly due to too many limitations, they have to get back to their build place, have to grab their bones and re-sort their inventorym because it's chaotic after a death. The time advantage may get lost entirely.
Author
Member

i'd happily add a shimmering effect at the edges of safe flight when a player is near them, or whatever else alias thinks is reasonable.

i'd happily add a shimmering effect at the edges of safe flight when a player is near them, or whatever else alias thinks is reasonable.

Builders flight is intended to help builders, not kill them.

Please note: My "initial ideas" were a very early draft and many of those are outdated or you replaced them with superior ideas.

From all the discussion presented and what I need to include from a game design perspective, we'll piece together what builders flight will look like. Certainly no semi-creative, certainly no death machine.

Builders flight is intended to help builders, not kill them. Please note: My "initial ideas" were a very early draft and many of those are outdated or you replaced them with superior ideas. From all the discussion presented and what I need to include from a game design perspective, we'll piece together what builders flight will look like. Certainly no semi-creative, certainly no death machine.
Member

We might also use builders' flight to promote the voting process on new city services. New players are seldom in need of builders' flight. They need to gather materials first and start with a small base. We might require players to have participated in some votes or at least visited old sites that had been voted on successfully and talk to the NPC there before they get builders' flight. Some familiarity with what exists on the server might not hurt before starting your own large project.

We might also use builders' flight to promote the voting process on new city services. New players are seldom in need of builders' flight. They need to gather materials first and start with a small base. We might require players to have participated in some votes or at least visited old sites that had been voted on successfully and talk to the NPC there before they get builders' flight. Some familiarity with what exists on the server might not hurt before starting your own large project.
Author
Member

We might also use builders' flight to promote the voting process on new city services. New players are seldom in need of builders' flight. They need to gather materials first and start with a small base. We might require players to have participated in some votes or at least visited old sites that had been voted on successfully and talk to the NPC there before they get builders' flight. Some familiarity with what exists on the server might not hurt before starting your own large project.

i like this idea, but we shouldn't block basic builders flight on implementing this

> We might also use builders' flight to promote the voting process on new city services. New players are seldom in need of builders' flight. They need to gather materials first and start with a small base. We might require players to have participated in some votes or at least visited old sites that had been voted on successfully and talk to the NPC there before they get builders' flight. Some familiarity with what exists on the server might not hurt before starting your own large project. i like this idea, but we shouldn't block basic builders flight on implementing this
Member

Certainly not block! This is just an idea I wanted to write down so that I don't forget.

Certainly not block! This is just an idea I wanted to write down so that I don't forget.
Author
Member

i've done some more work on this today. things which changed:

  • players w/ flight that didn't come from builders flight will not be at risk of losing their flight
  • when a player first uses the potion, they get a reminder of how it works.
  • particle velocity is now slightly to the rear of the player
i've done some more work on this today. things which changed: * players w/ flight that didn't come from builders flight will not be at risk of losing their flight * when a player first uses the potion, they get a reminder of how it works. * particle velocity is now slightly to the rear of the player
flux added
4. step/ready to QA test
and removed
4. step/at work
labels 2023-02-02 19:11:22 +00:00
flux added this to the 1.1.118 milestone 2023-02-02 19:30:51 +00:00

it should only work in own master areas, not in subarea.

There should be a command where owner of a masterarea can toggle whether or not owners of subareas of said masterarea can use builder's flight

> it should only work in own master areas, not in subarea. There should be a command where owner of a masterarea can toggle whether or not owners of subareas of said masterarea can use builder's flight
Author
Member

it should only work in own master areas, not in subarea.

There should be a command where owner of a masterarea can toggle whether or not owners of subareas of said masterarea can use builder's flight

i agree, but i think it's alright to ship the current mechanics before that's implemented. there's plans to create a general mechanic for tagging areas w/ various properties to control various behaviors, but i think the basic flight mechanic should ship first.

> > it should only work in own master areas, not in subarea. > > There should be a command where owner of a masterarea can toggle whether or not owners of subareas of said masterarea can use builder's flight i agree, but i think it's alright to ship the current mechanics before that's implemented. there's plans to create a general mechanic for tagging areas w/ various properties to control various behaviors, but i think the basic flight mechanic should ship first.

Exactly where can you fly with the current Builder's Flight?
Is it only in master areas? Is it in subareas?

Exactly *where* can you fly with the current Builder's Flight? Is it only in master areas? Is it in subareas?
Author
Member

Exactly where can you fly with the current Builder's Flight?
Is it only in master areas? Is it in subareas?

w/ this update, any area you can build in, you can fly in, and there's a slight allowance for flying outside the area.

one thing that's still TBD is how players will actually get builders flight items. it may only be given to certain people at first, or might be available from an admin shop or NPC. there is no crafting recipe.

> Exactly *where* can you fly with the current Builder's Flight? > Is it only in master areas? Is it in subareas? w/ this update, any area you can build in, you can fly in, and there's a slight allowance for flying outside the area. one thing that's still TBD is how players will actually *get* builders flight items. it may only be given to certain people at first, or might be available from an admin shop or NPC. there is no crafting recipe.

While we're doing this, note that it is important to have the ability to deny builders flight within an area. Like area_open but no_fly_zone. This allows to set a sub-area and control more granular denial of flying. If you're building a parkour mini-game for example you would want to deny flying but maybe there is some area where flying is required for a unique movement puzzle challenge or 6-axis maze.

While we're doing this, note that it is important to have the ability to deny builders flight within an area. Like area_open but no_fly_zone. This allows to set a sub-area and control more granular denial of flying. If you're building a parkour mini-game for example you would want to deny flying but maybe there is some area where flying is required for a unique movement puzzle challenge or 6-axis maze.
Author
Member

While we're doing this, note that it is important to have the ability to deny builders flight within an area. Like area_open but no_fly_zone. This allows to set a sub-area and control more granular denial of flying. If you're building a parkour mini-game for example you would want to deny flying but maybe there is some area where flying is required for a unique movement puzzle challenge or 6-axis maze.

i agree that that's an important consideration, but it won't be part of this release. if players are flying where they shouldn't, that will have to be handled on the social side of things until a more full-fledged builders flight mechanism is implemented.

> While we're doing this, note that it is important to have the ability to deny builders flight within an area. Like area_open but no_fly_zone. This allows to set a sub-area and control more granular denial of flying. If you're building a parkour mini-game for example you would want to deny flying but maybe there is some area where flying is required for a unique movement puzzle challenge or 6-axis maze. i agree that that's an important consideration, but it won't be part of this release. if players are flying where they shouldn't, that will have to be handled on the social side of things until a more full-fledged builders flight mechanism is implemented.

This is what I heard most often:

  • There was a wish for different messages when item wears out and when areas is left. I'd be OK with either way.
  • One Builders flight item works in all owned areas and the player can fly in all of them. For testing, this is OK
  • People wished for an earlier warning before plummeting to the ground. That "late" warning may be due to me configuring only 60 seconds for testing purposes. For testing, this is OK
  • One asked for an auto- /spawn or /home when it runs out midair, but that's hard to detect. For testing, this is OK
  • If the item is used during a previous builders flight is running, the timer is reset. We should either make it that the time is added (preferred) or that the item cannot be used while builders flight is already active. For testing, this is OK
  • People unanimously love the HUD timer :D
This is what I heard most often: - There was a wish for different messages when item wears out and when areas is left. I'd be OK with either way. - One Builders flight item works in all owned areas and the player can fly in all of them. For testing, this is OK - People wished for an earlier warning before plummeting to the ground. That "late" warning may be due to me configuring only 60 seconds for testing purposes. For testing, this is OK - One asked for an auto- /spawn or /home when it runs out midair, but that's hard to detect. For testing, this is OK - If the item is used during a previous builders flight is running, the timer is reset. We should either make it that the time is added (preferred) or that the item cannot be used while builders flight is already active. For testing, this is OK - People unanimously love the HUD timer :D
AliasAlreadyTaken added the
ugh/QA OK
label 2023-04-20 14:23:19 +00:00
flux added
4. step/question
5. result/fixed
and removed
4. step/ready to QA test
4. step/discussion
labels 2023-04-25 18:37:33 +00:00
flux removed this from the flux's TODO list project 2023-04-25 18:37:36 +00:00
AliasAlreadyTaken was assigned by flux 2023-04-25 18:37:42 +00:00
Author
Member

this is live, but how do players acquire the item?

this is live, but how do players acquire the item?

Since this is the first iteration of builders flight, we'll rule "test ok" and make the item available as soon as possible :)

Issues with the item will have a new issue ID and subsequent iterations as well.

Since this is the first iteration of builders flight, we'll rule "test ok" and make the item available as soon as possible :) Issues with the item will have a new issue ID and subsequent iterations as well.
Sign in to join this conversation.
No Milestone
No project
8 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#3453
No description provided.