Model code changes

[dpeter99]

So @elix-x , what do I need to do to make:

• Inscriber
• Charger
• SkyChests

to work?

[Elix-x]

Thos are animated ones, right?

[dpeter99]

Right The pressing anim of the Inscriber The charger and the inscriber shows whats is inside And the chest yeah, the normal mc anim

[Elix-x]

Leave chest to me or @JosephRymer. It's handled internally. Charger shows what's inside, but does it have animation? If no, make model as you would to any block. I or @JosephRymer will take care of item displayed. As for press - there will have to be work done on both sides. Let's leave it for later.

[dpeter99]

OK. @JosephRymer And a few other questions: What about tiles like tile.BlockCrank or tile.BlockGrinder

Could you describe me how the QuartzGlass texture should be set up?

[Elix-x]

Similar to glass. Everything animated will be done when static models are finished.

[dpeter99]

OK For most of the machines Drive, ME Chest, etc. there is no facing information in/for the blockstates file, so I can't rotate them. { "variants": { "facing=north": { "model": "appliedenergistics2:tile.BlockDrive", "y": 180 }, "facing=south": { "model": "appliedenergistics2:tile.BlockDrive", "y": 0 }, "facing=west": { "model": "appliedenergistics2:tile.BlockDrive", "y": 90 }, "facing=east": { "model": "appliedenergistics2:tile.BlockDrive", "y": 270 } } }

[Elix-x]

Somebody should check blockstates passed to models. ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||Poking @JosephRymer - 50%...........................................................

[61352151511]

If it's not too difficult I think that models that render items in it should have a .info file attached to them. That way if someone creates a custom model and wants it rendered on top the info file could handle that. It would just contain information on the translations of the item rendering.

[dpeter99]

I'm using vanilla blocksates now, I can switch to forge if nesesery but expect the Drives I don't see the need. And I think it would be grater if a specially named cuboid inside the actual model would hold the rendered image if possible

[StrayCargo]

Just got home so whats going on exactly we need some models for stuff im reading it right

[StrayCargo]

@dpeter99 working on getting environment going again then i will look at the models some sort of flower bug bring it on

[StrayCargo]

@dpeter99 the issue with the animation bug for the sky stone chest is a simple edit to the json file follow this brief instruction and that should fix it i would but currently waiting for someone to share me their environment since mine is bugged and cant seem to get it going again instructions are below

builtin/entity Uses the hardcoded TileEntityRenderer. Used by Chest, Enderchest, Skull and Banner ^the parent class

[Elix-x]

@JosephRymer i will do the chest and item in charger, it's done with TESR. You can work on animations for presser (and other things) with @dpeter99, as work is required on both sides (model with animations + TESR for items + block render update for begining of animation + extended block states). Also, is your environment still buggy? Which IDE are you using? Which gradle commands did you run?

I got environment going but i got a lot of purple and blacks

[yueh]

Forge has a animation system for their custom json format. Be sure to use it, when possible instead of inventing our version and waste time for it.

Regarding the rotation, we have 24 (36 actually, but 12 are unusable) different rotations. Bloating every blockstate json with it might not be a wise decision. If that can be even achieved with them. Iirc there is a limit of 16 states per block for the normal properties. That is one reason why the 1.8 port uses ISmartModel for pretty much anything.

[Elix-x]

Sure, we will use forge's system.

Starting from 1.9, we have getExtendedBlockState and using it we can pass pretty much anything from TE to json.

[dpeter99]

@elix-x @JosephRymer So whats up with the facing information?

[Elix-x]

In AE, facing isn't like a facing... In short, i'm making example json for one block.

[Elix-x]

Ok, now rotations are being passed to models. Because AE blocks can be rotated on all axis, you have forward and up properties which define which directions that are forward and up of block. These properties exist for all blocks with tile entities. Dummy grinder model included.

[dpeter99]

OK @elix-x now most off my blockstaes are broken (the ones with tile.). They don't show up.

[Elix-x]

Yeah... Now you need to specify 24 ( 6x6-2x6 ) rotation combinations in block states... Plus other things...

[dpeter99]

@elix-x Really? There is no way for it to say that "I don't care about those fields" ? Like this ? { "variants": { "normal": { "model": "appliedenergistics2:tile.BlockCellWorkBench" } } }

[Elix-x]

I don't think so... @dpeter99, @yueh Please give me list of blocks that don't care about rotations. In code, all of them seem to.

[dpeter99]

• CreativeEnergyCell
• DenseEnergyCell
• EnergyCell
• tile.BlockCellWorkBench
• tile.BlockCondenser
• tile.BlockEnergyAcceptor
• tile.BlockIOPort
• tile.BlockSecurity
• tile.BlockSpatialIOPort
• Molecular Assembler
• Crafting Storagges
• Spatial Pylon

these so far @elix-x

And what does up mean

[Elix-x]

up is up direction of block... I'll try to visualize it.

[Elix-x]

Like this:

[dpeter99]

Got it but where do we need things like this? (What program did you used?)

[Elix-x]

For visualization, i used blender. Why the heck do we need thing like this? @yueh why? Couldn't it be done with x-rot y-rot rather then with forward-dir up-dir?

[dpeter99]

I can't see how to change the up-dir. and other than maybe multipart I can't see a usage for it. @elix-x @yueh

[Elix-x]

I can't see how to change the up-dir.

In block state file, you can rotate model around x, y and z (take a look at end rod).

other than maybe multipart I can't see a usage for it.

Facing up frive bay, yes. But facing up drive bay with shelves rotated on x or z... Not quite.

[dpeter99]

@elix-x With:

I can't see how to change the up-dir.

I meant in game.

[Elix-x]

Wrench.

[dpeter99]

Oh ok @elix-x But would you ewer rotate a grinder that way?

[dpeter99]

@elix-x What states does up have?

[Elix-x]

Wait a bit. I may refactor rotations to be x, y instead.

[yueh]

No idea why it uses front/up. It did previously use ForgeDirection, so potentially the helper methods were better to rotate it.

If up actually uses cardinal direction, it should also be way easier to debug it. Pretty much anyone should understand that, if the state says "front=up,top=west" that the front should point to the top and the top side west. Or any other combination. And it is easy to spot invalid combinations, you cannot have up for both. or something like east,west.

Also not sure, if throwing a full blown rotation matrix at it makes it easier, it can only rotate in 90 degree angles.

[Elix-x]

Not full blown matrix... We only need rotations on X (-90<<90) and Y (-180<<180) and they will do all the trick. Then we can even rotate around Z, and it can still be converted to X, Y.

[yueh]

Not sure, if would be an improvement. We already have to convert between EnumFacing and our custom AEDirection because the vanilla one is lacking for our use case. Introducing a new rotation class/enum just for rendering would add more room for errors. Like the interaction with a wrench would report an EnumFacing, it needs to be converted to an AEDirection to lookup the correct part, then again to the rotation stuff.

3D rendering is surely not my best skill, so maybe I am missing something. But currently it does not look like an actual improvement. If you still plan to dumb every single rotation into the state json, there is no real advantage, except being able to copy paste the property value to the rotate definitions. But it would make harder to debug, invalid combinations will no longer be as easy to indentify now. If you see the debug screen ingame, you always have to rotate it in your head (Was the default orientation north? or south? Was -90 clockwise or countclockwise?) Maybe someone with a good knowledge in 3D rendering, can handle it easier.

The only advantage I could see, would be if we can use the value as variable inside the json. So no "forward=south,up=up": { "model": "appliedenergistics2:tile.BlockGrinder", "y": 180 },, but just something like "rotation": { x: $xRot, y: $yRot }. But certainly not possible. Except we bake the rotated ones at runtime. Which would remove something with a high error rate due to copy&paste around the wrong versions.

[Elix-x]

What exactly AEDirection has that EnumFacing does not?

[yueh]

AEDirection is probably the wrong name for it, something like PartLocation might fit better. But whatever.

We need all 6 EnumFacing sides as well as a center. ForgeDirection had an UNKNOWN we could abuse, but that is gone.

[Elix-x]

So technically, AEDirection can be replaced with EnumFacing in all blocks except mutiparts?

[yueh]

Ah it is even named AEPartLocation, no idea why it had AEDirection in mind. Maybe it was the name as we discussed it. In most cases we should already use EnumFacing for most things excapt part handling.

Lex stupid recommendation was to "just use null". Which plain stupid. The code would constantly look like

for (EnumFacing side : EnumFacing.all()) {
   foobar(side);
}
foobar(null);

This would also be common. But it is not easy to determine, if foobar(null) is missing on purpose or a bug.

for (EnumFacing side : EnumFacing.all()) {
   foobar(side);
}

We might even still need a wildcard value, so null might have to cover two different meanings (=> impossible). So might have seen some stuff like

for (EnumFacing side : EnumFacing.all()) {
   foobar(Optional.of(side));
}
foobar(Optional.ofNullable(null));
foobar(null);

Pure bullshit. One idea behind Optional is to not deal with null checks. Just a simple return optional.filter(foo).map(bar);.

[Elix-x]

Use null for valid value? Sorry, what? Yeah, that's not ideal at all. In best case, AEPartLocation should have all valid locations + unknown (in case it actually is unknown, but should work) + null (for buggggs).

[yueh]

Yes, null as a valid value. There was a discussion about patching EnumFacing to contain UNKNOWN. Which is stupid because the enum has a different semantic as the old ForgeDirection and what results/bugs it would introduce to minecraft. Or at least keep ForgeDirection for its different semantic. Lex response was basically "just use null". Which more or less means "I do not care about you having to deal with avoidable bugs, as long as I am not involved somehow or have to provide a solution.".

null in case of AE2 should mostly be a wildcard for anyside. But if we ever need it, we could probably replace it with something like getAllParts() or a getPartsOnSides(EnumSet sides).

[Elix-x]

Null can be a valid value. I meant in a way to that it replaces something meaningful, like UNKNOWN, it's not the best idea.

[yueh]

Yeah. it is a valid value for "absent", but not something ambiguous. Like some mods using it for UNKNOWN/CENTER or a wildcard for anything, or the next just throws an exception.

[dpeter99]

So @elix-x @yueh the conclusion is? Just because I would like to make those models but as most of them (which were already made) are now broken (he tile ones) and I don't really see the need to rotate a IO port in these ways.

[Elix-x]

I'm currently refactoring tiles that don't need to be rotated to not be.

[yueh]

Pretty much every tile needs to be rotatable around all axis. If you can currently rotate it, it needs to stay that way.

[Elix-x]

Why? For example energy cells? They are the same on all sides.

[yueh]

Why not? Even if the only use case currently is a texture pack adding a different texture. E.g which is not mirrored on both axis, but say allows a diamond pattern to form on a 2x2 cube of cells.

Why limit the creativity of them, when it pretty much requires no effort on our side? You do not have to use the blockstates inside the default json. Just ignore them and pretend they do not exist.