Currently uploading a fix to all of the issues, except the ones with turret prediction.
I attempted to reproduce the bug, but while the turrets were slightly over-predicting enemy movement, I didn't see any major problems with them. And, no, the prediction code is the same as for other turrets'. Was the inaccuracy, perhaps, happening at very close range?
Can you specifically test the Flak turret - from what I see it rarely hits - it is the only turret where you have added an overPrediction variable (is this to simulate inaccuracy?) I'm not sure why this is necessary. If the algorithm is correct, and the target doesn't change velocity, then it should always hit and not require any over prediction?
I did test the Flak turret, and added the overPrediction variable to it yesterday after seeing that it tended to, well, over-predict. After checking the enemy and bullet velocities to be correct, I tested again (today), and it seems that the prediction fudges up most when (1) the enemy is one of the "fast" ones and it's moving at least 45 degrees while the bullet gets there, or (2) the enemy has just gotten in range and the turret fires almost immediately without rotating all the way toward the target. However, even after completely removing "smooth" rotation and/or adding a condition to fire only within 1-2 degrees of the target angle, the inaccuracy persisted, so that can't be the main cause. I ended up removing the overPrediction variable, since in some cases it tended to under-predict as well.
You're right that there shouldn't need to be any tweaking necessary, but at this point, I have no idea what's causing the inaccuracy and it would be easier for me to just buff the mortar turret in some way to compensate for this, instead of spending hours bug-hunting.
Okay, fair enough. The only obvious things I could think of are the turret not rotating fast enough to track the enemy, or perhaps your algorithm is not targetting the centre of the sprite/hitbox, but one of the corners. Anyhow, I spotted a few other things.
1. You cannot chain junctions, i.e. two junctions next to each other will block up the transport of materials. Not sure if this is deliberate or not, but I've had scenarios where this would be useful.
2. Increasing the cost of drills does not prevent drill spamming, just makes the first few minutes of the game a bit of a grind while you slowly build up your stone industry. I think the conveyor and router speed / capacity limitation is a better way of moderating resources, and already works pretty nicely. Ultimately the more you add to the game the more difficult it'll be to balance. The extractors were a really nice addition though.
Nope, it's not that either. Even with instant turret rotation, they're still somewhat inaccurate, and I made sure to target the center of the hitbox.
1. This is intentional. My reasoning was that player could theoretically chain a bunch of them together in a line and use them as faster conveyors, which was undesirable, although I never tested whether this "exploit" was actually viable. I guess I should enable it now?
