That's confusing, as the tooltip says "science production". Research productivity is applied at science pack consumption. Either you are mistaken, or the tooltip needs to be clarified.
I don't see a problem. This is the final addition to the progress of the research measured. The same way as producing of electronic circuits is measured with all the productivity included.
The big question is whether the research info tooltip shows SPM or eSPM. But a nice addition nonetheless
It shows the effective SPM, with all the productivity included.
Finding out kovarex is a dwarfer is almost more interesting than a new enemy design.
Being dwarfer and being czech are sets with very very large intersection :)
The achievement name for finishing the game is a Red Dwarf quote - from Ace Rimmer
Correct.
Read moreMy idea is for the electric update to calculate the satisfaction percent based on the energy demanded for the shared buffer and save that in a new field on the energy buffer. If you have a merged buffer of 100J and 50J is consumed but only 30J is available to refill the buffer then the satisfaction is 60% (30J/50J) even though the buffer would be 80% full. During the entity update each entity would key off the percent satisfied field on the energy buffer instead of the energy available in the buffer.
This results in behavior almost identical to current behavior even in low power states. The one way this changes behavior slightly is in a low power state where an entity goes from idle to active. Currently the entity will operate at 100% speed for 1 tick because its buffer is full at first before reaching the equilibrium speed based on how low the power is. With this idea the newly active entity would operate at the speed of the current satisfaction equilibrium but if you simu...
Can you code in C++? If you want to work for us and program this (or something else), you can be my guest, and I will not require you to go through the testing process. (This is my reaction of your analysis which was exactly what went through my head thinking about it)
Isn't this already done for accumulators?
When they are placed or changed, they are separate until their energy level syncs up with the rest of the accumulators, and are then computed as a single entity.
Yes, but the difference is, that they can be used together, without any change in behaviour. Consumption machines can use different levels of energy based on activity (one fully beaconed assembler uses way more than assembler full of efficiency modules for example). So the problem with entities is little bit more complex, but solvable.
As the game engines stands now, is it better to have more smaller rail blocks (signals closer on straight sections) or fewer larger blocks, assuming we don't make such a drastic change that the distance between trains going the same way changes?
For performance, it is always best to have as few blocks as possible, as blocks (parts of blocks actually, as junctions split it even more), are the steps the pathfindiner is using to find the goal.
This is because of simplification, the pathfinder is using the already existing block structure for itself. But it would be reasonable to build special data-structure for pathfinding, where only junction points would divide individual steps, which would greatly reduce the comlexity of the search in real-life scenarios.
Good read. I still think the electric network update could be changed to having one electric buffer per entity type (eg all fast inserters on one network share the same buffer and all the stack inserters share a different buffer, etc) reducing the number of buffers to update from the number of electric entities to the number of entity types for each network. This would improve both the electric update obviously but should also help the entity update by significantly reducing cache misses for fetching the entity's electric buffer because the buffers are shared.
I believe I have a way to incorporate all electric network mechanics except drain but there are several ways to make something like drain depending on what the intended gameplay purpose is.
Wait a second ....
...
My brain is trying to figure out the reason why it can't work.
Eh? Derp?
Obviously, it would change the behaviour in some ways, but maybe not in ways that would matter. It might be weird for some bigger entities like roboports, which can charge up and discharge. So a lot of roboports in a big network sharing their buffer would mean it takes much longer to run out of energy completely, but maybe it doesn't really matter that much.
For small buffer entities like inserters, assemblers or laser turrets, they have buffers, but just for technical reasons, and we want them to slow down or shut down in a coordinated way when there is not enough electricity anyway, so a shared buffer wouldn't matter.
This would be a problem once we want to independtly update entities at the same time, but in this case, the buffers could still be split based on the group in which the entities would be updated.
And as you suggested...
Read moreRead moreI have a save file that i quit a while ago because of performance. I was about 900 hours in with 39% of research done. I wanted to complete a PY run with every intermediate having a train station but with only the base game, no LTN or Cybersyn
Some spec:
Trains: 1130
Train station: 5372
UPS: between 24-26
My train take 2/3 of the update time
But 95% of those repath are not required. The train go in a straight line and wont encounter a fork until about 300-400 tile later. It should be scheduled for a repath. But the repath should not happen until he really need to figure out were he want to go for an optimal path… a fork
There is still quite a big reserve when it comes to both train movement and repathing, it just wasn't usually that much time consuming in our saves, but with the additional improvements, it is just a question of time before it does. Can you post a link to the save (or the forum with the save?)
Having the bots move once every 20 ticks looks interesting, but how does that work with robot-biter interaction? If a worm tries to kill a bot that flies overhead, it needs its current position updated at the speed of combat.
The construction robots (only kind of robots relevant to this), upate every single tick whenever enemies are around. This keeps the behaviour around enemies consistent, but keeps the performance boost when enemies are not around (which is usually almost always).
Since you have capped Productivity to 300% and implemented all the other restrictions, have you ever considered allowing them back in beacons in certain scenarios? Maybe set a cap on how much you get from them if they are broadcast? Could be interesting as it would allow for more variety in builds.
Not really. The 300% productivity is only achiavable in the very late end game with limited number of recipes. The overall boost from all of the bonuses available combined is enough. We don't need to break the game by semi-forcing productivity beacons everywhere.
You might be right. Because you are generally expected to build bigger in the expansion. But definetly not so much bigger, if you just want to progress.
I tried to steer the game design into a direction where if you compare the end state you had (all (nauvis) research finished), things should be ok because:
1) You finish all nauvis only research faster compared to vanilla
2) The rocket is cheaper and simplier compared to vanilla
3) The planets are effectivelly an alternative to progress compared to the infinite research, which should be more fun.
4) You can build "relatively" small if you want to just finish the game, there is one tester who finished in 37 hours by trying to go as minimalistic as possible (some semi/exploits were used, which we want to patch, so it will be more), but it still wouldn't be crazily more. We finished our MP playtrhough with very seldom use of quality, so we kind of proved it is far from necessary.
Obvious...
Read moreYeah I agree. Quality is useful for things that will be built and exist permanently, not for things that get consumed for science.
quality science packs doesn't make sense indeed (one if the reason is, that there still will be normal production all these quality ingredients are supposed to support). But quality ammo or fuel has bonuses. I didn't try it with ammo, but quality fuel allows train acceleration and max speed to be increased a bit. And since trains generally don't eat that much, and fuel isn't that expensive, it is a reasonable thing to do in the end game stage of the game.
Could you please describe how landing pads work? Orbital platform inventory is instantly available for extraction from landing pad? Or some kind of delivery cannon required?
What if there are multiple platforms in orbit? How to select which one is "connected"?
Is it possible to transfer items between platforms?
It works similarly as with logistic network. Landing pack has logistic requets which can be satisfied by the set of platforms (working as passive provider chests) currently on orbit. It is not teleported, but transported by a capsule with a delay
100% productivity bonus does wonderful things. For example - 5spm needs 1 belt of iron and copper ore. If you add 100% productivity to everything, you get 200spm out of the same amount of resources.
Productivity boost calculated with warptorio2 modules, as the mod adds that while barely changing existing recipes. Of course the comparison does not match what will happen in the expansion (warp modules apply productivity to every recipe, but also we don't take into account buildings with builtin prod bonus or prod researches, we don't know recipes for the new science packs, etc...). But you can see what could happen if you take just base game + quality mod, without space age.
Don't forget about the productivity researches (only available for specific set of items, but still important)
we have just one expandable landing pad per planet.
It's nice to know that throughput isn't capped by the landing pad. When they first announced there could only be one, a lot of people had concerns about max SPM.
It kind of is capped by it, but the cap is huge, nothing to worry about.
Hello,
we usually show finished stuff in Friday facts these days, but I personally always liked to have a peek behind the curtains and see the (temporary) mess there.
This motivated me to do some kind of overview of how the overall expansion development felt from my perspective.
If you are like me, you might appreciate it.
Our story starts in February 2021 with ...
Read moreExcept that corporate profit margins surged during the pandemic, not nominal profits. That means profits became larger than they should have been proportional to revenue, which doesn't happen with inflation caused purely by an increase in the supply of money.
The articles I linked, which you clearly didn't read, explain this.
Also, no, that has nothing to do with anything I'm saying. You're the only one with a vested interest in pushing a "capitalists did nothing wrong, it was all the government's fault" narrative. You're the one that brought this up.
Edit: I can't anymore with this, this is such a waste of time.
Yes, I know the articles stated that profits went higher, and if the wages didn't go up appropriatelly, than yes, people working for these corporations had wages effectivelly shrinked. But it is a different subject, which doesn't actually explain that corporate greed would cause inflation. It would just affect that these corporations take advantage of it to improve margins.
Getting tired, that is a good sign. We are revealing the errors in the assimuptions you have. These assumptions are creating your worldview, and you are getting tired, because your brain defensive mechanism is kicking on, trying to avoid changing the worldview as much as possible.
“It's easier to fool people than to convince them that they have been fooled.”
So, if I demanipulate a single person it would be worth it.
Read moreAre you trolling? I would say we are more consumer friendly than about 99.9% of other companies.
But your pricing model isn't. The entire rest of the industry allows their games to depreciate with inflation, and you're saying you won't do that. That is a less consumer-friendly pricing strategy.
And you're deluding yourself if you think you're the only consumer friendly studio out there, especially among projects of this caliber. I can think of several other projects off the top of my head that have no microtransactions, have put out years of large, free updates, and have never increased their prices. Two of which are your largest competitors, Satisfactory and Dyson Sphere Program.
After we put more than year of work working 14 hours a day 7 days a week for free.
It wasn't "for free," it was for the product you were planning to sell, which you did end up selling many year...
Let me focus on the most fact based thing to debunk, because somehow I smell this motivates you towards all of this:
Just search "money printing in the us during pandemic". So they apparently printed 27% extra money. And soon after that, there was a surge inflation, what a conicidence.
Yes, I understand there is a big motivation to blame the corporations, and coin terms like greedflation, to somehow achieve that so many people get confused and blame anyone but the real villain.
Read moreI have no idea how you can say "greedy" is a subjective term, acknowledge that you're adopting a less consumer-friendly pricing strategy than everyone else for no other reason than that you feel you can, and then turn around and say people are "generally incorrect" for seeing that pricing strategy as greedy.
Beyond that, a lot of what you're saying is simply wrong.
You have the investment cost, the risk of the investment (the bigger risk the bigger rewards often)
Factorio was crowdfunded, and you sold early access through almost the entire development process. Compared to the vast majority of game projects your investment and risk were both extremely low.
The labor wasn't done, the game is being worked on.
The vast majority of your work since 1.1 (which as I've pointed out was two full years before the price increase) has gone toward Space Age, which is a new product you plan to sell. So n...
"Acknowledge that you're adopting a less consumer-friendly pricing strategy than everyone else"
Are you trolling? I would say we are more consumer friendly than about 99.9% of other companies.
"Factorio was crowdfunded, and you sold early access through almost the entire development process. Compared to the vast majority of game projects your investment and risk were both extremely low."
Wrong. After we put more than year of work working 14 hours a day 7 days a week for free. This, lets say a million dollars worth invested. It is many times more than the money we got in the campaign and could go all into nothing. So the risk was already there. And after the campaign, we invested all of the money to keep going while barely getting along for another year at least, so even more risk, extremly big risk, when you think about how many games are released, and how many don't make anything.
"The vast majority of your work since 1.1 (which as I've pointed out ...
Read more
devtrackers.gg
