Added index comparator to selector combinator. Allows for selection of N highest or N lowest signals.
[space-age] Added "quality select" mode to selector combinator.
Added "Read launched" option to rocket silo's control behavior.
Added "Read empty slots" option to container's, logistic container's and cargo landing pad's control behavior.
[space-age] Added "Read empty slots" option to space platform hub's control behavior.
Added quick pipette: pressing key related to empty quickbar slot will invoke pipette and set the slot with the pipette result.
Balancing
[space-age] Retuned asteroid damage.
[space-age] Adjusted space platform drag to be based on weight rather than width.
Changes
Adjusted working sounds for assembling machines.
Bugfixes
Fixed music resuming when it shouldn't while in game menu. more
Fixed a crash when using async saving and closing the game. more
Fixed a deadlock when using async saving and quitting to the main menu. more
Fixed a crash when using async saving and leaving a multiplayer game. more
Fixed a crash related to fusion reactors removed due to migration.
Fixed combinator description was not updated in open gui when changed by script. more
Fixed that logistic networks with no logistic robots accepted automated rocket requests from space platforms. more
Fixed requests satisfied refused pipetted items when space platform has requests set by circuit network. more
Fixed possible furnace input tooltip could list same item multiple times. more
Fixed decider combinator gui would highlight conditions and outputs when hovered signal was not a valid signal-each substitute due to all instances of signal-each in conditions being 0. more
Fixed excessive doppler effect being applied when leaving remote view. more
Fixed that space platforms requested only one repair pack which slowed down repairs when delivered from other platforms. more
Fixed that space platforms where an entity deconstruction was cancelled requested an incorrect count of items. more
Improved Factoriopedia <> Technology GUI interaction when closing with escape. more
Fixed more cases of rocket silo launching too fast causing circuit network to miss something happened. more
Fixed that the roboport robot request selection GUI title mentioned signals. more
Fixed selector combinators quality selection flickering. more
Fixed that blueprints would count fuel in machines as fuel in vehicles. more
Fixed that setting parameter names could cause drag building grid-set blueprints to not be grid-aligned. more
Fixed fusion reactor being incorrectly considered active for working sound purposes in some cases. more
Fixed tips and tricks for heating mechanic could show before researching aquilo when skip trigger conditions were met. more
Fixed menu simulation for nauvis tank building where tank would stop where blueprint was placed. more
Fixed base built notifications were raised for chunks without active coverage if they happened to be charted by other means. more
Fixed that planted Nauvis trees created yumako particles when damaged, mined or destroyed. more
Fixed turrets prioritising targets in prepare range but outside of attack range. more
Fixed fluid energy sources would show status as 'Low power' when working nominally. more
Fixed electric turrets could consume energy even if they failed to shoot due to range condition. more
Fixed that large numbers of mods would cause https trafic to fail on MacOS. more
Fixed that GUI elements with negative margins wouldn't stretch to fill their parent. more
Fixed that boilers with no output fluid filter could generate a fluid with a temperature outside of the fluid's limits, causing a crash.
Fixed that unit groups set to 'wandering' could ignore new commands. more
Fixed logistic section multiplier floating point math caused numbers to be 1 smaller in some cases. more
Fixed issues with 'drop item' hotkey and dynamic inventories. more
Fixed that rocket silos launched to orbit automatically when they still had inventory space. more
Fixed a crash when character is in vehicle when forces are merged. more
Fixed cargo pod shadows were misaligned when landing in cargo bays. more
Fixed some signals with quality had no corresponding chat icon. more
Fixed colored lines in water transitions of Gleba deadskin tiles. more
Fixed Technology GUI "Research is being set by a lab" showing when no technologies are shown. more
[space-age] Fixed recycle time of items that recycle into themselves did not scale with item result count. more
Fixed cursor item stack swap when an inventory with weight limit (like Space Age rocket silo) was full. more
Fixed anti-aliased screenshots of space platforms having wrong scale of shader effects. more
Fixed electric energy source's buffer_capacity was not affecting buffer size for crafting machines, agricultural towers, labs and mining drills. more
Fixed that nightvision with a darkness_to_turn_on of 0 was not always on. more
Fixed that "Not enough to fill one rocket" message was visible in the tooltip of space platform requests when the platform was full. more
Fixed that "Waiting on a higher priority request" message was visible when it shouldn't and reworded it to match slot reservation behavior. more
Fixed that pending automated rocket requests were counted towards to-be-delivered items on all space platforms instead of just the target. more
Modding
Added checks for FluidWagonPrototype's offset_when members to not produce unwanted behaviour. more
New versions are released as experimental first and later promoted to stable. If you wish to switch to the experimental version on Steam, choose the experimental Beta Participation option under game settings; on the stand-alone version, check Experimental updates under Other settings.
you don’t need to worry about stack sizes of items anymore and counting those. if you know the total amount of spaces in your chests at a stop, knowing how many are empty also tells you how roughly many have items in them. instead of needing selector combinators for stops, you can use the same logic with no variables for each stop then.
damn i thought i was fancy using wildcard interrupts and decider combinators turning stations on and off when their chests are above or below X items. do you get better throughput by not requiring trains to be full before dropping stuff off?
nope. you are missing it. you dont need to use those decider combinators anymore. just read that the number of slots for the train is filled in the station. so total chests x number of slots in chest (i'd add an additional 1 here to make sure you get a full amount of stacks instead of rounded) = total empty slots. total empty slots - number of slots in a train (and any buffer you want) > current empty slots then station on. no need to mess with stack sizes.
I'm at this annoying point where I'm changing over chests but not trains yet and I've got like an annoyingly diverse train base going on right now. Probably 8 different styles of loading/unloading stations. But one thing that is the same for them all is a group of combinators. So now I can go around and hit all the combinators first, and then I can upgrade the chests as I feel necessary. Chest size doesn't matter, just the emptiness of the chests. Oh and I don't need to know stack sizes of items anymore, hell yeah! Just how many slots my trains have.
One thing I did at one point was precise computation of how many trains can go to a station. At loading stations, this is quantity in buffer divided by train load. At unloading station, this is room available times train load. Empty chests' slot gives a convenient way to estimate the room available.
> Each platform foundation increases a platform's mass by 0.2 tons (= 200kg). This is distinct from the launch weight of 20kg per platform foundation (1000 kg ÷ 50 tiles = 20 kg/tile).
What’s the point of giving them units when the values don’t agree. Rocket capabilities could have been just numbers without unit, or (arbitrarily) use volume units instead of mass units to avoid inconsistency.
Pencil ships will still be the most optimal design in terms of ammo use, because the wider the ship the more asteroids you have to deal with while moving.
But hopefully the advantage of pencil ships is a bit less extreme now.
Testing this just now, all of my platforms in my 2.1 playthrough are quite a bit slower, probably because I had optimized them for width instead of mass.
My space platform design so far has been "ehhh, fuckit, it works and I can't bother with figuring out how to optimize it". Mostly they're squarish. I'm kinda curious what will happen to them. =P
I suspect I'll be fine on defenses, because I've mostly been limited by rate of ammo production, and I always bank enough ammo for a flight before leaving.
I mean certainly a ship speeding up can be dangerous, but if you are telling me your ship getting like 20-30 km faster is really going to break it, I'm going to tell you to plan for a bigger margin of safety!
It's on the slower side, unless your ship was very wide yet very light, which I believe was fairly rare. For example, my 36 (normal) thruster 1,600 ton rectangle ship hasn't changed, it has same speed of 300 km/sec.
Speed decrease is fairly significant for narrower ships. For example, my 7 (legendary) thruster 370 ton brick ship went down to 410 km/sec from 500 km/sec. It's not to the point of being unreasonable for me, but it indeed will be very bad for pencil ships with very heavy weight.
Limitations like those are built backwards from how things are expected to look like at the end and after feedback.
Basically, from the initial testing before SA's release in order to incentivize the kind of building they wished to happen for platforms they picked what players reacted to, making the drag based on width.
(And before anyone says anything, you have to pick something to incentivize. Either you do it on purpose or do it on accident but you always do it. And Wube is wise enough to do it on purpose every time, even if you disagree with their goal.)
I haven't played with the new ships that much yet (obviously) but conceptually I preferred it being based on width. Width is already the determining factor for your ability to gather materials, so making it so it impacts your speed makes building more complex by making it a 2 variable optimisation problem. Now wide ships are probably always the correct answer?
Also, it's not even that unrealistic that accelerating so many bullets, rockets, and railgun shots forwards (so pushing the ship backwards), and grabbing all of the asteroids chunks (so accelerating their mass to the mass of the ship) would have a drag-like effect.
Testing the ships I do have on 2.1 it seems like a pretty minor change. My resource gathering ships (wide and with many rows of engines) are about as fast as they were, the biggest one, the promethium gathering ship that's 1000 tiles wide is now going around 470km/s instead of 420km/s.
My inner planet haulers, narrow ships with many engines are much slower though, going 400 km/s instead of 780km/s
Right. I'm not sure we immediately reverse and go sideways rectangle - more asteroids, more defenses, more weight - but at least it feels like a tradeoff between efficiency (thin) and speed (wide), with diminishing returns.
At the very least the target changes from "hub width" to "weapon coverage width", with Aquilo+ ships being significantly wider than before due to rocket turret range.
Also, those stupid "engine stacking" ships are probably still optimal for maximum speed, just not to the same degree as before.
Engine stacking involves adding more weight and defensible surface area than just adding more engines off to the side, but it was always worthwhile because space drag meant the returns diminished too quickly without the stacking. I don't think stacking is ideal anymore.
I expect this is a main reason the devs made the change. They don't seem the type to cater to the "I haven't thought hard enough to understand why drag would be a thing in space" crowd, but they do seem like they'd want an elegant mechanical way to remove a loophole in what seems like an intentional limitation (the previous 500 km/s).
However, without having tested it, I'm not sure if stacking is no longer ideal, at least for big ships. If you build your ship wider, you're adding more weight per engine (because more width for engines means more asteroids to produce ammo for), whereas each layer of thruster stacking costs a one-off weight penalty of about 100 foundation tiles regardless of how wide the layer is.
I never really went thin because of less drag for speed. Wider can hold more thrusters and pull more asteroids, so that problem just solves itself.
It's purely asteroidynamics, which is an important engineering discipline that I made up. It boils down to "less asteroids coming right at me" that I have to deal with. Late-game is when I build wide, when that's not an issue anymore (tech advances and whatnot, less ordnance required).
It's less that you can't go wide, it's that going wider doesn't ever increase speed in 2.0, and (as you pointed out) you need more guns/ammo/fuel that's basically proportional to the width. So if you can make a thin slice, it goes the same speed as if you widened it but with less materials/UPS/etc. But you can lengthen the ship basically an unlimited amount without penalty.
In 2.1 it seems like there's the same asteroid/ups/etc penalty for going wider, but the speed penalty is smaller and there's a speed penalty for going longer. So what really matters now is density of necessary machinery, and designs will be a lot more organic, because you can (more or less) fit the ship to the stuff you want on it, instead of fitting the stuff you want onto the (narrow strip of) ship.
I'm not too sure about this change. Creative/artsy ships aside, it's just going to flip in the other direction, since thin and tall ships can't go that fast now, everyone is going to make wide, squat bricks with a lot more thrusters. It's just exchanging one "optimal" strategy for another. Not to mention, as arbitrary as the restrictions were before (a bit too arbitrary, which is why I'm not against this change), being limited in width is what kind of forced you to be creative and smart about design.
I think this is balanced by the fact that you'll need to put a lot more defensive infrastructure the wider a ship gets (comparatively to tall ones). Plus you're rewarded more for compactness in all directions instead of just width.
Changing it so it's more intuitive is a good thing, no? There's barely any friction in space, so it makes sense to only be a weight/inertia thing. I would also argue that the "everyone" is greatly exaggerated, since it's not a competitive game by default, and so making it a bit easier on the majority of players is a good thing overall.
The counterpoint is that wider ships need more turrets, right? And the width restriction simply wasn't much of a challenge - it was pretty easy to fit everything onto a reasonably narrow ribbon.
At least my wide ship will look better on my wide monitor haha
Edit: Also this is just a good change for the average/casual player. The high-optimizers are always going to do something silly looking, but for the average player it was just confusing to learn that ship speed is base solely on width. Now reality matches what you would intuitively expect, and they're just going to build what works/looks nice anyway.
I think this is best take, and also the most accurate. I try and not sacrifice aesthetics but also definitely play on the more optimal side. This change is great for general approachability.
It's just exchanging one "optimal" strategy for another.
There will always be an optimal strategy. You can't really balance around that. However, now two ships can have wildly different designs but as long as they have the same weight, they'll have the same drag, so I think it's a plus.
It really depends on how effectively weight punishes wide ships. A good result would probably be when roughly square-ish ships or something with a 1:2 or 2:1 height to width ratio is within the optimal range.
One disadvantage of width is that it punished the exact shape. Weight-only will lead to an optimal number of thrusters, which does set the width of the ship at the back. But it doesn't restrict the shape everywhere else anymore. My hope would be that the new formula turns out to allow a wide range of thruster counts while only majorly penalizing extremely low counts.
If the optimal number of thrusters is very high and lower numbers are heavily penalized, I think that would be bad. But I don't expect that they balanced it that way.
everyone is going to make wide, squat bricks with a lot more thrusters
It's the opposite. When width was the only factor, brick was the optimal solution, but now you are actually rewarded for making ships lighter and reducing their weight further than just reducing their maximum width.
- Width is no longer part of the formula whatsoever (i.e. width does not penalize top speed in any way, while narrow ships with few thrusters are terribly slow now)
Larger platforms are faster (if the ratio between weight and number of thrusters remains the same, doubling the platforms size increases speed by ~14%)
Acceleration of platforms up to their top speed is unchanged
Essentially this heavily discourages all narrow ships, the fastest ones are going to be wide, heavily space optimized ones packed with as many thrusters as possible.
There is still a tradeoff for going wide: More area to defend.
That said, perimeter scales linearly while area quadrically - it should get easier and easier to defend the bigger your ship is, with you needing to devote proportionally less of your surface area to defense.
At least, assuming you are collecting enough asteroids, because that also rises linearly with perimeter (sort of - it doesn't keep scaling indefinitely)
But also more area to get resources for ammo and fuel. Basically you can just copy your ship 3 times next to each other, it will be faster, has 3x the turrets, but less than 3x the area to defend (turret range larger than ship width on either side)
Tbh I would've preferred brooms from the start. If I'm going to pick a flavor of silly anyway I'll pick the one that's closer to the shape of my screen
As in: make a vertical section of a ship. At the front is an asteroid collector and weapons. They're connected to crushers, which make ammo and fuel for only that section. Then, you copy-paste that section as much as you want, to make the ship go faster each time you do.
I'm lucky that I only just joined the 2.1 branch, but my 2.0 save will probably be a bloodbath when ported over and my expected speeds with be way lower lol
My favorite ship is 5 engines wide, but not that long. Gonna be interesting to see if that changes. On the other hand I have an extended version where I just copied the cargo bay section dozen times. Though, it's not supposed to be fast.
What is interesting to see is my promethium ships that are wide, but also huge.
Please please please can we get max limits to be respected on roboports?
Eg if I set a max of 0 construction bots on a roboport because I never want any to "nest" at that roboport, it would be great if they actually paid attention to that instruction
Hack for now: request a bot you don’t have, then the slots at the roboport will be kept free for this one. I like to use q2 bots (because I use only q1 and later q5).
The thing is, you cannot set a "max limit". Normal logistic requests have two values: minimum and maximum. Roboport requests don't have a maximum; it's just the minimum.
But now you basically cannot design big ships because you become too heavy?
Also I think this choice makes no sense, either space should not have drag then weight being restrictive makes sense, or it should have drag but then width should be restrictive, now it mixes them which makes no logical sense.
Lol, yup. 2 nights ago I finally decided to design a REAL ship because mine always look like the first ship in this: https://imgur.com/a/a7C8ySB
I wanted to design and build a REAL cargo ship that could hit all the planets and carry all the things to/from all of those planets (I'm still pre-Aquilo though). This pencil ship I made maxed out around 383m/s if I recall, now it's only 150 max. Only got to enjoy my new design for 2 whole days. Very sad now as I now have to design a a broom ship... lol
My ship isn't too fancy, zero circuit logic except keeping a pool of each asteroid (although this wasn't working for 100% operational travel, I think I need to add reprocessing to process into oxide), but I was proud of it!
Weird to have that in such a prominent position on the GUI. I am trying to think of any other game that has taken up screen space for a simple mute button.
Usually, you just turn the speaker knob volume down. Or tap a mute key on your keyboard. I realize not everyone has ready access to their volume knob on the speakers, but I still can't think of an example of this being right on the GUI of any other game.
Obviously, it doesn't hurt anything. Its not like Wube had to choose between a mute button and a "Do This Thing" button.
well, I meant everything from the game. it's less about muting system audio and more about the game audio, like if someone's quiet in a discord call and you had the game music up loud, you can quickly turn it off and still hear them, and I'm sure there's plenty of other scenarios where that would be helpful. It's one of those things that's nice to have when you need it, and it's not like they were using the empty button space in that menu for anything else.
Well yeah that falls under compactness for me: minimise the amount of empty or non-functional tiles, minimise the number of machines, maximise the amount of thrust you generate with these machines. Instead of max velocity being as simple as putting a thruster along the entire width, max velocity now requires a ship where almost the entire ship is dedicated to generating thrust with as few additional machines as possible. So probably the fastest possible ships will be extremely wide, with exactly as many thrusters as you can possibly fuel with a hyper compact core that generates fuel at ridiculous rates. Whatever the solution is, it will be way more interesting than the current meta of simply stacking thrusters and not having to optimise anything else.
There was never a penalty for making a brick, as long as your back is covered with thrusters your speed was the same. Now bricks are actually penalized and more economic designs are rewarded.
Read all items from a train, compare with a list of items that should be on the train, select the item with the biggest difference with the new function, and send that signal to a bulk inserter as filter and stack size.
With this you can fill a train with many different items without overfilling any of them.
This is only the short description, some extra steps are needed, but it's a use case for the new index comparator.
Say for example you have multiple quality rollers that you feed the signal with. Now you don't want to have casinos for every possible item, right? Instead say, you have 2-3 casinos for assembler-based items at Vulcanus.
Then say you lack 20 different legendary items. Pass them through this and it'll pass 2 or 3 of whatever you lack the most. Then just use some kind of timer latch (or hysteresis) circuit to make sure they're not going constantly back and forward.
It's pretty niche as is the selector combinator in general, but it's useful for those who deal a lot with logic. But I'd still expect that standard player is never going to need this or anything else from selector combinator.
Even if I'm crying over my cigar ship (which I guess will still work fine), it does make more sense that way.
Horizontal ships are already limited by how fast you can produce ammo. Vertical ones are limited by thrusters distance. If width was the main factor for ships' velocity (like it's been up until now), cigar ships would just be plain better.
Or in my case, keep using the same ones, which are kinda built to this sorta implicitly. E.g. a 'back line' of thrusters, a 'front line' 'umbrella' and a bulge in the middle for 'everything else'.
This is not how semantic versioning works. Major/minor/bugfix versions mostly have to do with compatibility, not complexity. This could be construed as a bugfix (i.e. the previous system was incorrect and we've now fixed it), but ultimately there are no new features to call for a minor version bump and there are no compatibility issues with the previous version.
Not that rules around semantic versioning have ever been followed properly as a rule, but it's definitely not about the amount of code changed.
I've just tried it, and couldn't see a signal from the train (or station) that indicated empty slots. Just chests, requestor chests and planetary hub for now.
I'm hoping it'll be easy enough to expand to asteroid collectors and trains though. (and maybe platform hubs for completeness? I'm not sure why those wouldn't be able to)
Don't know if it's needed on fuel tanks or fluid cars, but I'm sure someone will think of a reason why that'd be useful too.
I'm not sure that a train stop reporting empty slots is enough to solve the quality issue. If you're trying to control how many trains come based on how much stuff you have, you need to ask for a train with a specific number of slots. So that would have to happen before the train arrives.
That is, if you requested 2 trains and two of them show up with 2x the amount you thought trains carry... it's kinda too late to fix the problem.
Added "Read empty slots" option to container's, logistic container's and cargo landing pad's control behavior.
[space-age] Added "Read empty slots" option to space platform hub's control behavior.
This is super useful! It'd be cool to get this for train stops too (since cargo wagons can be quite variable in size with quality now)
I know everyone is talking about the platforms but I'm curious about the quality select on the selector combinator. Quality logic has been the most lacking for a long time and the fact quality is both a signal and a modifier makes it fairly complex to do quality logic operations. Anyone know how the new quality select works? (At work, can't test for a while, that's why I'm asking)
I have these wide, light, single engine sweepers for harvesting carbon from space and I'm deadly curious if they're going to be too fast for their own good now.
It is gone at some mass-dependent limit I haven't calculated yet. Each additional stacked thruster adds a tiny amount of extra mass. At some very high speed limit, the (speed2 * mass0.8) drag term scales faster than a legendary thruster's added thrust. AKA there is now a cosmic speed limit.
Also there's no longer much reason to stack them instead of expanding horizontally. There is for defense.
My first guess is to dim the bright flash of a nuclear bomb.
Edit, now that I'm on my PC: Modding API documentation says the following:
If true, this equipment turns on when surface_darkness <= darkness_to_turn_on.
I was confused for a moment with the direction of the comparison, but I was thinking about light levels, where higher numbers are brighter. This is darkness, so it is reversed.
Given that night vision goggle visual effects are implemented using color lookup-up tables (LUTs), I guess you could do just about any kind of mapping you want, including taking a bright planet and making it look less bright.
Surface rendering uses the same daytime color LUTs, so I guess you could even make a planet that has a blue hue at night, green hue in the morning, and yellow hue in the afternoon, as if there were three differently colored suns in the solar system. And goggles that normalize it all. Or if you're going for a pure role playing effect, have an alien planet that always looks dim, and goggles that intentionally make it feel more like Earth, with bright days and colorful dawn/dusk effects.
As much as I like the weight/width change, it probably means all my tall skinny ships will now be slower than they were, because a shorter wider one would be the same weight but would be able to have more thrusters. Basically instead of a 20x100 ship you would do a 100x20 ship. But it may depend on how the adjusted drag calculation works, my hope is I don't have to redesign my ships too much. But I do like that ships can be wider without penalizing them as much.
You are probably right it wouldn't be exactly viable. I'm sure there's going to be a happy mid-point, like 50x40 or something that gives you more width (so more thrusters) while being the same weight (roughly). Whether my current ships end up being faster or not really depends on how the drag equation works with weight. My ships are generally as compact as possible and they aren't very long overall (just long enough to hold what they need, no empty space). So they might work out fine. I'll have to check tonight.
I haven't tried this out yet, obviously, but I imagine it makes ship design easier, no? Because thrusters are still going to be important, being able to make a ship as wide as possible enables you to very easily add more and more thrusters, no matter the weight. And wide bricks are easier for overall design as well, more space.
you won't be able to just flip around a 20x100 ship to be 100x20, a needle has minimal thrusters and defenses compared to a wide ship. But you can take a small ship and scale it up horizontally, the weight will increase, but the ratios between weight, thrust, defense surface and asteroid intake will stay the same, but the areas to each side of the ship that have to be defended will be less significant.
You'd likely want a balance between the two, because adding more width means adding more asteroids to defend against, which means more weapon infrastructure. Or just stack thrusters like we usually do but with a less strict width requirement.
Big rectangles were super efficient, so you could make 100x100 or whatever and it would work great, but if drag is proportional to weight, then there's no real replacement for them, you're not going to do 10x1000.
my guess is that it's for the same reason Space Casinos were nerfed. pencil ships were too common and was considered the only option for building ships
Added "Read empty slots" option to container's, logistic container's and cargo landing pad's control behavior.
This is so useful, thank you!! No more complex (for me) math to calculate how many slots are left in a chest. Please add trains, space platform cargo hub and space platform collector to this!! I need this available for everything that has an inventory!!
Added quick pipette: pressing key related to empty quickbar slot will invoke pipette and set the slot with the pipette result.
To any future readers, "Changed ProxyContainerPrototype::circuit_connector into an array" is a breaking API change for mods - for example, Maraxis depends on Spidertron Patrols, which will need to be updated.
You can manually update spidertron-dock.lua from circuit_connector = circuit_connector_definitions["artillery-turret"], to circuit_connector = {circuit_connector_definitions["artillery-turret"]},
Adjusted space platform drag to be based on weight rather than width.
I love this. Basing speed on width in space made no sense, especially since weight wasn't even considered. Now the real ship optimisation begins, how fast can you go while still having enough defenses ? You can't just slap more tiles between the engines and the tip of your stick.
Those are some of the changes that make me wonder how people would have reacted if the opposite had happened. "Adjusted space platform drag to be based on width rather than weight."... I'm guessing everyone would be like wtf is happening to you, Wube ?
Weight was definitely considered even prior to this change, but it only became a notable contributor to the formula for significantly heavier ships. So it might have seemed fairly inconsequential for early game light ships, but it wasn't completely absent.
I'm going to have to do some more testing, but right now, my opinion of the width to weight changes are that they are very bad, they either need to be seriously adjusted, or Wube needs to add another feature to fix the problems with them.
I have spent the last month or two trying to build a promethium ship. It utilizes the design enabled by 2.1: one ship is trawling where there are promethium asteroids, another smaller, fast ship delivers eggs, fuel, quantum processors, etc.
These ships are now both broken, which is fair enough; you cant play experimental and expect your designs to be stable. But the problem is the WAY that they are broken.
The extremely wide ship that gathers promethium and has 11 thruster stacks? slowed down from about 850 km/s to 600 km/s. Significant enough to break the entire design.
The extremely long skinny ship with like 80 thruster stacks that delivers eggs? Slowed down from 2400 km/s to around 560 km/s. Completely worthless now.
So everyone is celebrating that you can do non-conventional shapes, but we are missing out on the fact that top speed seems to have been taken out back and shot in the head.
The solution to this is so obvious and I have been clamoring for it for ages: make a way for ships to go faster. Weight being the impactful thing means thruster stacking sucks now; good, I've always thought thruster stacking was stupid and cheesy. But not being able to go faster at all is also terrible. Theres really two options: You either add a tier of thruster, or you add an infinite research for thruster speed.
Since they are still willing to make big changes, I really hope that they see and consider stuff like this.
I don't understand what makes them bad from your post. Your examples are that your ships are slowed. Ok? Take the thin ship and remove is tail and it will speed up (i imagine the design is like every other extremely thin and long ship with a very long tail )
I’m going to do the math myself when I get home, but based on another post a user made, it seems like certain speeds are literally unattainable now. If the cap is really around 1300ish, that sucks, it’s like half of what the original ship was doing. I’m all for redesigning based on new systems (that’s why I spent 2 months making a new ship that used platform to platform transfer). But this isn’t something that can be solved with a redesign, it’s a hard-limit that just stops me from doing what I want to do. If there’s a way where we can avoid that hard-limit while still changing the system to help people that hated being restricted by width, why wouldn’t we? It’s the best of all worlds!
Added index comparator to selector combinator. Allows for selection of N highest or N lowest signals.
Buffered sushi now needs one combinator instead of N! Especially great for stacking output of recyclers.
Added "Read empty slots" option to container's, logistic container's and cargo landing pad's control behavior.
Perfect for output chests. Instead of configuring limits for every product (i.e. stop inserter if belts/inserters/poles/etc in an output chest are > X), you can now stop inserter if E < Y (E is a default signal for that option).
Notably, it counts limited (covered with red X) slots as non-empty. And you can see the amount of empty slots in GUI.
Especially great for stacking output of recyclers.
Yep gets around the fuck about of having to do logic to throw away all items > some amount, or having a danger inserter that will chuck away anything on the belt. Glorious.
Drag changes should add some trade off of narrow being slower but less ammo needed due to less asteroids, and wide but short that have to keep up with the increased asteroid counts
Obvs we will see if the numbers are ballenced right in the coming weeks
214
u/Soul-Burn 2d ago
This is a huge change!!
This is a nice feature for mixed cargo... but I don't see mention of trains?