mod-dev-talk Friday 18 June 2021

61 messages7 people

ColdFlame5300:46
How about blender ? (:
nailuj01:00
Replying toColdFlame53How about blender ? (:
i dont think that would export to mc models
ColdFlame5301:04
What file format do they use ?
CDAGamingTeam01:06
java and json I think
And it's not the json part thats the issue, its the fact that the entity data format shifted in 1.17 for the java-end
And migrating is not straightforward for it
Haven King01:13
https://github.com/Haven-King/myron 😉
GitHub
Haven-King/myron
An OBJ loading library for the fabric ecosystem. Contribute to Haven-King/myron development by creating an account on GitHub.
Works on 1.17
Doesn't work very well for entities, however, if that's what you were referring to.
ColdFlame5302:11
Oh okay I see what you mean now.
CDAGamingTeam15:56
@Jack Papel Not sure if you could patch this, but riding on a descending block has a few....issues sort to speak xD Luckily there are no other issues i could see
Jack PapelTeam17:47
Yeah I noticed that. I believe it's an issue with the physics system, but I'll see if I can find a workaround
Jack PapelTeam21:12
Maybe we should check if its velocity is negative 😅
Minecraft__1.17_-_Singleplayer_2021-06-18_14-11-14.mp4Video, 6.9 MB. Not stored in the archive.
By the way, when a new FloatingBlockEntity is created, it spawns 0.5 blocks too high. I'll make a PR to fix these things
kalucky0Team21:21
Replying toJack PapelMaybe we should check if its velocity is negative 😅
It's a feature
Jack PapelTeam21:46
About the riding on descending blocks issue, I haven't found any good solutions. Minecraft's boats act a similar way, and have this same problem. One solution I could think of is making the FloatingBlockEntities nonsolid when they fall, but I don't particularly like that solution.
Another solution would be a mixin to the player movement so that it doesn't set its velocity to zero when it lands on the floating block, but that seems a bit like overkill
CDAGamingTeam21:51
Merged the fixes, but yeah in either case something needs to be done to have the de-acceleration not kill everyone that uses it xD
Jack PapelTeam21:57
Been playing around with aerclouds and floating blocks. Wondering what if floating-block-ified aerclouds still acted on you like the normal blocks would
I'll write up some code for it, think it'd be a fun idea
CDAGamingTeam22:02
I tried it, and unfortunatly they don't, but we could design a system for that
Their boundary boxes work (As in youll still sink partially into them) but actual mechanics wont
Jack PapelTeam22:03
It appears that Entity only has onPlayerCollision and no onEntityCollision
So it'll only work for players
CDAGamingTeam22:03
Adds to Jira 1.18 suggestions* xD
LudoCrypt22:06
hey guys
man
yall need to start organizing yalls sounds
nobody does that!
seperate sounds into folders
combine sound events when you need to
there shouldnt be three seperate sound events for three seperate songs
just make one sound event for 'aether_music' or whatever and put em all together
also if we're gonna have creative music in here then youre gonna need to remove music from the biome json anyways and make it into a mixin
actually no you dont have to remove it necessarily(edited)
but you do need a mixin for creative music at least
CDAGamingTeam22:10
I was wondering when someone would bring this up xD Yea, I've been slowly refactoring all the folders, and atm I've been working on the tags, though atm music will be looked at once the 1.17 port is further along 😄
LudoCrypt22:10
moral of the story
alright
just like
sound events need to be renamed
so instead of just the name of the file being its name make it its use
like aether.music.game or block.fly or whatever
also make sure your sound files are properly compressed
an easy way to do that is to just export as an ogg with a quality of 4 in audacity
4 is safe and around what minecraft does
CDAGamingTeam22:12
I definitely am aware that a lot is in a sort of jumbled mess, but refactoring everything to work better together is one of the things I want to finish topping up on 😛 Regardless, I'll keep all this in mind for when that time comes (Which will be soon, I promise 😅)
LudoCrypt22:13
gotcha :P if you dont get around to it i probably will since no one really cares about organizing sounds it looks like
like all the mods ive worked on all their sounds are exactly like what yalls is now
CDAGamingTeam22:15
Well, I definitely can say I'm not one of those people. The Aether is meant to be a very high-quality mod, so I can personally make certain that we'll get to it in time 😄
Jack PapelTeam22:26
Box newBox = getBoundingBox(); getBoundingBox().union(newBox) 🤔
Is there a reason for this?
afaik, that will always return the same thing as getBoundingBox()

CDAGamingTeam22:30

Best way to see, try without it, see if anything explodes xD

Speaking of that

            if (!FallingBlock.canFallThrough(this.floatTile)) {
                Box newBox = getBoundingBox();
                List<Entity> otherEntities = this.world.getOtherEntities(this, getBoundingBox().union(newBox));
                for (Entity entity : otherEntities) {
                    if (!(entity instanceof FloatingBlockEntity) && !entity.noClip) {
                        if (entity.getY() < newBox.maxY) {
                            entity.setPosition(entity.getPos().x, newBox.maxY, entity.getPos().z);
                        }
                    }
                }
            }

Is there a way we could inverse the logic to keep the play linked to the block while its going down?

Jack PapelTeam22:31
Yeah I suppose so
CDAGamingTeam22:32
That's what im thinking the least expensive solution would be, is to just inverse the logic that helps us stay attached while it's going up
If it can work going upwards, surely it's logical that it could work to keep us attached to the block
Jack PapelTeam22:33
I'll tinker around with it
CDAGamingTeam22:36
Another concept I have as well is if we could possibly incorporate rotation to the levitation, so that depending on rotation, a block can go vertical/horizontal (In the case of going horizontal, the block would expire a few away from unloaded chunks to prevent FloatingBlock stasis.