Network values not being evenly distributed among conduits.

[KeeganDeathman]

So i have it so that the tubes for my particle accelerator need to be in a ring. They also deduce their shape by the surronding blocks, and then tell the next tube there is a new straight or corner, and that tube tells the next, and that tells the next, coming back around until the chain finds a tube that already has the correct number of that kind of tube, the first one. But in my testing, the tubes in the ring don't all carry the same values, mostly around corners is when values are lost in transit.

Heres the class, it all starts in the updateEntity.

https://github.com/KeeganDeathman/DeathmanLabsStuff/blob/master/main/java/keegan/dlstuff/tileentity/TileEntityAcceleratorTube.java

[TheGreyGhost]

By crikey dude, there's no chance of me helping you debug that without some proper commenting to explain the algorithm you are using.

 

-TGG

[larsgerrits]

...

Heres the class, it all starts in the updateEntity.

https://github.com/KeeganDeathman/DeathmanLabsStuff/blob/master/main/java/keegan/dlstuff/tileentity/TileEntityAcceleratorTube.java

Well, where is the updateEntity method?

[KeeganDeathman]

Oops. That ones a little outdated.

Try it now

[jabelar]

It's cool what you're trying to do and the approach seems sound, but it is hard to get interested enough to crawl through it to look for logical errors. I think you should just perform standard debug practice -- put console statements at all the critical points in the code to confirm its operating as expected. Alternatively, use a debug mode of your IDE to watch the values of the fields. I'm sure you'll quickly see the problem if you just trace the execution.

[KeeganDeathman]

Ive tried the standard debuggin practices, but, I can't seem the find the problem.

I'll keep looking though

[TheGreyGhost]

Ive tried the standard debuggin practices, but, I can't seem the find the problem.

I'll keep looking though

I reckon the first thing you should do is to write down a couple of paragraphs on how the algorithm is supposed to work.  Maybe draw a sketch on a piece of paper too.  You might realise halfway through you've made a wrong assumption.

 

-TGG

[Draco18s]

Maybe draw a sketch on a piece of paper too.  You might realise halfway through you've made a wrong assumption.

 

Been there, done that.

My last one was arranging a series of rectangles so that none of them overlapped.  As an optimization, I told it to only move the rectangle (between an overlapping pair) that was farthest from the origin, and to move it in the direction closest to making it not overlap.

 

It hit an infinite loop with a set of 3 in a specific arrangement, where the one being moved overlapped with two others both closer to the origin, and both wanting to move the interloper in opposite directions.

 

So I had to track "lastMove" and compare with "currentMove" and if they were diametrically opposed, just make it move in the same direction as "lastMove."

 

Then a little while later I buggered up x/z/y as x/y/z (due to a 2D vector operation accepting a 3D vector and ignoring Z when I actually wanted to ignore Y; I could refactor it, but this code editor is shite at refactoring).

[KeeganDeathman]

1) the tile entity runs the updateEntity method

2) The method calculates whether a section of that pipe is or should be rendered by checking for appropriate blocks around it, and assigning booleans about that(up, down, east, west, north, south) we also save the current type to an oldType string

3) The if statements come in. First we weed out the invalid pipes, those going vertical. Then we check all legal configurations and assign the tubes "type," whether it be straight, ne, es, sw, or wn, or invalid, if it is illegal. Then we check if the type changed at all by comparing the oldType and current type. If so, we check if it's a corner or straight, and call the appropriate function on the next tube, based on a function that checks for a tube in order, posx, posz, negx, negz. It also checks 2 over on the Z in account of the detector core, which will always be on the z line. It also adds one to the apropiate internal counter of straights or corners, and updates the aporiate boolean of if it has(insertCornerTypeHere) if it is a corner

4)The addBlahBlah function adds one to the correct counter if it would match the source tubes count. If not, it finds the difference, and adds that. After that, it sees if the next tube doesn't have the right number, and calls the add function on that.

All is saved to the NBT of the tile entity, where I can see if the function works. It appears all is well, but the add function doesn't seem to make it around corners.