Railcraft

Railcraft

34M Downloads

WAILA always shows water tanks as 0/(whatever size tank) even when full.

InuYasha86000 opened this issue ยท 12 comments

commented

I have found that WAILA is displaying the incorrect water amount inside of a water tank. it will only show the tank as empty, here are some pics to show you:
2016-07-01_23 30 12
2016-07-01_23 31 30
2016-07-01_23 33 15

as you can see no matter what fill level, WAILA still shows as empty and 0/. i'm not sure if this is a result of railcraft itself but all the other mods within my modpack show properly as far as I know.
here is a link to my modpack for testing if needed: http://www.technicpack.net/modpack/the-valley-testing-phase.797682

commented

Please provide versions of the involved mods at the time this happened.

commented

alrighty:

Waila-1.5.10_1.7.10
Railcraft_1.7.10-9.12.2.0

commented

If anyone cares to point me at the WAILA code that handles this I might be able to do something about it.

commented

@CovertJaguar as far as i can remember Waila made huge problems with showing stuff or keeping stuff synced. So when i made my waila plugin i made overrides and did not care if waila did sync stuff because i did sync stuff myself (the waila overrides are simply config overrides because waila config is unstable)

But to give you an answer on your question:
Waila hacks in to your Code with reflection to get your tank access and read the fluidstack. If the fluid is null its showing the text you have...

now after bulkreading your code i found the issue. Waila is always clientsided (the reading text) and since its hacking into your code it tries to get the server data on the client. Which it does not get provided because you split client & server data. Which is in general maybe a good idea but in this case with Reflection use simply deadly and causes this bug.

In short:
-Waila hacks into Railcraft and tries to use getFluid() (FluidStack) to read the data it needs
-Railcraft syncs its data but on client getFluid() (FluidStack) Seems to be always null

Sry for the long talk around it.

commented

Yes, that is completely the wrong way to go about getting the information and not something that is really fixable on my end (unless someone wants to submit a Walia override, I'm more interested in "The One Probe" myself).

Only the master block sync's its fluid data, not the slave blocks. If you don't go through the Fluid API like you should (which is only present on Valves), you will get meaningless data. But then that should be possible with reflection too, it just sounds like whoever wrote the interaction didn't really test anything or read the code beyond the class headers.

The correct way to get the information is to call getTankManager() and operate on the object returned.

commented

@CovertJaguar you are partly wrong here. He is hacking into Railcraft not the FluidAPI. So he is using the ITank interface which is inside railcraft to get the main tank which automaticly accesses the Master Block no matter where you are... And even through its not railcrafts fault its partly railcrafts fault. Why dont you sync the FluidStack data? and set it into a tank (i see why you did that splitting but its not really nessesary)
So: Its wailas fault not hacking correctly & railcrafts fault to split the data.

commented

Just to give you another Pov of that. Waila is already a broken mod. But the bug here can be fixed from your side and shows that railcraft stuff at least works with it...

commented

Ah! I see the issue, it's because in 1.7 I separate the render information from the tank information.

This should be fixed in 1.10 then as I did away with that artificial separation and just update the tank fluid stack directly on the client.

Thanks for the insight.

commented

It would be great if you could fix that in 1.7.10 too because its a fast fix...
(Leaving a good version behind is the mindset i have in my head)

commented

Fast fix?? Hardly, I had to rewrite at least three separate systems to make it work properly in 1.9.

commented

If from what I can understand it's a simple and easy fix, it would be nice to have that done in 1.7.10, but I can understand if it's better to just do it for 1.10 if that's easier, I understand the major code changes that happened from 1.7 to 1.8 and beyond.

commented

@CovertJaguar well i call it a fast fix for two reasons...
First you already send all data needed (without NBTTagCompound) to the client but you just inject it into the renderData.
Second: Who said that you have to remove the data split?

Here is my simple fix and takes like 2 minutes & you do not have to change much. Actually you only have to change how this function works:
https://github.com/CovertJaguar/Railcraft/blob/master/src/main/java/mods/railcraft/common/fluids/TankManager.java#L122
Simply you create a new FluidStack and put that into the Tank. If the FluidID = -1 you set null into the tank. That is your fix. You can keep the way you keep rendering you had it but waila no longer fucks up with your stuff...

    public void readPacketData(DataInputStream data, int tankIndex) throws IOException {
        if (tankIndex >= tanks.size())
            return;
        StandardTank tank = tanks.get(tankIndex);
        int fluidId = data.readShort();
        if (fluidId != -1) {
            FluidStack fluidStack = new FluidStack(FluidRegistry.getFluid(fluidId), data.readInt());
            tank.setFluid(fluidStack);
            tank.renderData.fluid = fluidStack.getFluid();
            tank.renderData.amount = fluidStack.amount;
            tank.renderData.color = data.readInt();
        } else {
            tank.renderData.reset();
            tank.setFluid(null);
       }
}

Little side note: I checkt all functions / parameters before adding this. So you should be able to just replace it and it should instantly work & fix the problem.