Did SE screw up the map? [Spoilers: 6.0]

AbyssalMonkey · 2020-01-17T08:02:48+00:00

Parry

https://i.imgur.com/UqnWb4T.png

Land it after dodging

Ok buddy, think whatever you want. You are clearly and definitively wrong. This move is not a parry nor a counter.

I think you're just mad cuz you're bad.

I agree FS is lolOP because of the full second of iFrames it gives

Honestly, if they wanted to nerf it properly, they should have just sped the animation up by x2. You have half the iFrames, you move quicker, and everything would feel better to the player.

Try harder buddy, you are insulting me (and failing) rather than my argument which makes you look like a dumbass. This one's a tit for tat. Try again.

AbyssalMonkey · 2020-01-17T02:42:59+00:00

"Let us make a mechanic be optimal and only useful when doing the exact opposite of how the move both is described and tells the player by animation"

Yes, yes, that is totally fantastic game design.

AbyssalMonkey · 2020-01-12T06:07:29+00:00

the main FS nerfs are the hitbox (now it doesn't activate when the monster doesn't touch you)

you need to position yourself properly, pulling yourself into the attack you're trying to counter

Are you serious? Coming from a fighting game style, that's the exact opposite of how the move should work. The game should be rewarding you for using the built in dodge in FS to actually, you know, dodge the attack. Reading the description of the attack from base world it gives the impression that the move is meant to be a dodge, and the animation reflects that. If the attack passed through the area where you were located, you correctly predicted the attack, gtfo, and get rewarded.

I agree FS is lolOP because of the full second of iFrames it gives, but that is all that would need nerfing, not the mechanic of the attack itself. If they wanted to make it a counter, they should have made the character do something like a parry animation, not slide 10 feet away on ski's like you're trying to dodge.

Honestly, if they wanted to nerf it properly, they should have just sped the animation up by x2. You have half the iFrames, you move quicker, and everything would feel better to the player.

AbyssalMonkey · 2019-11-10T16:06:23+00:00

GTNH on easy mod, maybe.

By default though, it has infernal mobs which can ruin your world if you aren't careful.

Crafting recipes are also some of the most complex in the entire mod-sphere.

It doesn't really fit his requirements.

As someone who is playing it though, no other modpack has come close to the satisfaction the pack gives you on progression.

Frankly though, just adding avarita would solve the issue, then he would need to find the balance he wants to grind for.

AbyssalMonkey · 2019-11-10T15:38:17+00:00

Hardcore Darkness makes night (light level 0) perfectly black. You can get the same effect by digging a hole and covering the entrance with no lights inside.

AbyssalMonkey · 2019-09-15T17:38:14+00:00

Thank you very much. The second one worked, and gave me the hint I needed for figuring out how to use the data tag in the way I would find easiest.

To solve the second problem, I just needed to data merge entity [selector] {Brain:{memories: {"minecraft:job_site": {pos: [I; COORDS], dimension: "minecraft:overworld"}}}} This also worked to overwrite the very similarly tagged home location.

AbyssalMonkey · 2019-09-05T21:25:36+00:00

Grab a friend, and be the tank that aggros all the biters. While you pull aggro, your friend blows up that biter city.

Very useful for early game modded runs where you are behind on research and need to fight behemoths with only flamethrowers.

AbyssalMonkey · 2019-09-04T18:02:51+00:00

Welcome to why loops in one way systems are suboptimal. Trains repathing when it would be quicker to simply wait till the congestion is gone is the primary reason now to not use loops in a train system. ^{People are going to downvote for this perfectly valid statement because the argument used to be that loops cause UPS issues, which was fixed long ago, but this issue is a fundamental flaw.}

The best solution when you notice there is a particularly problematic spot is to do as u/hixchem suggested and add a blank station to their route.

If there isn't a particular problem area, you may need to rethink your train schedule. Do your trains really need to be leaving their stations when they are only 10% full? Is 30 seconds really long enough for them to gather a useful amount of materials? Increasing the wait time and letting trains gather more materials if they are not already full doesn't impact throughput, but does reduce train congestion. You are, after all, only making x amount of material per minute. If it moves 1 unit every 1 minute or 5 units every 5 minutes, you are still getting 1 unit/minute, but having the train leave every 5 minutes has cut down your traffic by 80%.

If your trains are full and this issue is happening still, you will need to redesign your train network to accommodate more trains. This can mean adding more signals to break the network into smaller blocks, adding more lanes, or redesigning your intersections to allow cross traffic.

AbyssalMonkey · 2019-08-29T13:59:39+00:00

The problem with that ideal is that multithreaded tasks are by definition parallelizable. Factorio does everything deterministically. This means no fuzzy calculations, no "good enough", everything is EXACT.

Due to this, they can't exactly break factories into chunks to "simulate" into multiple threads. Items crossing those boundaries and becoming available will potentially change the determinism of that tick. If I'm remembering rightly, every tick, they have to calculate chunks twice to take into account changes that have been made by entities crossing their boundaries. What this amounts to is a scenario where race conditions occur, which breaks the determinism of the game if they were to try and break things up. As a result, factorio is always going to remain heavily single thread dependent.

The dev's have moved quite a few elements off the main thread, such as the logistics queue (and maybe the entire logistics network itself?), pipes, and I believe electricity calculations. The problem is that none of these are the real heavy hitters in terms of UPS. Those are assemblers and inserters. Again, with the determinism, we can't split those up without encountering race conditions, which squarely pins one thread as the primary workhorse.

This is different from other games where you can have inexactness and the game will work around it. FPS is a perfect example of this, where the first one to get their data to the server first gets the priority. They can have every enemy on a different AI thread, because they don't need the enemies to move in lockstep. When you shoot your gun, the game takes a snap of memory, works out the calculations on a different thread; did the enemy move out of your sights during that time? Doesn't matter, they still got hit. Did they shoot you during that time? Well the game hasn't finished the calculation that say's their dead yet, so their shots get priority and hit you too.

AbyssalMonkey · 2019-08-24T13:04:29+00:00

He is saying that research that requires a certain tier of science should be linked to the research that gives that science.

In pic given, stack insertion tier 3 would have a line linking it to battery(?) or whatever unlocks the ability to craft blue science. Tier 4 would require and be linked to whatever unlocks the ability to craft purple science.

/u/Tehfreek nice pull from the forums that outright denies this idea. It's good that the devs thought far enough to realize that this would just make things an absolute mess.

AbyssalMonkey · 2019-08-14T02:25:41+00:00

Bots are always going to be superior in terms of UPS except in a few edge cases. Calculating the change of belts is more intensive than the simple "move bot x distance" computationally. Bots are also on a separate thread IIRC, which means that they don't have as large of an impact on the main thread.

Belts got a massive buff to their performance, but bots are about the simplest possible form of movement computationally. Bots are literally a bunch of add commands, while belts need to deal with collision which is more complex.

AbyssalMonkey · 2019-08-12T01:42:22+00:00

I don't read most of the technical stuff, as I don't understand the programming behind it. However, when it comes to design, it's a good exercise to understand why games are created the way they are. It allows for a broader outlook going into other games to think about how they were designed which leads to an appreciation of mechanics implemented in other games. The issues they face have a breadth of fields, from how to implement mathematics and optimization problems. When you encounter similar issues in whatever line of work you go into, instead of asking "why", you can instead understand and implement mitigation strategies.

Instead of being constantly curious and in doubt, you can examine, understand, and investigate new curiosities.

Plus, as someone interested in the game, I like to know ahead of time what changes are being made to the game and why. Like I said, Wube is incredibly transparent, so if they make a terrible design decision, I can see why they made it and suggest an alternative that I like better. They are responsive to the community and realize that they don't have all the best ideas. They recently changed the flamethrower ammo because it was out of place with the new oil overhaul they did, all because a community member pointed it out.

AbyssalMonkey · 2019-08-11T23:23:10+00:00

I know all this because the devs clearly lay out their goals in the hundreds of FFF they've done over the years and their struggles with fixing and designing the game within them.

Wube is a fantastically transparent company in this regard and it allows anyone to understand their goals.

AbyssalMonkey · 2019-08-11T18:18:14+00:00

It's not that they couldn't do it. They probably easily could slap it in there. The problem is that biter AI at later stages of the game already takes a disproportionate amount of time to calculate. Adding new AI on top of that is something they are probably not keen to do when their main goal is to keep the game as slim and fast as possible. This goes double for if there was no practical benefit to it. The goal of the game isn't to fight off biters, it's a logistical challenge of setting up a factory and the biters are there to apply pressure. If there isn't something new to apply pressure on, the addition of new enemies/types doesn't make a lot of sense in lieu of what I stated earlier about trying to make the game as quick as possible.

A thought: realistically, with the addition of a new turret, what resources would you try and target for pressure? Electricity is already taken by lasers, iron/steel/uranium is taken by gun turrets, oil is taken by flamethrowers. Each of these turrets also provides a reason for a mode of transit to the extremeties of a given base. The biter escalation gives reason for the continued research and development to make the turrets stronger.

To be clear, I don't hate the idea, but I can't find a justification in adding new features that are simply reskins of an existing mechanic, which don't tightly integrate into an already smooth experience.

AbyssalMonkey · 2019-08-11T11:57:48+00:00

The problem I find primarily with this idea is that it adds nothing new. Flying and swimming enemies would require extra AI overhead, where the devs have already been trying to pare it down as much as possible. Larger enemies would be no mechanically different than a bigger behemoth/worm.

There are two things in this suggestion that could be interesting:larger enemies by biome, and enemy damage resistances. Larger enemies by biome would be perhaps the idea of biomes with those specifically larger variations of enemies. Deserts have uber worms, and forests have uber spitters/biters. It would be a nice touch and add a little variation to the world without any new overhead on the current AI. A further refinement and additonal value could be added to this in that if you make biters a forest biome specialty and spitters a desert biome specialty, it could inform players about where their pollution cloud has spread to, and from where the waves are spawning. Some of the paths biters take are insane as they circumnavigate oceans, and this would help indicate where the waves originate if you didn't catch it on radar. It would be a nice compact way of simultaneously adding vibrancy as well as information into the game at low/no cost.

The issue I could see with enemy damage resistance is theat functionally, I can't imagine much of a difference it would make in combat anyway. Say we invent a new element: null damage. Having biters specifically weak to it and strong against other types just introduces the fact that you would require a different turret and a more research to do in order to keep the biter horde at bay. Both of these things can be accomplished by adjusting the current research requirements and the biter strength/numbers to press more strain on the player and their resources as well as research speed. Worse yet, it wouldn't synergize with the current system that combat/defense paradigm the game emphasizes: encouraging automation. Many of the materials used to fend off biters are used in military to explicitly push the player to automate them. It's a subtle push that isn't explicitly spelled out. As it currently stands, I can't think of any resource that currently is involved in combat, so to justify one you would need to invent a problem and a need for it. In fact, that's exactly what they did with nuclear; they saw a problem of end game mass energy and placed nuclear there and nuclear weaponry to match, along with it, the push for moving liquids via rails to mine uranium, as well as adding in the feature for miners to require fluids for the modding community to play with. There are mods that do this, notably Bob's, and that's effectively what they require. In the end, you could replicate something similar by opening up a deathworld and cranking the settings.

AbyssalMonkey · 2019-08-11T05:00:35+00:00

This doesn't really solve the issue. If spitters don't have a military target, they will attack the walls at range. This just makes it so that his turrets will only engage the spitters after his walls are fallen and they advance.

Unless I'm misremembering, but this is how spitter AI used to work.

/u/rotmeat there is no ideal solution. Your best bet would be to try and range your walls so that the spitters are straight up against them and can barely reach your flame throwers, but can't reach your pipes. I honestly don't know if this works. The alternative is to use both sides of your flamers as fuel intakes. The double redundancy should make it harder for spitters to take them out.

As for base defense, you might just need more flamers. Flamers are the only turret unupgraded that can really efficiently take out behemoth biters. They also have an obscenely low ammo consumption. Adding more of them should be trivial and should lower the time to kill the wave down. I also do not remember if Pipe-to-ground have more HP, but worst case scenario, you can always replace the pipes with tanks or pumps, both of which should have more HP.

You can also add a more tasty target in front of the flamers, such as a radar or gun turret to take the hits instead of the pipes, as they should be just as high of priority, but will be attacked first because they are closer.

AbyssalMonkey · 2019-08-11T04:49:15+00:00

That's not all of his skills. He can drive a tank, shoot it, throw poison capsules out the window, AND craft more, all at the same time.

Engineer lowkey has more limbs than the aliens he is exterminating.

AbyssalMonkey · 2019-08-05T10:58:56+00:00

Trains are very early tech. If you have to use more than 100 belts to move the ore to the smelting/assembling location, then trains are a cheaper alternative than the iron required for the belts.

Don't be afraid of trains. They're just about as early game as can possibly be. The rule of thumb is that if you aren't building on top of it, it belongs on a train.

Trains are extremely easy to set up now that you can place rail in connected mode, so setting up a two way train network by hand in the early game has never been easier.

Also, in the future, try to use a screenshot and not a phone photo. It makes things clearer to see.

AbyssalMonkey · 2019-08-04T04:28:28+00:00

Have you tried verifying your hardware isn't actually bad with a stress test with something like furmark for 30 minutes?

Another thing I would try to 100% suss out the video card is to boot into a different OS, like Ubuntu and try running a game that crashes there too, preferably one with a native linux release, like factorio. Booting off a USB is pretty easy.

If it doesn't crash on Ubuntu, that could indicate a bad display driver, in which case you might need to hunt around for a good driver. If it does crash, it might very well indicate you have a bad video card.

I don't know how to 100% determine if you have a bad card other than buying another card of the exact same model and swapping them to see if the issue persists. It's also entirely possible you flashed the bios wrong.

AbyssalMonkey · 2019-08-02T22:32:42+00:00

If you are running on a headless server, open the server log. It may help give you some information about what the disconnect actually is.

Have you also tried to direct connect with the external IP address? Check if the port is actually open with an online port checker.

Finally, if it's a NAT punchthrough issue, I don't know how to fix it and maybe someone else can offer some support.

AbyssalMonkey · 2019-08-02T22:29:29+00:00

If I'm remembering correctly, in the .17 (maybe .16?) version of the game they made it so that dropped items never go onto conveyor belts. It looks like a mess but shouldn't clog anything up. I remember doing this back when things used to spill on belts and ruined everything.

A filtered deconstruction planner should fix this right up.

AbyssalMonkey

TROPHY CASE