FortressCraft Evolved
Hopper problems.
I've come across two hopper related problems during my current playthrough when I started trying to automate ore smelting:

1. Ore smelters deposit bars into hoppers based on a cardinal direction priority (north, east, south, west, etc.) which causes them to drop bars into ore hoppers. The solution suggested was to set the ore hopper to "remove only" and the bar hopper to "add only", however, this solution prevents ore extractors from filling the ore hopper without conveyers, and conveyers draw those plant sucker enemies that eat your ores. The only solution I have found is to memorize the direction smelters favor and rearrange everything to fit that pattern. That becomes very tedious when you have to wire in power and orient to face an ore deposit as well. The easiest solution I can think of to simplify this would be to change smelter output priority from cardinal direction to machine orientation (how it's rotated), like maybe have it always prefer to output in the back of the machine. That way we can rotate the machine to output the direction we want without locking out hopper input/output.


2. Hoppers that are touching each other level out their inventory when an ore extractor drops ore into them, which is the preferred behavior to maximize storage. However, this action does not take place at all when an ore smelter drops a bar into a hopper. This seems strange and inconsistant behavior to me, as I can stack a bunch of hoppers collecting ore just fine, but I'm limited to only filling 100 bars into one hopper because it won't level out. Perhaps a bug?
< >
1630/32 megjegyzés mutatása
Nekochan eredeti hozzászólása:
I can only speak for most of the early access people since I know them better than the after release people. But there was a lot of moaning about it being to simple, then to hard and then more mobs, more varieties and still to hard or to easy. The consensus though (and forgive me for those who disagree) was that the game needed more npc's, more variety of attacks. And well easy/hard is a 50/50 toss up I guess. Mynocks used to be way harder than they are now, and when we first got them, I think you could power a space shuttle to the moon with the energy from the complaining. Nobody had any turrets ready to defend themselves with lol. I'm not saying it to be mean, but holy crap the ones you deal with are nerfed. A blast or two from a turret that doesn't take any energy worth noting, compared to 5 turrets, constantly out of energy and about 20 or so at any givin time in a small area lol.

Guess what I'm trying to say is that as far as defence goes, its trivial to the point of almost not worth it compared to before.

As for some dedicated need for one side being in and the other out, I guess I just don't get it, hoppers have always worked for me and trust me, I've built some pretty huge logistic setups.
In my simplistic implementation, the only thing I suggested is simply a change to the "round robin" starting point of machinery output to be orientation (rotation) based instead of the "start at north" implementation we have now. That simple change has nothing to do with "this side is input, that side is output". Granted, being able to acutely configure I/O like you suggested would be cool to have, I never suggested we go that far. See, to me, conveyers are a transport medium to get product/resources from point A to point B over distances, and shouldn't be necessary in taking a product from one machine to the next in the production line when they are next to each other.

As for your line "As for some dedicated need for one side being in and the other out, I guess I just don't get it, hoppers have always worked for me and trust me, I've built some pretty huge logistic setups.", why does something have to be huge to be complex? I've created some very tight, compact complex logistic setups in minecraft. In this game though it feels like I need an aircraft hanger worth of space just to do some simple logistics.

Edit: Additionally, why are you even arguing against a simple change simply because you wouldn't use it? I've stated before one exact use (going from extractor to hopper to smelter to output hopper without bars ending up mixed with your ore) which you logistically can't do comfortably, so no, hoppers don't "always work".
Legutóbb szerkesztette: delerium76; 2015. dec. 4., 5:29
Well not an aircraft hanger lol, but I start most worlds with a 9x9 shaft (used to be 11x11 but someone *cough*Dj*cough* lowered the machine to a 3x3) to T2 then another shaft to t3/mass, I have those feed up to a centralized smelting hub which takes up about 11x11x7 in space for 8 fully uppgraded smelters and constant load balancing of ore, which then feeds to my temporary storage area which then feeds to wherever I need it to go. I keep power generatioon centralized above the shaft, attached to machines as needed, and a power tower for the smelters. This way I can divert coal lines effeciently and later upgrade to solar lines for some machines without effort. I know some people like to smelt directly at the ore, but you still have to bring the bars up anyway unless you plan on moving automated machines after each deposit runs out. So I guess its more effeciency vs ease of changes when it comes to putting smelters at the deposits.
DjArcas  [Fejlesztő] 2015. dec. 4., 6:09 
Should probably be worth mentioning that there's actually a 4th method; Storage Hoppers are push, not pull, so it's actually the conveyor putting the item into the hopper, not the hopper pulling the item. I believe this paradigm is across the board (I forget, it's quite transparent from code).

It should also be worth mentioning that I'm not planning on allowing on-site smelting forever, because it's far FAR too bloody good, and completely trivialises the entire 'get your resources back to base' setup. Still rather shocked how few people have done it yet, too!
The "simple" change you are advocating is not as simple programmatically as you think. Right now the smelter has say the "north" (Just an example, not reality) direction as it's preference and then goes on to the other directions. To change that, you need to program in that the smelter has to figure out it's orientation and then choose to look "east" or "west" or "up" or (on and on) and then start doing the directions. In the first example, it is one step because it doesn't care how it is oriented. In the second you have to calculate the orientation and then perform if some direction do this or this other direction do this and so on. It adds a LOT more CPU usage versus the first approach. On my system, when I first purchased the game, I easily met the requirements but the game has grown to the point that I am having problems running it at times so you do this to a number of different machines and suddenly those of us that were on the edge currently suddenly can no longer even try to play the game. If you only do it to smelters then people complain about that and that the game isn't consistent. A lot of work for very little gain, especially since you are the ONLY person to have complained about this issue.

DjArcas eredeti hozzászólása:
It should also be worth mentioning that I'm not planning on allowing on-site smelting forever, because it's far FAR too bloody good, and completely trivialises the entire 'get your resources back to base' setup. Still rather shocked how few people have done it yet, too!

That is how I have always set up my mines. I figure that it's better to smelt the ores into bars and then do whatever I planned with them because it's a four times less of a problem moving on easy than it is the ore. (It was eight times less on easy when I first started.) Now I find out that you will be making the smelters no longer work below like you did with the PTGs so I am going to have to change my approach so when this change eventually goes into effect it wont break my systems. Oh well, luckily I started a new world a week or so ago and haven't gotten to smelting at my extraction sites yet so I can plan around it before it happens. :-)
DjArcas eredeti hozzászólása:
Should probably be worth mentioning that there's actually a 4th method; Storage Hoppers are push, not pull, so it's actually the conveyor putting the item into the hopper, not the hopper pulling the item. I believe this paradigm is across the board (I forget, it's quite transparent from code).

It should also be worth mentioning that I'm not planning on allowing on-site smelting forever, because it's far FAR too bloody good, and completely trivialises the entire 'get your resources back to base' setup. Still rather shocked how few people have done it yet, too!
Ok, fair enough about your intentions. I kinda agree that it can be pretty powerful.



Lions_Den eredeti hozzászólása:
The "simple" change you are advocating is not as simple programmatically as you think. Right now the smelter has say the "north" (Just an example, not reality) direction as it's preference and then goes on to the other directions. To change that, you need to program in that the smelter has to figure out it's orientation and then choose to look "east" or "west" or "up" or (on and on) and then start doing the directions. In the first example, it is one step because it doesn't care how it is oriented. In the second you have to calculate the orientation and then perform if some direction do this or this other direction do this and so on. It adds a LOT more CPU usage versus the first approach. On my system, when I first purchased the game, I easily met the requirements but the game has grown to the point that I am having problems running it at times so you do this to a number of different machines and suddenly those of us that were on the edge currently suddenly can no longer even try to play the game. If you only do it to smelters then people complain about that and that the game isn't consistent. A lot of work for very little gain, especially since you are the ONLY person to have complained about this issue.

DjArcas eredeti hozzászólása:
It should also be worth mentioning that I'm not planning on allowing on-site smelting forever, because it's far FAR too bloody good, and completely trivialises the entire 'get your resources back to base' setup. Still rather shocked how few people have done it yet, too!

That is how I have always set up my mines. I figure that it's better to smelt the ores into bars and then do whatever I planned with them because it's a four times less of a problem moving on easy than it is the ore. (It was eight times less on easy when I first started.) Now I find out that you will be making the smelters no longer work below like you did with the PTGs so I am going to have to change my approach so when this change eventually goes into effect it wont break my systems. Oh well, luckily I started a new world a week or so ago and haven't gotten to smelting at my extraction sites yet so I can plan around it before it happens. :-)
I'm a programmer, so I know exactly what it entails. What you fail to mention is that the code to do this is already in place (for the conveyers) and all of those function calls to do this can probably be re-used from that. If the code is properly sectioned out, these checks will be seperated out and independant of the actual conveyer "class" or function and can be called from the smelter code in place of the code to "look north first". This check only has to be done each time the machine's orientation changes, and a variable inside the object can be set up to store this info to be used when checking outputs. This causes no additional overhead during runtime, trust me. Likewise as DJ said earlier in the thread, the one method that puts alot of strain on the system is "Some machines look at all potential outputs, then make a decision where to interact.(Missile assemblers)", not the other two (and I would agree with that too).

However, the whole point is kinda moot if dj doesn't ever intend on us creating compact machine setups by connecting machines together by hoppers alone, even above ground. If the intended method is to have two hoppers per machine for input and output, and connect all of these clusters by conveyers, then that can be clearly done using hopper permissions, and there's really no point to my request. I'm completely fine with that, I just came in here initially because I have always done things a bit different is all.

Edit: I'm not the only person to have complained about this issue, considering the confusing part has even been mentioned in the smelting section of the FAQ here: http://steamcommunity.com/app/254200/discussions/0/558754899341048392/
Legutóbb szerkesztette: delerium76; 2015. dec. 4., 13:33
Thinking about it a bit, wouldn't it be better to assign a priority number and have the machine store state change? It might cause a bit of a delay in seeing a new hopper but it would allow you to set two add/remove hoppers to a smelter and say "this one takes priorty over the other in terms of pull" and "this one takes priority in terms of push". That would be what you are looking for without locking a direction in at all, simple every say 5 seconds pole the cardinals and store the pointer internall for them. To make current users happy, could even set the smelter for polling in the UI, that way for people who don't need it, everything functions as normal. For people who need it, a boolean can change it to polling and storing.

At the risk of being shot for some bad psuedo

setPolling(b) { Polling_Timer.Start(); }
Polling() { //get each block at cardinals and store poionters in descending order of prioty in Polled_Machines, remember to hook in for dispose event }
GetPolledMachine { return Polled_Machines[0]; }
GetCardinalityMachine() { whatever you do now; }
PullMats() { Hopper m = null; if(Polling) { m = getPoolledMachine(); } else { m = getCardinalityMachine(); if(m != null) {m.DoWhateverYouCurrentlyDo;} }
Legutóbb szerkesztette: Nekochan; 2015. dec. 4., 14:04
That would definately be a working option as well. My suggestion was mainly to create the least amount of coding work for the devs by combining two methods already in use, but your option would work perfectly as well.
DjArcas  [Fejlesztő] 2015. dec. 5., 2:14 
Wait. Who here is NOT a programmer? O.o
DjArcas eredeti hozzászólása:
Wait. Who here is NOT a programmer? O.o
I think you found your target market? lol.
lol exactly. btw, wanted to add that I love what you've done with the game so far. I bought it quite some time ago and shelved it because there wasn't much to do at the time, back before there were enemies that attacked you. I recently came back and I love the "tower defense" additions, and research lab concept. I've logged around 24-36 hours in my current game and still have stuff to do, which is a huge improvement of a couple hours and done when I first got it. Keep up the good work!
oh yeah, I wanted to add that I tried out the ore leveling method, but cubes don't auto-level between hoppers if one of them is set to remove only, so that solution didn't work for me.
DjArcas  [Fejlesztő] 2015. dec. 5., 3:31 
delerium76 eredeti hozzászólása:
oh yeah, I wanted to add that I tried out the ore leveling method, but cubes don't auto-level between hoppers if one of them is set to remove only, so that solution didn't work for me.

They'll level only in one direction; auto-levelling obeys hopper permissions.
DjArcas eredeti hozzászólása:
delerium76 eredeti hozzászólása:
oh yeah, I wanted to add that I tried out the ore leveling method, but cubes don't auto-level between hoppers if one of them is set to remove only, so that solution didn't work for me.

They'll level only in one direction; auto-levelling obeys hopper permissions.
Yeah, I was just pointing out that it doesn't solve the problem of bars going into the ore hopper while still allowing an ore extractor to be attached to the hoppers without conveyers. that's all.
DjArcas eredeti hozzászólása:
Should probably be worth mentioning that there's actually a 4th method; Storage Hoppers are push, not pull, so it's actually the conveyor putting the item into the hopper, not the hopper pulling the item. I believe this paradigm is across the board (I forget, it's quite transparent from code).

It should also be worth mentioning that I'm not planning on allowing on-site smelting forever, because it's far FAR too bloody good, and completely trivialises the entire 'get your resources back to base' setup. Still rather shocked how few people have done it yet, too!

does this mean we wont be able to use smelters underground ?
DjArcas  [Fejlesztő] 2015. dec. 5., 7:21 
hmkagm eredeti hozzászólása:
DjArcas eredeti hozzászólása:
Should probably be worth mentioning that there's actually a 4th method; Storage Hoppers are push, not pull, so it's actually the conveyor putting the item into the hopper, not the hopper pulling the item. I believe this paradigm is across the board (I forget, it's quite transparent from code).

It should also be worth mentioning that I'm not planning on allowing on-site smelting forever, because it's far FAR too bloody good, and completely trivialises the entire 'get your resources back to base' setup. Still rather shocked how few people have done it yet, too!

does this mean we wont be able to use smelters underground ?

Eventually, but not without plenty of warning. On-site smelting means that the ENTIRE logistics part of the game can be skipped.
< >
1630/32 megjegyzés mutatása
Laponként: 1530 50

Közzétéve: 2015. dec. 4., 1:26
Hozzászólások: 32