2.0

  • Added 2 new materials
  • Added 1 new ore block (Titanium)
  • Added 4 new turrets
  • Added 2 new player weapons
  • Added liquids, conduits and pumps
  • Added extractor blocks
  • Added 3 new armor blocks
  • Added 3 new enemies
  • Added 4 different enemy tiers
  • Decreased enemies per wave, but increased health and damage per enemy
  • Added multiple placement modes (on Android)
  • Increased drill speed, but increased cost (this should help prevent item lag, as it is now harder to spam drills)
  • Halved cost of most blocks
  • Fixed crash caused by junction block
  • Changed block selection UI
  • Changed title screen and logo
  • Many UI tweaks
  • Added pause toggle (space, by default)
  • Allowed player to place blocks while paused
  • Removed zoom buttons, scrolling is now done with the scrollwheel
  • Changed terrible weapon sprites
  • Changed weapon selection to only use number keys or clicks
  • Made some blocks replaceable (e.g. steel walls can replace stone walls)
  • Fixed turret prediction being inaccurate
  • Changed turret names
  • Many, many other bugfixes and tweaks

As always, please report any bugs you find! This release should be more unstable than usual, due to the amount of content added.

Files

Mindustry-android-2.0.apk (23 MB)
23 days ago
Mindustry-mac-2.0.zip (52 MB)
23 days ago
Mindustry-linux64-2.0.zip (52 MB)
23 days ago
Mindustry-windows64-2.0.zip (50 MB)
23 days ago

Get Mindustry

Comments

Log in with your itch.io account to leave a comment.

Found a mistake: Titanium Extractor description says it outputs coal not titanium.

And a bug: the game will crash if you remove a conveyor, leading off a junction, as the junction is outputting onto the conveyor.

Also, I mentioned that the turrets were firing wildly off target in version 1.5, you said it was a mistaken in the maths. This is definitely fixed as of 2.0 for the old turrets, but the newer turrets seem to be suffering from the same, or a similar bug. This is most obvious with the Flak, sometimes firing 90 degs in the wrong direction. Could you have copied the erroneous code to the newer turrets before applying the fix?

(Edited 1 time)

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.

(Edited 1 time)

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?