I was doing it wrong just to be short. Long story though when calling
for the addon to render you can't do any of the normal GL11 call for
changing the location, scale, etc., or at least not the way i was doing
it. Only thing the addon creator should need to do is call for the part
of the model to render connected to the pipe core.
Still haven't got the pipe addons to work client side. I think it has
something to do with a packet handling issue but i can't tell yet. As
well some method are not getting called right in the sub tiles.
Has not been tested yet so most likely i will need to make more changes
to this code to prevent error.
Also i added some packet code to update the client with the new
TileEntities
Added Tick updating to the pipe addons
Added packet sending for the pipe addons though reading packets still
needs to be done
Added IPipeExtentionRender interface so the pipe render can render the
pipe addon on one of its sides.
A pipe addon will be a sub Tile that will attach itself to one of the
faces of a pipe. Then the pipe will store, and update this tile as if it
was a real TileEntity.
Fixed pump pumping flowing sources, next step is to make a lava pump
Fixed connection issue with tanks and pipes. Not sure what the cause was
but i remove some code i added to the prefab fluidStorage class just to
be safe.
spent an hour looking for that bug and it turned out to be a missing !
(FacePalm). Though it did lead me to correct a missing ForgeDirection in
the on block activated code.
Go rid of LiquidData.class. Had my reasons for its use to store
pressure, name, colorcode, etc. However, the new system doesn't need it
and there are other ways to store the data i need. As well i no longer
need to store the string name as LiquidDictionary can get the name for
me
Cleaned up and changed a few classes after i added the prefabs. The tank
and sink now use the FluidStorage prefab to make them easier to read.
Sink basicly went down to packet code. Tank will do the same later after
i add in Code to turn it into a fluid network of its own. Also toyed
with release valve but nothing major changed
This was a cool idea to prevent NPE errors in the api however its
leading to other issues. This could be with how i was using it but it
just needs too go.
Got it for sure this time though it looks like i need to fix the
autoDrain method some more. As well prevent the fill method from trying
to refill the source of the liquid.
Pipes on each connection update should try to drain liquid from there
connected sources. I'll improve this later to limit the network from
getting surged all at once.
Also fixed, i think, the network saving its stored liquid to all
connected parts that can stored liquid. There still might be a bit of a
lose but i'll fix that later
At this point i'm a bit lost on how to do pressure in the system. I know
that the pressure will decrease with each part in the system it pass
threw. Which means later i'll need to add a path finder to simulate
this. However, right now i can't figure out how to do pressure produced
and pressure load needed. The only way i know is with one source of
pressure but in minecraft people will not just add one source of
pressure for a system.
Now that the new network pipes function up to the same level as the old
pipes its time to retire the old pipe. Only thing left too do with the
new pipes after this is too refine the code, add PSI methods, and make
it more compatible with other mods. Though as far as i can tell it
should work with other mods. However, if a mod doesn't use some methods
right then the pipes will not fill them as fast.
I believe i am now using the built in update system that sends a
description packet if the block is marked for update by the game. This
should simplify it a little and i think correct a few other errors with
updating server side.
The fluid network use the get tank side method to better find which
tank to fill first. However, i neglected to use this method correctly in
the tank and most likely something else but I'll get to that later.
as cool of an ideal as it was it didn't get used as much. As well if
someone wants they can check the connecting pipe's colorCode for stack
info or threw some other way.
fixed model rendering north and south connector wrong
fixed water gauge not rendering with a texture
changed read out string for the tank to use a formatted string
Still haven't fixed that odd error with the connector rendering on the
wrong face. Though the plan is to remove the connector render as you
can't see it past the pipe.
for now I will just use it for connection rules for rendering, and trade
processing. However, in the future i might use this with the path finder
to make a more uniform movement of liquids in the connected tanks. Might
even have them update all as one entity instead of each one at a time.
Though that will take some time if i set it up just like the UE wire's
network. As i will have to make sure that the liquid always travels to
the lowest tank first, and saves to the lower tanks. Which means that
i'll end up storing the tank's Y pos or getting it during
saving/loading/processing.
*changed how it sends packets to only update if something changes or at
random points in time.
*changed the getColor() to use the blocks metadata and not a var
*added code to the setColor to change the blocks metadata
*Fixed load function to not set content if it read as unkown
Changed name of network part so save me from miss typing it every time
Fixed connection rules for pipes so that they will connect and render
Fixed networks merging and not crashing on merge
Fixed pipe gauge item's texture so it showed
Added a render for the network pipe (temp_use)
Bug connections/networks don't update on load just yet.
My network code is about the same as UE's short of the fact i have to
still ably to net.minecraftForge.Liquids interfaces in order to keep my
mod compatibly with other mods. So its only logical that my network pipe
updates, reacts, and works the same as the UE conductor. Though i will
be making change to mine in order to have it function with liquids more
and more.
removed the old canConnect methods from every class that used it and
replaced it with the new one still matching how the class used the old
one. Though i'm concerned that the new method might increase processor
use a bit since it sifts threw all stacks that the pipe can handle
instead of the first valid one.
this will not be easy as i've forgot some of my hydraulic's class. As
well if the pressure or load changes i have to update the entire network
to the change and recalculate the network's pressure.
