hugo_the_dwarf

Like I mentioned the fuse box actually does all the scanning, and mapping + route making. So the fuseBox tileEntity will hold these lists (and save so on world load and such) then a machine will look for a fuseBox (note only things that *need* power will look, special cases are if you have a powerStorage that can input and output) the machine will access the fuseBox's list of powerSources (remember I was going onabout saving the location of a powerSource and the route of cables(that you would find with A*)) and try the route (check to make sure all cables still exist, and that the 1st and last connect to the fusebox(1st) and emitter(last). Since A* I would think you'd start from the box and go to the emitter) if the route is still good, attempt to draw power, if that is good well draw power, if either of those clauses fail, move to the next "powerRoute"(which is a different emitter, that may, or maynot share the same cable route) in the cases where the machine can't find a route the fuseBox should be notified about this to A) try to find a route, or B) in the case of a broken or false route, reroute. And if that fails remove from the list normally the fuseBox will every now and then ensure that everything is up to date (cable map is still good, or say fk the map and check the cables whenever needed (that will be one less thing to store in memory) and routes are the only saved cable lines) it will also check for any new emitters or machines and ensure that there is a route, and if there is one, is it still good. But that should probably happen every min or so. Also do you mean nodes are the emitters (generator, battery) or you mean like a RL network (Modem, Cat-5 cable, switch/router, cat-5*ports+targets,target) the switch/router being the node? or are you thinking that each Node will keep a list of everything connected to it? (Node 1 is connected to 2 generators, and Node 2 and 3) then a fuse box can say "well to get to generator 2, to power machine 1(machine one being connected to node 4) is I have to route power through nodes 4, 3, and 1 all the while getting the fastest cable route between them all?

actually replying to your final post, and idk if you saw mine. But by default it shows the 1st 24 replies, you then have to goto page 2... or all.

not saying TGG is wrong, but if you need somewhere to hold the network why not a block that does just that? The fusebox hold all the mapping information, and routes to machines and power sources, and only things that need power will make a request to the fusebox, and the fuse box will check to see if it is valid (connections, etc) and send the response. That way most players will have 1 fusebox, and just hook everything to it, plus you can have things like fuses that might blow if too much power is going through it . kinda like how IC has machines explode if too much power goes to them, only now you have a chance to prevent that with fuses. Either way it is whatever works best for you and the mod.

If (!world.isRemote()) { spawn creature; } isRemote gets true if client, false if server. So make sure the world is serverside and spawn it.

@Override public String getUnlocalizedName(ItemStack item) { // System.out.println(getUnlocalizedName() + "." + // names[getDamage(item)]); return getUnlocalizedName() + "." + this.names[getDamage(item)]; } you then have a String array called Names and in the getSubTypes just add each name into the array add the subtype names, then you can add them into your .lang file with the "item.unlocalizedname.subname.name" I crossed out my error, I am working with another modder across the world, and he reformatted my code. which made me miss the fact that I just declare my string array at the start.

I guess could do it with another block called a "fuse panel" or "circuit box" that will do the mapping and routing and hold the lists, then nearby machines, nodes, emitters will look for this controller. And have something that if another fuse box is placed too close it simply does nothing to prevent the same list from being populated (this will help stop griefer's from abusing your mod to ruin servers.)

Oh by route I mean "the fastest or first line of cables that connect the emitter to the requester" once it has a route it just saves it to the list and moves to the next emitter to make a "route" until it finds all routes for all emitters. There probably should be a check for each cable to make sure it was included in the map (if even use the map) because if the requester wasn't connected to that cable in the first place, why bother trying to find a route? And then another issue I thought of, is since all these are saved, and not checked every time (in the premise of hoping that saves on cpu and lag reduction, at least that is how I see it, I'm sure a more experienced programmer will tell me else wise) how will it know a new cable was added, or an emitter? It's easy to tell if a cable was removed (posted a cleanMap method) but what about subtle additions?

looks like A* would work nicely however how many loops (or recursive calls) would have to run just for each route? now of course with the weights it would for sure help it decide the fastest route, so combining both would make it work to the best effect. I wouldn't mind if you shared the finished code with me (of course when I get around to using it, or improving it I would of course share those changes with you ) but it seems you have everything you need now

Now been thinking about this, can only post a little have to run off to work. But I don't think the distance needs to be saved because like the issue of "what if there are no straight lines, but some needlessly complex cable route, with dead ends" With the way I was thinking "E" is emitter and "R" is requester and with the cable weighting system that I "thought" of would probably fail pretty hard (unless you can work off of it and get something working) because the weights would be: Now that is only a side view of X and Y (staring down the Z axis) the player could also have some dead end branches at certain places. So either the cables need to save their "weights" of distance of an variable that increments (and not a calculation of distance, but a count of hops) that might work better because then dead-end cables that flowed out from the initial path would be weighted higher then the true path. Because the best way would be for the emitter to create a route or the requester to start from the emitter and work back to the requester making a path (saving it as an array) as it goes to save in the arrayList of PowerRoutes that way when it needs to draw power from that emitter, it can check to make sure all the cables are there (if one comes up as null or not the right cable, delete that list and/or try to make a new route)

Part2: Going to spoiler this whole post: "Also not to self, this is harder then I thought"

Seems like you have quite a complicated location class (not that it's bad, or hard to understand.) I personally try not to save a tileEntity (as I have no idea what happens if it changes, does it update? Is it only a reference?) I just save its "last known coordinates" and "get" it when the time comes, that way I will always know it is fresh (because I got the newest update of it) and can make sure it is still there. But how I would set it up would be: Ok i'm going to have to make another post this is too long.

DrawPower() { TileEntity te = getWorldObj.getTileEntity(x,y,z); if (te instanceof MyEmitter) { //Do draw power stuff } else { system.out.println("Oh snap, that's not a emitter!"); ArrayList.remove(where this was stored); } } I mentioned about making a tempArray that the cables can reference, so Cable1 finds Cable2. Cable1 adds itself to the list (personally the machine/requester should do this) and adds Cable2 to the list. Cable2 then finds Cable1 but before saying "search command" it checks the arrayList to see if Cable1 is already in there (which is should find) it will then say "ok no need, but am I in the list?" check list to see if it is in there, add self if not (likewise personally if it started at the requester the cables won't need to check or add themselves, just the new found cables) then look for Cable3. But I had mentioned a list of "Routes" these would be saved to each emitter (Route 1 and Emitter 1) so when the machine needs to draw power it will choose route 1, (which goes down each cable making sure it is there). Also remember I mentioned about a class that holds the x,y,z and distance variables? each point of distance can be used as a weight and your "cable range" TGG has a good points there too, altho I don't understand nor used those methods.

what does your upgradeStat method look like?

yes I am using a tessellator, I just wasn't sure where I had to set the color considering everything is done in the matrix then popped back in. EDIT: works like a charm, now just to do some maths while putting weapon effect layers on too (don't want an effect colored, just the base object)

Title kind of doesn't do this justice, Right now I have a itemRenderer for my customizable weapons (players can make these weapons and change how they look by swapping out blades, guards, and handles) that works fine, but I want to know how can I have certain parts be colored like vanilla renderpass methods. Atm I looked at how tinkers construct made their tools and looked at how coolAlias resized his weapons (or how he does it, he posted it somewhere) but I realized they both don't have anywhere that colors the parts. I was hoping to have a few parts like handles and guards be greyscale so players can pick from a range of color choices in the gui for it. I just don't know where I would make the change, I know looking at the vanilla ItemRenderer class there is a spot that gets the display color NBT from the stack, and extracts the 0.0f - 1.0f color value and tells openGL to draw with that. I'm not sure where I would make the "check color, GLColor3f(r,g,b);" calls. Just don't want to make an extra 10 or so versions of the same handle/guard to show different colors (T-Construct may be happy with that, but I prefer something more dynamic)

Well my idea was to have a ArrayList<ofThisThing> public class ofThisThing { public int x, y, z, distance; public ofThisThing(int x, int y, int z, int distance) { this.x = x; this.y = y; this.z = z; this.distance = distance; } } will probably be a temp array (so put it in the scope of a method) you could also make a class called "Route" and it stores a path of cable coords to an emitter but more on that later. you will also need a helper method to calculate distance easy probably something like private int getTotalDistance(cableX,cableY,cableZ,requesterX,requesterY,requesterZ) { return ((cableX - requesterX)+(cableY - requesterY)+(cableZ - requesterZ)); } now this is where I get stumped, because you will need a recursive method that calls itself for each cable found, but also references the list of "already found and weighed cables" the requester will send out a "search" command to all attached cables, and these cables will send out "search" commands to all attached cables (but also look for emitters) I have no idea what damage something like this can cause. But you shouldn't have the cascade splash back it should always flow out to cables not already found. If that makes sense?

I've been trying to post a theory or an idea on how to do a weighted cascade to compliment choice no.1 but my logic just contradicts itself. I know Jabelar posted in your other thread about the idea of the cables updating themselves using meta data. 0-15(16 total) I think your best bet is to look at how redstone works and engineer that functionality to your cables, emitters and requesters

depends on how you want to do it, you can have the tileEntity check all stored known nodes every now and then. Or when it needs to access the node it checks to see if it's still there/valid

this is why you have a check to make sure that what you got is what you wanted and is not null. Normally if(tileEntityGotten instanceof TileEntityMyTargetType) covers null and well your TE. if that passes and goes in you can then use TileEntityMyTargetType targetTe = (TileEntityMyTargetType)tileEntityGotten; targetTe.doWhatEverItIsThatPleasesYou(); now if you mean you these tileEntities have to be unique (place one, use item to save it's location, someone breaks it and places it down(new tileEntity, same location)) then I am not sure how to deal with that, I guess you could have that tileEntity store a special number or code in itself and the item that records it. Then when you right-click or activate your recorder item it loads up the tileEntity, checks the instance (covers null aswell) if that pans out, check the special ID in the tileEntity and match it with the one in the recorder. If that fails clear out the info on the Item (because it lost its tileEntity)

just write the TileEntities coords into the itemstack. then all you need to do is get them and find the tileEntity usually "World.getTileEntity(x,y,z)" the method "onItemUseFirst" on items should help you grab your tileEntity as this method gives the blocks coords that you right clicked from there you can make a check to make sure the tileEntity you got is the one you want, then write the coords to NBT, and the next time you use it you can check to see if you have coords written, get the tileEntity with the coords and do your thing.

some how I missed your first reply about this jabelar, but now I have a question, just thinking about the worse. What if he has one cable line that connects to two sources? one source has power the other is empty, what does it do if it finds the empty one first?

Actually I told you how to get started on it, if you get the disX,Y, and Z (these 3 variables are the result of This.xCoord - Source.xCoord, etc.) if the disX is 6 and disZ is 1 the fastest way there is over 6 up 1 (if the cables were in straight lines. Also since those are global coords the fastest route would be 6) now if we say the fastest way to the source is 6 hops if you are wondering where I got the idea of 6 is because it's (horizontal -1 + vertical) this is cables i'm talking about like I said before the fastest way from A to B is a line so imagin this layout + ------X this is the -6 disX and -1disZ lets just say disY is 0 for simplicity sake. Since cables can connect to any adjacent cable/machine/source we can go over 6 because it will still touch the source. but even if the layout was: +-- ----X that is still 6 cables, or 6 hops. Essentially you can use for loops to try and find a correct route or maybe a single While loop that has counters. Something that can run a scan for each possible route (Is 6 in a line left reach the source? no, does 5 over 1 up work? no, does 4 over, 1 up, 1 over work? etc. etc.) untill it exausts it's final attempt of what about I try a line from the disZ +------ X if that fails try the cable crawler method with a direction to help it along the way with my example it knows it is -- (-x and -z upper left) this will go the slower route of here's a cable, is it connected to the left (-x is greater so that is a preferred start) or connected to the top to another cable. If all this is all too much or you take about a week or more and want to give up. Just have the machines "magically" connect to the power sources and make a visual rendering of cables (like how the lead or fishing rod makes a rope/line)

in your posted code you have some copyPasta errors if ((!nodeXpos.contains(x))) { nodeXpos.add(x); } if ((!nodeXpos.contains(y))) { nodeXpos.add(z); } if ((!nodeXpos.contains(z))) { nodeXpos.add(z); } they all add into the same array list. Also you will probably run into an issue since a cable or a line of cables can share all the same x/z locations and a column y locations I made my own class object for a base building system public class UtilityBlockLocationType { public int x,y,z,meta = 0; public Block block; public UtilityBlockLocationType(int x, int y, int z, Block block) { this.x = x; this.y = y; this.z = z; this.block = block; } public UtilityBlockLocationType(int x, int y, int z, Block block, int meta) { this.x = x; this.y = y; this.z = z; this.block = block; this.meta = meta; } } you might be able to do the same so you would only need one arrayList ArrayList<CableLocations> cables = new ArrayList<CableLocations>(); then your tileEntity that needs power will collect all nearby cables. But I have a better logic Idea. Your tileEntity will look for all powerSources a certain radius away (15 blocks?) in all directions, when it find a tileEntity it checks to see if it is an instanceof PowerSource, and saves those coords (x,y,z) once that is done it should have all powerSoruces in a 15x15x15 zone now it will go through the list, 1st PowerSource before anything, check to see the distance between them disX = (this.xCoord - powerSource.xCoord) disY = .... you should have all the distances now. We all know the fastest way to point A to B is a line. So you can probably make an algorithm or something that will check all the "fastest routes" to the power source making sure that there is a cable block there if not try another fast method until idk 4 times if that fails use the go down all cable blocks route?. if it finds a route that is all cables, it will save the route and reference it to the power source as a list or array. reason for saving the list of cables is so when Machine needs to draw power, check 1st powerSource, has power good, check each cable in the cable route list, if one is missing try to reroute and resave the list. If can't find a route cancel and move to next power source. maybe strike the first powerSource off this list or something. oh and each time a cable block is attached to the machine it will recheck all connections and look for new powerSources. Now my logic is most definitely flawed but some aspects can be used. I just hope it can inspire you or help you figure this out.

Actually you can use normal variables in a tileEntity and get and set them with that, If you make them public it's as simple as "TileEntity.variableName" if you make it private and you have getter and setters it'd be "tileEntity.getValue()" and to read and write the NBT (for saving and loading) @Override public void readFromNBT(NBTTagCompound nbtTag) @Override public void writeToNBT(NBTTagCompound nbtTag) you do your saving and loading in the respected methods.

Had a look, seems like this level of modding is out of my reach for now. Hopefully in the mean time, this topic will be found by those searching and can get going from your suggestions. Thank you.