0.71.0 Release discussion #997
Labels
No Label
#P1 CRITICAL
#P2: HIGH
#P3: elevated
#P4 priority: medium
#P6: low
#Review
annoying
API
bug
code quality
combat
commands
compatibility
configurability
contribution inside
controls
core feature
creative mode
delayed for engine release
documentation
duplicate
enhancement
environment
feature request
gameplay
graphics
ground content conflict
GUI/HUD
help wanted
incomplete feature
invalid / won't fix
items
looking for contributor
mapgen
meta
mineclone2+
Minecraft >= 1.13
Minecraft >= 1.17
missing feature
mobile
mobs
mod support
model needed
multiplayer
Needs adoption
needs discussion
needs engine change
needs more information
needs research
nodes
non-mob entities
performance
player
possible close
redstone
release notes
schematics
Skyblock
sounds
Testing / Retest
tools
translation
unconfirmed
mcl5
mcla
Media missing
No Milestone
No project
No Assignees
10 Participants
Notifications
Due Date
Dependencies
No dependencies set.
Reference: VoxeLibre/VoxeLibre#997
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?
Do you think the lid can be opened to 90 degrees only? It looks weird clipping too much into walls.
MC2:
Minecraft:
Ok, I can work on that.
I think we should wait for Villages and call the release the "Village Update".
Wow, wouldn't that take a long time to release? There's plenty to do for the villages update - professions, trading, breeding, etc. And we still need a Potion of Weakness, so we can cure zombie villagers. Or is the healing done differently compared to Minecraft?
The mob spawning should be fixed (once and for all) before the Village Update. We already have too many of them, so adding villagers will further impact the game. Here'a screenshot, although a video would've made all of them more visible - tens of mobs, no kidding.
Professions, trading, and curing is already implemented. The potion of weakness exists. Mobs can't have status effects tho, so I just left the weakness part out when implementing the curing.
Release 0.71.0 "animated chests"?to Next release when?Wow, that's significant progress! Se we can cure them only with a golden apple? :) And if the players can have status effects, would it require significant (or even engine) changes to give mobs status effects?
Anyway, we still need a few functional job site blocks, like the composter (#691), blast furnace, smoker, barrel and others that can also be used by the players - some of which were added in newer Minecraft versions. But I'm sure many players will be happy even if we start with having them as decorative blocks first, like Minecraft did for a few of them. :)
For reference
Yes, just cure zombie villagers with a golden apple.
It would not require any engine changes. But the thing is, (bzoss if you read this, I'm sorry but I gotta say it) status effects and potions are implemented pretty bad from an API / extendability perspective. I think I'm rewrite some of the code to provide a proper API and to make things like mob status effects possible.
I don't think we should make job site blocks. I can't think of any way it will not totally kill performance.
The features of the next release should be:
See also: https://git.minetest.land/Wuzzy/MineClone2/milestone/2
Feel free to add items to the list, it's probably incomplete as I just added stuff I know about, which is mostly the stuff I did myself / planning to do myself.
Next release when?to 0.71.0 Release discussionI really like the idea of discussing when to do a release and what features it should include. We should do this for every release. Let's show Wuzzy we can do it ;)
Most of the job site blocks are actually useful for the players too, so we will need them at some point. That's why I said even if they start out as decorative blocks, which is harmless to the performance, they would be appreciated. Besides, how would we give a villager a profession? How about trading - is it planned or in the works? What exactly can be expected from the first villager release?
Trading is completed. Villagers are pretty complete, they already exist for pretty long. It's the villages that are worked on (-> mapgen). You can try out villagers in creative mode. They just all have random jobs, and you can't change their jobs.
Sorry, I got you wrong about the adding job site blocks, of course we should add the blocks themselves.
EDIT: MineClone2's target is 1.11 - All of the blocks from your list were added in 1.0 or 1.14, and MineClone includes the 1.0 blocks on the list. I think the mechanic of job site blocks was added in the 1.14 update, so that is beyond the MineClone2 target anyway.
That's pretty nice. :) Now assigning and changing jobs might be something to look into before this update, because it's actually not a huge thing.
What do you think?
[1] Movement pattern: Villagers tend to not travel far from their beds in a large village unless the job site or the nearest gossip site (bell) is far from their beds. [...] If a villager finds itself outside the village boundary, or a villager without a village detects a village boundary within 32 blocks, it moves quickly back within the boundary. A villager taken more than 32 blocks away from its village boundary forgets the village within about 6 seconds. Whether in a village or not, a villager is never prone to despawning.
In which Minecraft version was assigning jobs introduced? I think it's 1.14. If so, we should not do it, since it is really a difficult and performance critical task, and if its 1.14 its very low priority.
I think #868 is realy important to resolve for 0.71.
This issue is very blocking for mods creation.
Changing their professions by player interaction was added in 1.14 indeed, but the game kept a balance since 1.3.1:
Now don't take the following as a request to push for anything, I just want to understand why you think job reassiging is a performance critical task. Either you're thinking about a more complicated implementation than necessary, or I'm missing something.
Currently, whatever job gets assigned to a villager, they will keep it. Is the function doing the random job assignment implemented in a way that has a performance impact? If it isn't, I don't understand what would impact performance, because they can't change profession on their own, or randomly, the exception being the balancing done by the game - and it's a one time event even if it's "expensive". I don't know why flipping a few bytes (skin, profession, job site block coords) on an entity, one time, would have a constant performance impact.
From an algorithmic perspective, there are two main cases when having job site blocks:
So from a performance perspective I don't see what would be problematic. Their job site block interaction is just like the sheep eating grass at random time intervals, triggering a sound in the process. Only the farmer is supposed to do more than that, by planting and harvesting. Now with Minecraft 1.14 they also added a schedule, which is simply a behavior pattern reliant on the time of day, probably introduced for the villagers' activity to feel more natural. I see this schedule as a switch-case implementation.
So what would require CPU cycles or a lot of RAM in any of this, and why?
The performance problem is not the changing jobs itself. The problem is determining the conditions when to change jobs; if we implement job switching it will result in a painful chain of issues like what happened with mob despawning, e.g. villagers changing their jobs right when the player is trading, villagers changing the jobs all the time, and so on. Compared to despawning, villagers changing their professions is just not really relevant. If we on villagers we should focus on making the villagers staying in the village and the village not being over- or underpopulated. That alone is hard enough.
But the thing is, we (afaik, tell me if I'm wrong) didn't even plan to touch the villager code, we only discussed the villages mapgen feature. I for myself don't plan to work on villagers, there is enough to do anyway. The feature that is worked on is "Generate villages" and not "Improve villagers". We can improve on villages later, but I'm against doing it in 0.71.0.
If somebody wants to do this: Fine, but I'll not work on it in this release. Don't bloat the release with too many features. I think we should make a release at some point that gives MineClone2 a proper API. Many things are just pure pain, this one is just an example. Modders often have to waste their time working around workarounds. But again, we should focus on one or two big things in every release only. This release focuses on Villages and Animated chests as "big" features; as small features cleanups & fixes of the newer gameplay features (Enchanting, Burning, Status effects, Despawning) and tweaking of Minecarts & Boats.
I'd suggest to make 0.72 the Performance & API update. I'm also planning to complete the texture pack converter in 0.72.
Fishing is also something we need to work on sooner or later; but it seems like nobody is interested. I'll work on it in 0.73 unless someone else wants to do it earlier. By then we might have the required engine changes to make it actually good.
Another point we'll need to work on is making mobs in general a bit better (e.g. migrate to mobkit).
We might need a Roadmap / Milestones. Does gitea support something like that?
Again, I was strictly interested in knowing why you considered the jobs a performance issue, so I'm not looking for having any of this in 0.71.0.
It looks like you have a more complicated idea about the implementation, but it can be kept simple.
In Minecraft, villagers:
Pseudocode:
So this is event-based, and not a performance concern.
Add #995. At the time of writing, white treasure chest lids are unavoidable on mobile. (grammar?)
I've created a Milestone for 0.71.0: https://git.minetest.land/Wuzzy/MineClone2/milestone/2
And Guys can you announce the ETA of 71.0
This issue tracker is not a chat, please keep in mind everyone participating in each issue receives an email notification for each comment, so try to add everything you consider relevant into one message.
And typos can be fixed by editing your message - which also allows you to add more ideas to the same post if no one replied in the meantime.
P.S. Hello, and welcome to Minetest and MineClone 2. :)
Ok
Please stop spamming
Anyway, what about the 0.71 release date?
I'd say two weeks after Mt release, the 20th of February.
@EliasFleckenstein03 What do you think about the following? Some might be simple enough for the next release.
#46 Fishing rod + #807 Fishing improvements
#631 Equip armor with shift-click
#855 Check dirt before generating decorations
#897 Log weather changes
#898 Fishing bobber stuck in underwater block + more
#900 Applying bone meal only generates items on the same level of dirt
#916 Inconsistent behavior opening and closing trapdoors
Fishing is too big to be touched right now and we dont have the necessary engine changes.
Armor should be reworked later on (to use API from MT 5.3 instead of a workaround from 0.4.16), so that won't be included in this release.
Check dirt before generating decorations: I don't really know what to do here, mapgen is one of the things I leave up to others.
Log weather changes: We could put that one in, I don't think its a good idea tho, the logfile is spammed enough anyway. There should be a setting to enable/disable it. I've added it to the milestone.
The other ones are no problem, but I'll probably only work on it if there is enough time.
All sounds good, just keep in mind we have two sounds that we can use for fishing.
OK, since you never did a release before, here's a list of things that I did for every release:
git tagthe last commit with the version number (e.g.git tag 0.71.0)--tagsingit push!)You already told us. I've also put it into CONTRIBUTING.md I think. ;)
Oh, right. My memory is broken sometimes. Control over ContentDB and forum post is still TODO, but I talked to rubenwardy now.
I think we should make a habit of stating which versions we use before anything, because some issues refer to the latest (or a specific) release, while some are about the latest development snapshot. It would help
If Gitea supports issue templates, it would help to have one like this:
903a29f949is obvious (commit ID), which can be useful for 100% clarity. If the poster doesn't know how to get the ID, or if it's irrelevant, dev-latest would be good as well, as the issue's date and time can be correlated with the commit's if necessary.This is in particular an answer to MineClone2/MineClone2#1060 (comment)
Yes, it depends on 5.4.
Don't get irritated by the amount of issues that are still open. Many of them are duplicate, waiting for MT release, discussion issues, or with a checklist that is almost done. Some issues take very long to implement, others are easier, and Imo most of the big features are done. However, you are right that we'll probably not get everything done until the 20th. Therefore I suggest:
Edit: I also announced this at the forums and on discord.
As long as 0.71 depends on Minetest 5.4.0 to be relased, the next MC2 release date can only be tentatively set. But we should keep in mind that 5.3.0 also had an RC2, and 5.4.0 is only in RC1 stage. We might as well set a flexible release date, like within 3-7 days after the 5.4.0 gets released. :P
Minetest 5.4.0 is finally out! :D
@kay27, there are still a lot of open issues in the 0.71 milestone assigned to you, should I take care of some of them? Should some of the issues be moved?
All except carts will just bugfixes - suit well for 0.72.
Carts - well... well... well... I don't like to push them right now, so many problems left, and so many upcoming features and tests... It can really spoil all the impression from new release.
So I'm sure I'll definitely continue working on it but let's just move these all and release what we currently have.
I think we should move #1126, #1178, #1117, #1055, #924, #1002, #247 to the Mineclone 0.72 milestone. Unless some of them have already been done. I don't think these issues are important for Mineclone 0.71 and its time we release 0.71 and shift our focus to 0.72.
But I think it would be good to implement #567 so minecart becomes consistent with boat.
#1117 should be fixed for 0.71 because it's really annoying and the remaining swimming issues are not hard to solve (compared to the earlier ones). We'll be using 0.71 for a while, so waiting for another day is worth it.
@epCode please take a look if you can fix MineClone2/MineClone2#1117
let me know if you need some help
@ryvnf OK, MineClone2/MineClone2#567 is easy, I'll try to close it today.
I want #1178 and #1117 to be done before 0.72. Minecarts would be cool, but if you're not done until first of march, that's ok as well.
Both on me, oh boy, :). I will work on these mainly today then.
I also think #1152 should fixed before 0.71 if possible. We want to avoid having critical bugs in the release since Mineclone2 will probably stay on 0.71 for a while. Unless generating villagers are disabled.
Also applies to #1131 but I think that can have slightly less priority. But I think we ideally should fix both for 0.71.
Also adding #1203 to the list of things I think we want to fix for 0.71.
Fixing #1152 should be as easy as removing the toolcaps from tools when serialized and applying them again when the player actually trades for them. I have assigned myself.
#1203 should be trivial as well.
#1131 should be done in 0.72 because changing creative / damage ingame has certainly to do with gamemode switching and I don't think it's a good idea to implement dynamic in-game changing of damage using settings if we want to do it per-player in the next release anyway.
i also think #1194 should be done in 0.71. my son says it's very annoying when the lava flows faster than the water. it's very hard to make obsidian.
How does this make sense? You can't even create obsidian from flowing lava, it needs to be lava source. The flowing speed of lava has nothing to do with obsidian. Also didn't you see I added the "needs engine change" label? We currently can't fix this.
There are very easy ways too. Just use dirt to create a shape (like scaffolding) around the places you need to place the lava source blocks, then pour water over those. It takes about 5 minutes.
Check this out: https://youtu.be/vkdyl57CHoc
^ Now the guy in the video went from top to bottom, which makes things a bit harder with lava flowing. As long as you have the shapes for each layer going up, pour water and no lava will spill anywhere.
@kay27 I'd prefer to release 0.71 soon, so what is the ETA for minecarts? It's perfectly fine if chest/hopper/furnace minecarts are not implemented. I moved nether portal linking for now.
As soon as #1152 and #1178 and Minecarts (at least particulary) are done we can release.
In addition to this: let's close critical labels and release. If you want to fix current carts yourself - please feel free. What I'm doing offline is more likely a complete redesign, there is a lot of work still. Carts really have many problems for me. I still don't know how to resolve some of them. Main problem is client/server synchronization, especially when there is a lag and the speed is high, and all the stuff related - e.g. proper physical state: I'm still comparing 3 versions of code and can't decide which behaves better - they behave different in some specific conditions, e.g when you move through tunnels with solid walls, meet the mobs, etc. Maybe I should add three different carts to some publicly listed server to let you guys check them yourselves... but now the best one is from latest MTG, to be honest
Hmm ok. Then lets just get #1152 and #1178 done and we're ready to release, I hope you'll be able to port some minecart features tho.
Could You please give a deb of minetest 5.4.0
armhf for raspbian
This does not have anything to do with MineClone2 0.71. Please stop offtopic posts.
OK, I'm releasing 0.71 now. No commits to master please until it is done!