I can't fill the jetpack tank

[DankestO]

What happened?

Since the last update 4.3.1 it seems that the jetpack filling doesn't work, or at least, when you break it after marking that it's full, when you break it it becomes empty again.

Curiously, with Jade it shows that the tank is full before breaking it.

Loader

forge

Mod Version

4.3.1

Minecraft Version

1.20

Relevant log output

No response

[PssbleTrngle]

Does that also happen when breaking it using right-click?

[DankestO]

Oh, I hadn't thought of doing it with a wrench.
And testing it, it seems to work! :D

[PssbleTrngle]

No I meant without a wrench, simply by right-clicking it with an empty hand to pick it up. But wrenching it does work?

[DankestO]

Aaah, I actually grabbed it with the wrench because it wouldn't let me grab it with my hand, or crouching, or without anything.

And yes, grabbing it with the wrench seems to work correctly, it doesn't lose air in it.

[j-romchain]

I'm experiencing something similar.
using /data on the item (/data get entity [myplayer] SelectedItem) the tag says it has "389.0039f" air, and when I place it down and read the data (/data get block [blockpos]) it then has 2 sections. on the base tag it has "389" air, but in a subtag called "VanillaTag" it still has "389.0039f" air and after powering with kinetics till it poofs it says 900 air on the base tag, but still "389.0039f" in VanillaTag.Air... I have managed to get it to fill up once, but I have not been able to recreate it.

[j-romchain]

I eventually have recreated it, and it ONLY seems to be filled when you right-click the block with an empty hand and no chestplate armor.

[j-romchain]

I'm not sure and I don't have a testing rig set up, but data merging has never seemed to work well for me and I think it refuses to replace things that are already there if they have certain type differences or something.

[j-romchain]

if it is a "merge refuses to replace float with int" issue then the proper action could be to switch the float to an int everywhere, but then keeping track of multiple uses per air value gets complex, and if this does fix the problem then its good enough for me.

[PssbleTrngle]

very weird, I just copied what the normal backtank has going on as a loot table, I might have to check again if I made a mistake there

[PssbleTrngle]

Ok truly very weird, I can pick it up using a wrench by shift-right-clicking, an empty hand or simply a pickaxe and all of them give me a jetpack with air.
You do have the latest version of create (0.5.1.h) installed, right?

[DankestO]

Yup, all updated.
I just figured out why I couldn't grab it with right click, I didn't have to have a certain piece of armor equipped (I use jetpack in curios)

I also noticed a couple more things.
-This only happens when you break it with a pickaxe (although we already knew this(?))

-I got netherite jetpacks from the creative, it seems that they only charge correctly the first time, the second time for some reason they don't refill correctly if you break them with the pickaxe.
The jetpack's fill limit in this case, would be the maximum it has at that moment, so the more you use it, the maximum goes down, and it never fills correctly again. It's a bit strange to explain.

[j-romchain]

my guess is it is because of failure to over-write the float value that the jetpack stores for air (so that you can get multiple uses per air-unit) with the integer value that the backtank fill mechanism uses.

[j-romchain]

You do have the latest version of create (0.5.1.h) installed, right?

yes, that is the precise version number I have.

[j-romchain]

perhaps it is an incompatibility with another mod I have?
perhaps the jetpack curio mod by robinfrt changes the loot table for it?

[j-romchain]

it is not the jetpack curio mod. just checked

[j-romchain]

attempting to test with the changes, but I can't compile presumably because I'm using the wrong java version somewhere.

[j-romchain]

attatched is the full gradle init fail debug log... I just pulled up the project in intellij and it had that error right off the bat trying with java 22 as the project java and java 17 as the java that I have on my normal $PATH...

log.txt

[j-romchain]

architectury-9.2.14-forge.jar
ars_additions-1.20.1-1.6.6.jar
ars_artifice-1.20.1-2.0.4.jar
ars_artillery-1.1.7-forge-1.20.1.jar
ars_creo-1.20.1-4.1.0.jar
ars_elemental-1.20.1-0.6.5.0.1.jar
ars_instrumentum-1.20.1-4.1.0.jar
ars_nouveau-1.20.1-4.12.4-all.jar
balm-forge-1.20.1-7.3.9-all.jar
citadel-2.6.0-1.20.1.jar
comforts-forge-6.4.0+1.20.1.jar
copycats-2.1.4+mc.1.20.1-forge.jar
create-1.20.1-0.5.1.h.jar
createaddition-1.20.1-1.2.4e.jar
create_connected-0.9.0-mc1.20.1-all.jar
createendertransmission-2.0.7-1.20.1.jar
create_jetpack_curios-1.0.0-forge-1.20.1.jar
create_jetpack-forge-4.3.1.jar
curios-forge-5.10.0+1.20.1.jar
DraconicWizards.jpeg
essential_1-3-4-1_forge_1-20-1.jar
geckolib-forge-1.20.1-4.4.9.jar
iceandfire-2.1.13-1.20.1-beta-5.jar
jei-1.20.1-forge-15.12.2.51.jar
justzoom_forge_2.0.0_MC_1.20.1.jar
konkrete_forge_1.8.0_MC_1.20-1.20.1.jar
kotlinforforge-4.11.0-all.jar
mizs_broom-1.0.2-forge-1.20.1.jar
Patchouli-1.20.1-84-FORGE.jar
PattysMoreStuff-Stable-1.20.1-1.4.1.jar
polymorph-forge-0.49.5+1.20.1.jar
starbunclemania-1.20.1-1.2.2.0.jar
'TATOS 1.0.1_stable.jar'
toomanyglyphs-1.20.1-2.3.2.12345.jar
uniquecommands-1.20.1-1.0.0.jar
waystones-forge-1.20-14.1.5.jar
XaeroPlus-2.23.2+forge-1.20.1-WM1.39.0-MM24.4.0.jar
Xaeros_Minimap_24.4.0_Forge_1.20.jar
XaerosWorldMap_1.39.0_Forge_1.20.jar

is my normal full mod list if it helps with figuring out the source of this issue...

[PssbleTrngle]

Ok I figured it out, it actually does not have to do anything with floats or integers, both would work fine. It's only caused because the two NBT functions in the loot tables are applied in the incorrect order, they are the other way around for the backtank.
Swapping these works, because the Air tag is no longer being overwritten by the VanillaTags. Will release a hotfix version shortly

[j-romchain]

... so my patch would theoretically work, despite being a bit excessive...

[j-romchain]

Anyway, yay!!!

[PssbleTrngle]

@j-romchain yep it would also have worked, thank you very much for your investigation and effort

[j-romchain]

You are very welcome. Thank you for being an active and freindly open source dev!