List of things for which PAs are actually better than any other alternative #14437
Comments
|
This comment was marked as off-topic.
This comment was marked as off-topic.
|
I was going to use it to stack fluid extractors from coal to make benzene, since it doesn't make sense to overclock fuel production. |
|
Assembler at EV-LuV (until the Precise Assembler becomes available through mona/bastline). Not really endgame, but the PA really helped there especially for circuit components. |
at what tier is gated the GT++ assembler? zpm? |
|
yes. |
|
then we may want to downtier the GT++ assembler so it has a purpose, and we avoid both multis to coexist around the same time of the progression no? What would be the implications of downtiering the GT++ assembler? |
|
The GT++ assembler can do recipes one tier over its energy hatches. This is built-in and required in ZPM+ tiering, but before then it breaks progression. |
|
yep pretty much what querns says. |
|
it's not clear which one you want to use then. I guess you go GT++ to do recipes of tier+1, and PrAss for recipe of current tier? |
This is correct. The PrAss has superior parallel capacity, but cannot do recipes over its energy hatch tier. The GT++ assembler is only for doing recipes one over its energy hatch tier. One way to reconcile this would be to give the LSAA the Maceration Stack treatment -- downtier it (and its casings), then put in a chip to upgrade it to a variant that can increase its tier by one. |
|
I tend to use both for different things yea. precise assembler has more parallels and much space for hatches, ++ assembler has the extra tier. If you want to bring one of them to IV right now that should probably be the precise assembler. would just need one recipe change: the mar-ce-m200 smelting (or where its being used). |
|
mhm, i'd like this idea yeah, even tho i'm wondering if getting PrAss in IV isn't too much of a buff. |
Doing this unheeded would also de-facto move naqline to IV, I believe. You'd have to adjust the PrAss to only have precise mode available at LuV+. Probably by means of shifting all the PrAss tier casings up by one, and adding a new level 1 casing that flags the PrAss as unable to do precise mode. |
|
this looks reasonable imo |
|
yea the mar-ce-m200 is only used in the precise casings, so some tier 0 casing could work nicely. without precise mode and probably just 16 parallels. the controller is already craftable in IV |
|
sounds like a plan. @chochem can you make a ticket summing this up nicely? i'm not much used to this part of the game and i don't want to talk non sense or dumbly copy/paste what has been said here. |
|
Is the electromagnetic separator getting a multi? Because the Monazite Line uses one in the main path and I don't fancy having a wall of single blocks to keep up in a power-efficient manner. My line already sucks around 100K eu/t with most machines running on EV or IV hatches. I need 12 or 16 EV separators in a PA to keep up with an EV digester. Also while we are at it can we consider why the multi dehydrator needs ZPM? I know it doubles as a vacuum furnace, but it would be nice not to have a random forced single block in the bast line. Lowering the tier at which you can craft the multi, making the stats somewhat worse and adding an upgrade chip to enable the vacuum furnace and restore the stats to the current stats would be my suggestion. The recipe for solar-grade silicon made from HCL is way more complex in an LCR. It's a 7-step process that does give you slightly more sg-silicon per silicon (1:1.066...). I've heard some people mention using PAs for that recipe. |
|
electromagnetic separator is on the list yea |
|
about cleanroom replacement for Circuit Assembler in IV and LuV, what would be the implications of downtiering the CAL? because given the multi already exists i proposed this: #14440 |
|
Downtiering the CAL wouldn't change much as you need Praesolite or whatever for the imprints which is gated in LuV I believe (Don't quote me on that), so it would just make setting up dedicated CALs later on slightly cheaper. |
|
downtier CAL? u can make hv soc sooner. |
|
hmm, downtiering CAL sounds more tricky/not that desirable. it currently needs luv parts, the AL, and a bunch of rare ingredients which in part can be sourced on T4 and T5 planets. its like a big piece of LuV content. hmm, not sure though what the alternative would be. |
Would that mode care about item ordering? Like the CAL, like he regular AL cares about it. If it doesn't, you'd end up with a 2-length CAL since any other configuration would be unnecessary. Personally, I would prefer to get a new multi and keep things simpler like they currently are. |
|
no, litterally you throw all your items in a bus and call it a day |
|
Aside from those already mentioned:
Most of the above are relatively minor, they are not some huge holes that will be left unfilled if the blue box is gone. However there is one more gripe that I have with the potential removal, and that is:
Right now, whenever a single block machine is insufficient, the player has a meaningful choice between using a multiblock or using a PA. (For evidence that the choice is in fact meaningful, consider the number of people who are using PAs, even for machines where a multiblock exists. Dedicated multis are not strictly better than PAs for every situation.) If PAs are gone, even if every machine gets a dedicated multiblock, this choice will be gone. To me personally, removing player agency matters a lot more when considering the long-term vision of the pack, rather than some particulars about recipe efficiency. Even if everything is going to get moved to dedicated multis, please at least leave the player some choice of which dedicated multi to use. |
|
Quick note: Since you need an extractor to process some crops (sugar beet is a good example), PA is very nice if you don't want to make an LPF specifically to do the extraction; it's a pretty steep cost for a simple extractor multi. It's the same with a few more machines that the LPF counts as, |
|
Using UMV PA is practically a no-brainer. Towards the end of the game, some GT++ machines are already significantly less efficient, and the latency from stacking them can be very high. That's when PA is a good solution: substantially higher power consumption, but lower latency. If some giant processing machines are acquired, then UMV PA will be removed from the available options. |
|
I've been using them as a cleanroom replacement for ordinary circuit assemblers so I don't have to maintain a multiblock 24/7 |
the upkeep of a cleanroom isn't that much of an issue, power wise the hatch you give it just impacts on the warmup time before it reaches 100% efficiency, and for the maintenance hatch, it's just like any other multiblock that is busy 24/7, but you can use robots to apply tape if luck isn't with you so it's not really an issue. And if really you don't want to pay the upkeeps 24/7, just power the cleanroom just before you start to craft, so you dodge most of the issue, but then you have to face the warmup time. I'd rather accept the complains about the size of the multi required or the lack of room in it than upkeep costs, as it's just some laziness. |
I do honestly hate the size of the cleanroom as well as the warmup time- also, maintenance issues for the cleanroom can straight up just void recipes rather than simply make you spend more power in addition, automating anything inside the cleanroom is just... well, you can't exactly pop a hole in the wall to run an ME cable so you need to make the quantum ring |
|
So what exactly do we do in IV-LuV, when we need lots of circuits (asslines, for example)? Just put more CAs in a cleanroom and parallel them with p2p interfaces? Because making a CAL for each circuit should be left where it is right now imho (End of LuV) |
Wireless connector is a thing |
This is true only if you don't go with transvector interfaces. Transvector interfaces are good to access remotely machines through walls. Also if you don't like transvector interfaces, wireless blocks to go through the wall will not kill your power consumption in comparison to a quantum ring, and you have all the benefits of AE2 inside the CR. |
|
I know this long term change sounds set in stone. I am probably much too late to comment. And I understand somewhat that the implementation for the current PA code is hacky... I still really frown upon these changes. Take this 'vision' to the extreme and in a few years we will have ten different types of LCR because the LCR was maybe too "generic". Generic multis are important to have in a pack with so many specialised recipes, especially with automated expansion. The PA multiblock I have personally adored. As stated previously, it is a nightmare to manually verify there are no missing multiblock-specific recipes for single block counterparts - just creating tons of development busywork imo. And they enable good voltage performance that is impossible to replicate in GT++ multis, without a ton of code hacking and otherwise unnecessary rebalancing anyway. But the main reason I am opposed to this change is in principle. The key advantage of PAs is that they are generic. With one generic setup, I can just keep repeating it and the only thing I need to change is the input machine and interfaces. In the past I have even used opencomputers to automatically assemble and place PAs en masse. The logistics of this - and one of my ultimate goals, a self-expanding base like in Factorio, is virtually impossible with PAs being removed. Like AbdielKavash commented, I at the very least think players should have the choice to use PA or GT++, especially when in endgame 64x PA is more performant. It also has a big building style advantage - consistency. Making a mega base with a consistent style, unless you spam 10+ of each GT++ multi (killing TPS in the process), is virtually impossible. They all have very clashing colours, and I personally find the GT++ multis to have ugly textures, unintuitive operation (especially the 9 in 1), and I don't exactly have much respect for performance of GT++ in general. There is only so much a spraycan and covers can improve. As AbdielKavash also mentioned, wall sharing different multiblocks is also a intriguing creative challenge to minimise space while still having sufficient hatches for recipes and no recipe conflicts, and something which specialised multiblocks can't do with different specialisations. Not only is this an efficiency boost for parallel processing different recipes, but I think it is an interesting puzzle in its own right and would be sad to see it leave. I would so much prefer if PAs could just have a better implementation here. I don't know exactly how 1.12 GTCEu handles the PA implementation, but in my personal opinion that's one of the big highlights of 1.12 GT-centered packs. I played to UHV in 2020 on prospercraft (my completed goal was infinity gear, not Stargate). I remember when they were added a few years ago and almost everyone in prospercraft was frowning at the GT++ multi additions -- frankly they seemed way too hacky at the time in terms of processing speeds and energy discounts. I don't feel that has changed much - in fact, I was hoping GT++ would get phased out. I can see that the opposite has happened. The inconsistency in style, in mechanics, and the huge recipe bloat makes GT++ one of my least liked mods in GTNH. To be clear I am not talking about a complicated recipe chain changes like aluminum or platline production, but, for example, flooding JEI with useless dusts and ingots and components makes recipe navigation so much more difficult. I suppose part of the blame for this falls on how GT tries to be generic, but GT++ just takes it the whole wrong way in my opinion. Tangent: I don't know if this has been considered, a kind of "lazy loading" where GT only generates recipes for material forms that are actually used in a meaningful recipe and not just for an auto-generated texture. For example, only registering the casing block if the casing is used in a recipe or for a multiblock. |
|
Just to clear some misconceptions: GT++ machines should no longer have a TPS or performance impact since 2.4.0 (atleast not a bigger one than GT machines in general), since all their recipe check logic was purged and replaced to use the one in GT5U. So if there is a performance issue now, it would affect all machines and not just GT++. |
|
I remeber using them for oil processing (super heavy to heavy IIRC) which could be easily shifted to destilation tower and for automating assemblers on EV/IV though that was few versions ago |
|
I would like to point out one of the only remaining advantages of PAs over gt++ machines after the batch mode change:
Due to the fact that you can jam 64 UMV machines in the space of a 3x3x3 multi, while most gt++ machines don't reach 64 parallel by the time you completely max out their energy hatch, unless I'm wrong this means that even with the speed boost of gt++ multis, 64xUMV PAs are faster while using a ton more eu/t. It'd probably be bad to delete PAs before we get more megas to replace them, or an upgrade that can be inserted into gt++ machines that allows multi-amp + laser hatches, or anything like that for late game. |
|
Just wonder how we are going to manufacture large amount of processor assembly/nano/quantum series circuits.CAL does not meet the standard as an replacement for PA.Guess we probably need a "primitive circuit assembler" which functions as singleblock cals,but with following features: |
|
I wonder if Processing Array can hold several Integrated Circuit or Lens or whatever blueprint-like item types in one input bus each, because GT++ machines, as I remember, can only hold one blueprint-like item each. If PA can, that is less place occupied and less crafting needed. |
both work exactly the same way in regards to this, not sure what made you think otherwise |
GT++ machine can contain several blueprint items, but can’t it be more comfortable to put one in each PA input bus, or PA can’t contain too many input buses? |
both PA and gt++ can have more than one non-consumed item in each input bus, but yes it's much easier to only use one each most of the time. The number of input buses PAs can handle isn't really relevant to this ticket because by lategame you're only putting one stocking bus on each PA anyway. And lategame is the only time PAs can compete with gt++ now, and even then only sometimes. |
Currently planning to make proposed code for a "Precise Soldering Array" or "Circuit Prototyping Array" that uses single block circuit assembler recipes. Intention is for it to have a footprint similar to current precise assembler, and for recipes to be gated via engraving system casing (recipe comparable to single-block circuit assembler of that tier). Might not get around to it before someone else makes a comparable proposal or something that fills the same role, though. The intention is for that machine to serve the same role as "processing array filled with single-block circuit assemblers" in progression: "making the circuits needed to enable CAL use", and circuit production pre-CAL but post-iridium. |
|
Seconding convenience on a benzene setup. LPF is really useful to have less trouble figuring out logistics for benzene setups with more than 16 fluid extractors. |
|
I've found an edge case where I had to go back to a PA: To process the tungstate family you need two item and one fluid inputs in an autoclave. While the large processing factory supports autoclave functionality, it has separate inputs forced to on in the current version, which means that both the tungsten ores and the sodium have to be in the same input bus. This causes automation problems because a regular input bus would tend to fill up with one of the two once the other runs out, causing a gridlock. The same problem arises if you have unprocessed ores on a separate ME network like I do and can't use a single stocking input bus. This could easily be resolved if the LPF would support split inputs, or as part of the dedicated multis suggestion. |
|
Don't input buses have restricted insert capabilities? As in, they'll only
allow one stack of each item, allowing for multiple different types to be
auto stuffed in willy-nilly.
…On Sun, Jul 14, 2024, 7:25 AM combusterf ***@***.***> wrote:
I've found an edge case where I had to go back to a PA: To process the
tungstate family you need two item and one fluid inputs in an autoclave.
While the large processing factory supports autoclave functionality, it
has separate inputs forced to on in the current version, which means that
both the tungsten ores and the sodium have to be in the same input bus.
This causes automation problems because a regular input bus would tend to
fill up with one of the two once the other runs out, causing a gridlock.
The same problem arises if you have unprocessed ores on a separate ME
network like I do and can't use a single stocking input bus.
This could easily be resolved if the LPF would support split inputs, or as
part of the dedicated multis suggestion.
—
Reply to this email directly, view it on GitHub
<#14437 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD4VLD2BYGYDJIVQHUUWIM3ZMJU37AVCNFSM6AAAAABK3ENJVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRXGMZDSNJTGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Depending on which exact tungsten source you use, a one stack maximum input limits the parallelism to 8-10 out of the possible 64 with a PA. |
serenibyss
added
the
Planning
|
PA is deprecated in 2.7.0 |
and others
This ticket is a placeholder to list every single aspect of the PA that makes them meta for specific tasks.
Please edit this post to list validated cases.
The text was updated successfully, but these errors were encountered: