flux reports: put 1 ethereal:glostone in a t ... #1981
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
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#1981
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?
flux reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
Upstream issue:
https://github.com/minetest-mods/moreblocks/issues/190
I'll try to get this fixed soon, but I'm feeling terrible today, so probably not today.
This might devolve into me rewriting moreblocks so as to fix all the major longstanding bugs.
As this can currently be used to create infinite quantities of glostone with minimal effort, I'm upgrading the priority of this.
I've started a massive cleanup (or partial rewrite) of
moreblocks
.https://github.com/fluxionary/minetest-moreblocks/tree/bugfixes
will be fixed when https://github.com/minetest-mods/moreblocks/pull/191 is live
From the discussion in this PR, it seems a lot of people are interested, but it still needs a bit of testing?
I noticed I can't import stuff from the testserver to the main due to some nodenames being different?
i'm not sure anyone wants more testing, but the people in charge of accepting the PR are being very cautions because this is a huge change. i don't blame them. not all the interested parties may be aware of the plans for the mod. perhaps i should try to speed things up by talking about it again in #minetest on IRC.
correct, it changes (normalizes) the names of many of the shaped sub-blocks. if you want, i could try to write a "revert" mod if someone decides they want to go back to the old way. i'm not sure it's possible to that "perfectly" though.
It's very good they are cautious, the last thing we need is a fragmentation over blocks where the old ones don't stack with the new ones and cause a mess during import of old schematics. Currently, importing old schematics to a moreblocks rewrite server will crash it. This can hardly be blamed on the moreblocks rewrite though, its more a WE problem: Looks like during import they do not consider aliases.
What's the reasoning behind this normalization? To get out of the moreblocks namespace?
ah, there's multiple normalizations.
yes, the "mod" portion of the itemstring of microblocks is now always the same as the original node. this is because most of the time, the mod should be the one responsible for registering the microblocks, not moreblocks. it also helps to avoid conflicting nodes, which was something we had on blocky survival - there were two nodes called "stone_tile", both of which could be used with the saw, but only one set of microblocks.
i also changed the naming format of some of the shapes so that "panel", "slab", and "micro" names matched. e.g there was a "panel_%s_quarter" which became "panel_%s_4"
hm. that's not good. which "import" method are you talking about?
//save
and//load
, or//mtschemcreate
and//mtschemplace
?@AliasAlreadyTaken i tried on a local test world. 1 of every variant of a gold block, and chests containing all the variants, and a circular saw w/ some stuff in it.
//load
worked flawlessly.//mtschemplace
worked as i expected (it doesn't handle node metadata including inventories). neither caused a crash.A building was created on the testserver with the new moreblocks enabled. This was saved as a WE schematic via
//save
and then imported to the main with//load
. That crashed the server.ah, so the problem was going backwards. i'm curious why that crashed things, but it absolutely shouldn't work properly.
i created an issue upstream on worldedit: https://github.com/Uberi/Minetest-WorldEdit/issues/210
Restest moving "old" moreblocks schematics to "new" moreblocks before moreblocks milestone!
is there anything you need me to do?