basic builders' flight #3453
Labels
No Label
1. kind/balancing
1. kind/breaking
1. kind/bug
1. kind/construction
1. kind/documentation
1. kind/enhancement
1. kind/griefing
1. kind/invalid
1. kind/meme
1. kind/node limit
1. kind/other
1. kind/protocol
2. prio/controversial
2. prio/critical
2. prio/elevated
2. prio/good first issue
2. prio/interesting
2. prio/low
3. source/art
3. source/client
3. source/engine
3. source/ingame
3. source/integration
3. source/lag
3. source/license
3. source/mod upstream
3. source/unknown
3. source/website
4. step/approved
4. step/at work
4. step/blocked
4. step/discussion
4. step/help wanted
4. step/needs confirmation
4. step/partially fixed
4. step/question
4. step/ready to deploy
4. step/ready to QA test
4. step/want approval
5. result/cannot reproduce
5. result/duplicate
5. result/fixed
5. result/maybe
5. result/wontfix
ugh/petz
ugh/QA main
ugh/QA NOK
ugh/QA OK
No Milestone
No project
No Assignees
8 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#3453
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
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.
question: should builders' flight persist between server crashes/restarts?
question: should builders' flight persist if a player logs off and logs back on?
i'm imagining a situation where a player was flying, the server crashed, they rejoin, and then they fall to their death. not fun.
Dangerous. Players who flew up high might get into panic mode and then fall down.
That's extremly short. For that, you'd probably be down to a steel ingot as payment.
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.
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.
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.
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"
Almost forgot
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.
i'd prefer it be craftable, so it can be part of the server economy.
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.
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 a similar idea, see #2862
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.
i like that :)
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:
Wow, so many ideas :D
Fo reference, this was the intial set of ideas for a builders flight mechanic:
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:
Yes. That's why it needs to wait for yl_settings, so we can alter it when a player is not online.
Yes. Else a player might have a disconnect midair and then plummet to the ground.
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)
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.
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.
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.
Regarding the flypriv BLOCK: I'd rather not have "technical" blocks like protectors or flyprivblocks.
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.
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
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.
Certainly a nice bonus :D
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.
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.
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.
That may lead to accidental uses. Also, let's have the time configurable.
That's up to debate and is one of the major questions. See the DURATION paragraph
Definite yes.
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.
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.
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.
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.
Not in favour, but not a clear "no" yet. We don't want to add gliders/feather fall/... with builders flight.
Thanks. That's a good one, I know of at least one who'd occasionally die if not.
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.
the temporary version should be non craftable, the final builders flight should be craftable.
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.
But that the player is flying.
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:
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.
@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.
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.
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.
That potion is pretty expensive iirc.
That's almost no time at all when building.
Rather annoying, yes. I see no reason for this limitation.
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.
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.
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.
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 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
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)
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.
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.
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 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.
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
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.
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.
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.
@AliasAlreadyTaken what to do about accounts that have the "fly" priv, but which are not staff? here is a list:
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.
i've created a PR w/ the work i've done so far: your-land/yl_statuseffects#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?
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.
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 :)
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>
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.
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.
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.
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)
Great, we agree on that.
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.
ah, that sounds like what i wrote in this comment: #3453 (comment)
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.
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.
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
Certainly not block! This is just an idea I wanted to write down so that I don't forget.
i've done some more work on this today. things which changed:
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?
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.
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:
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.