Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[zxc]

What if killing Imprinter had a negative event or effect associated with it in late-game? Like maybe the Zionites attack the Complex, and they are hostile to you as well. I'm sure Kyzrati could cook up some lore.

[tiniuclx]

While I don't have the extended endgame experience that the other commenters are, I'm sure Kyzrati wants to make the game as fun as possible for people like me too

Right now, I feel like going overweight on treads & legs in order to haul more storage is a no brainer. I think part of what makes the storage meta work is the fact that being 0x1 overweight essentially doubles the amount of stuff you can carry  (100% increase) without much penalty at all. Going 0x2 overweight, by comparison, is only a 50% increase and that feels like much more of a decision on treads & legs.

How would you guys feel about the overweight penalty kicking in sooner? For the sake of argument, let's make it come in effect twice as quickly: for a 40-support build, the 0x1 penalty kicks in between 41 and 60 equipped mass, 0x2 between 61 and 80, and so on. If you keep the support penalty the same, this is a big nerf to going overweight in general, and it also makes being overweight more granular. This would also be a big (unintentional) nerf to wheels, but that can mostly be compensated for by halving the support penalty for wheels.

If more granularity is desirable (Which is probably necessary for endgame) you could make the overweight penalty kick in four times more quickly (0x1 between 61 and 70, 0x2 between 71 and 80 and so on) and rebalance the support penalty across the board.

As a general aside, I think it's important to also think about why something needs to be balanced. I think it's okay for strong items to exist! They make the game fun! What makes the game less fun is items and interactions that are so strong, that they make other parts of the game feel pointless by comparison. Utilities in Materials come to mind - storage is so good, and lots of other things are so bad, that stacking up on storage feels like a no-brainer.

[GJ]

Burnout rate on cld. prop is still probably closer to being on the lower-end of balance than on the higher-end, 400 moves of speed boost is nothing to scoff at when you get to choose the moves you're boosted on and how much cld. prop you want to overload. It's very powerful on practically every map in the game.

A metafield that overloads or damages prop is a somewhat different mechanic. The integrity math is no longer about having enough cld. prop, you can discard flight units and pick up arrays, you can probably comfortably switch back and forth between hover and flight while maintaining a speedy build. This sounds a lot more interesting to me than current metafield and is more along the lines of the powerlevel you want early strong items to have, where it's fun to play and good but you don't feel like you're giving up the world by having your flight/hover build not do ZDC. The fact that cld. prop is a viable alternative to such a metafield is a good thing, ZDC is not a map that'll stop being visited because you have other options, some runs you'll have a particularly favorable seed for ZDC and so on.

[Vectis]

*I crack my knuckles and descend into the fray*

# Shinies
I think that players shouldn't be incentivised to hold onto their shinies until the last possible moment. I would like to see shinies getting used more often and earlier. I'm not sure how to best go about this other than through item storage nerfs, but it's something I'll always be a proponent of. I never want to be hurt by seeing a certain stream where a firepult is hauled from mats to -1/C and never get used. Maybe more master thieves could show up earlier in the game so people would want to use their shinies asap? uwu.

Pay merchants on -7 to hold onto your items and give them back to you on -1? :thonk:

# Item Storage
> One major point in no_stack's favour is that it frees up slots for other utils
I'm in the small camp with moist and juicy capacitors charged for <no_stack>, even though I know there are some big glaring flaws. Quite frankly, I find storage units to be boring items. I would much rather be trying to pretend to be player 2 and try to make builds off of the floor rather than trying to hoard 50 items. If buffing storage units and giving them <no_stack> makes the game too easy, make the world generally harder to compensate?
I feel like whatever the final nerf to storage ends up being, I would like to see a notable exception made for RIF. I feel like RIF existing breaks all the normal storage meta so it should get an appropriate special treatment. But I know that's worth.

If you disregard all of that, though, the biggest takeaway I want to throw into storage units is that *storage unit coverage and integrity is whack*. It just feels so weird to manage storage unit health... They are so tanky that it feels like they might as well not break at all. I don't know if that's a good thing; tbh I'd be fine if storage units got shot off more often and were harder to come by. Maybe that could be your hcp nerf, since you don't find those naturally in the complex.

I'd like to propose re: an earlier discussion; I'd be interested to see each level of overweight get exponentially worse than the last, maybe with an exception for wheels. Yes, I'm looking for a way to bully treads users.
underweight bonus bad.
don't listen to anything mtf says he's anti-botnet.

Thoughts on storage nerfs:
Just to add my two cents; I feel like on flight, storage is already reasonably balanced.

This feels true for hover as well. I think storage being well-balanced is proportional to how much you care about being overweight.

I think hcp. storage should be removed.

In any case:

reducing overall storage capacity should be a goal

# Matter and Energy Storage
I think that energy storage is insanely overpowered right now. I think it would be fine if you couldn't extract energy from batteries on the ground, but swapping wells in remains an issue (realistically they won't get shot off).

# Cave-ins
MTF's digless stealth run changed my mind on this. I think digging can be nerfed further if necessary. Dig nerf good.

# Legs
I'm excited to see what the leg change is going to be. I hope they are renamed to thighs.

# Sterilization
Sterilization is a good and fun thing. I like that it exists and I don't think it should be changed.
> This creates the dilemma that score no longer functions as an abstract indicator of combat strength, and thus loses its original meaning.
Since when was score supposed to be explicitly a measure of combat strength? People get score for all sorts of weird stunts.

# Metafield
To be honest, I never *personally* considered metafield to be that great. I mean, it's okay, but nothing to lose my mind over. But if it really shatters a build type entirely if it gets a slight nerf, like burnout, completely shatters a build archetype, that might be indicative of a deeper underlying problem.

# Traps

No current plans to make full trapper builds viable as their own sustainable thing

Is this a challenge?

# S7

Spoiler (click to show/hide)

I think this map is a lot of fun! It's probably my second favorite one in the game, behind Factory. Lootwise, I agree that it'd probably be fine if SR couldn't replicate AAs, but I don't think it's a necessary change and tbh it would be super annoying to discover that through trial and error. I'd like to see a few more people beat extended without going to S7 before I'm convinced that S7 artifacts aren't necessary for it though. GJ no offense but you are kind of an exceptionally good player.

# Alert

  - Alert changes
   - Gain alert when spotted by a robot, not on killing it
    - Gain alert for reinforcement squads on dispatch
    - Gain alert for investigation squads only on spot
    - No repeated alert gain for the same squad
    - Promotes true stealth
    - Gives non-combat builds more to worry about
    - Removes disincentive to blast robots that have seen you already

This is good but probably needs some workshopping.

Quick addition about the alert thing: No one seems to have noticed, or at least not pointed it out that I've seen/recall, but you currently gain alert from being partial spotted. That's always been a thing (but you probably wouldn't notice that in particular unless you also had RIF).

I literally have never noticed this wtf.

# Hacking
Okay these are good enough I wanna go through them one by one.

1) Nerf botnet values, as 6% is rather high.

I think botnet is fine as is.

2) Nerf operator network values, this is much more likely to have a relatively larger impact on faster builds.

I will cry if you do this.

3) Manual hacks currently have an offensive penalty to them, what is it, -15% per security level? Perhaps they could have a defensive penalty too.

I think the main issue with this is that defensive hacking % is otherwise constant so it'd be a weird exception to the system.

4) Nerf the offensive and defensive values on hackware. 10 is a nice and round starting value but probably not the smallest viable value for being desirable, the fact that you can kill an Operator for a regular hacking suite feels very powerful for stacking hackware equipped or in inventory.

Ehhhh I think they're fine.

5) Magnify the penalty for pulling schematics that are prototypes, and possibly be more strict about making high-value items prototypes, lrn. sensor array comes to mind.

I'd take this a step further. Remove direct hacking schematics. I hate scroll of wish mechanics.

# Closing thoughts

But we can talk about crazy things without committing to them.

Yeah, and I'm really down with the idea somebody mentioned of scattershotting out builds and forcing playtests to see which are best. Like what MTF did with dig nerf. Sadly, the issue is I feel like we're all too stubborn to change our mind based on playtesting... I know I am. None of you will ever be able to tell me Hype EM is bad.

I recently lost a game on stream where there was a Researcher guarding the door to the S7 cache... I was on treads and didn't have enough hacking to open the door. I tried to use FLK to assimilate the researcher, and it missed. It had a 95% chance PLUS the 10% targeting bonus (which I know doesn't get added on), and yet I still missed...

LMFAOOOOOO~ nerd

What if you didn't get scanned instantly?

Uh... This actually wouldn't be terrible. I think people would be just as terrified of researchers, so there'd be the same level of fun, but you leave in that "cave-in" style incentive for emergency manuvers.

Cogmind is explicitly designed for even horrendous part loss and misplay to be recoverable into a win, which for a roguelike is probably too forgiving, but certainly runs should still be loseable.

Nahhh I think it's fine for a roguelike to have 1shot protection

I have always felt that there are too many lower/upper cave maps and they should be compressed to a single (hopefully more challenging floor).

I agree! But I think changing the way caves plays is also on *the list*

Before I go here are my two dreams:
1. I think you shouldn't be able to see the mass of unidentified parts until you attach them.
2. Garrisons should always loop and RIF should in turn be nerfed later in the game to offset the snowball. As it stands I feel kind of bad getting no loops my whole run orz even though I know that's a rare misfortune.

Writing posts on the forms is so exhausting holy sh!t. I forget I'm surrounded by like, 40 year olds with attention spans when I'm in the Discord chat and I can go full feral rat mode.

[Tone]

S7

Spoiler (click to show/hide)

I'd like to see a few more people beat extended without going to S7 before I'm convinced that S7 artifacts aren't necessary for it though. GJ no offense but you are kind of an exceptionally good player.

Valguris has done at least one entirely branchless (no S7 included) run recently, although they are also an exceptionally good player.  I'm not sure why anyone would think that S7 is actually necessary, but there's almost no reason not to go there usually.  It's low risk (assuming you aren't entering at very high alert) and potentially very high reward.  The map is small enough that you can leave quickly (via predictably placed exits) if you run into any trouble, and you are given plenty of DNIs and teleporters if you want to have an actual near-zero-risk panic button.  It's trivial on flight builds and on combat I'd much rather be in S7 than on a standard Research floor.  I do have a run planned soon for recording/streaming that would be skipping S7 for ++ but that isn't the intended focus 

[GJ]

Because it's rare for the community to display even a rough consensus on things, I'd like to summarize two discussions here, the links should work if you have access to #cogmind-spoilers and #cogmind-redacted.

Discussion #1: https://discord.com/channels/205277826788622337/453076153817759765/766735551364726814

There's a rough consensus here that pulling schematics should or could reasonably be more difficult than currently, but no significant agreement on what the solution should be. The solutions discussed are roughly similar to what has already been brought up in this thread.

Discussion #2: https://discord.com/channels/205277826788622337/338852785154162688/766750651669020672

Strong consensus that S7 sec-1 terminals are abusable. Presumably they're sec-1 so that 'Open' hack would have its current success-%. Now that imprinting can't interact with that hack and force-ram exists, there's less need for a strong likelihood that you succeed the hack even without hackware. S7's guaranteed AAs are also capable of opening these, just gotta get inside one of them first.

[zxc]

I think I like the idea of indirect schematic pulling going away, but it's a fairly sizeable shift to the flight game. To compensate a bit, more guaranteed schematics (a la DM and Zh) would be sweet.

I don't know if a reasonable argument can be made against S7 sec-1 terminals going away. One could make a similar argument for -1 C entrance terminals, but I'm less bothered by those.

[muxecoid]

Nerfs, nerfs, nerfs... Can we have some buffs?
Let's buff cryofiber webs via nerf to everything else.
Mechanics change - make heat dissipation percent of current heat over base rather than fixed value. Change existing heat dissipation to 0.6 and make it work as percentage of current excess heat. Build that was at exactly zero heat balance before the change will now achieve equilibrium at 167 temperature. Enjoy your targeting penalty... But if your heat generation doubles you do not go to infinite heat, you stabilize at 333.

[GJ]

I'd like to suggest an integrity nerf to shieldings/casings. The concept of sacrificing a utility slot to protect a certain type of part from damage/RNG is cool, but their numbers seem high in a way that contributes to the ease of maintaining extremely powerful items and the same build throughout the game, and they often feel more efficient than other defensive utils even when losing such parts to RNG wouldn't be the end of the world. In other words, I think you are a bit too strongly incentivized to fab 200/300 integrity's worth of shielding and repair them for almost 200/150 integrity at stations (exp./imp. numbers). Fab/repair pattern doesn't apply to casings but they are very inventory-efficient at 200 and rather easy to get (even when not imprinted!).

Base shielding maybe doesn't need to change at all, they don't get used. I suspect Imp. still feels good at 100-integrity and Exp./Casing at 150. 66%/90%/100% are still very good numbers and you'll have reason to equip them for that, but you're less invulnerable to attrition and utility shielding doesn't allow you to scoff at cave-in risks as much.

I see core shieldings have 50/100/200, perhaps all the shieldings could be standardized at 50/100/150? This is an unnecessary nerf to Exp. Core Shielding, could make up for that by reducing its rating from 9*, builds on a core clock have a difficult time interacting with 9* parts. I get that this is the rating that disables them from repairs, but it's not powerful enough that blocking that prevents any real abuse. Sterilization is much more effective at preventing the sort of abuse that I assume the repair-block is intended for.

[zxc]

Buffing by nerfing everything else is my favourite method!

I really like the concept of equilibrium temperatures. Very similar to the heat stuff I was suggesting in an earlier post, where different bots have different heat baselines, and sensors identified bots by their heat signature.

Shielding nerf sounds good.

[Pimski]

One thing that has been discussed to some degree in the discord is the fact that fabbing strategies currently dominate the game to a very large degree, especially on fast propulsion. In this post I'd first like to name a number of potential issues present in the way fabbing works. Then I will introduce an example of a way I believe the current fabbing system could be improved. Lastly, I'll argue why I think such a change would solve the earlier-named issues.


Issues;
1. Hacking-focused builds can fabricate an entire extended build. This method feels somewhat illegitimate, as it is considerably easier to execute than most other strategies for assembling extended-viable builds. Because of this discrepancy with other strateges, on a lot of the faster build archetypes preparing for extended through fabbing feels rather mandatory. Especially on such builds, the strength of lategame fabbing serves to invalidate scavenger-style gameplay to some extent. This is unfortunate for the people who enjoy such gameplay more.
2. There is no compromise-option; either you are fully equipped to fab, or you can hardly fab at all. If you have enough hackware to fab semi-reliably, the only real limit in the number of items you can fab is the fabricator quarantine. Hackware builds can consistently fab enough in this allotted time to get together a complete build. Scavenger-style builds that run no or little hackware can rarely even fabricate a single item. Destroying hubs is somewhat of a remedy against this, but arguably the contrast between these two extremes is still too stark.
3. Fabbing strategies disincentivize risk-reward options to some extent. Scavenger-style builds are often incentivized to take on branches and fight dangerous out-of-depth enemies for rewards. Fabbing builds don't need to rely on such rewards; they only need hackware, and their extended succes is already pretty much guaranteed. Even if branch rewards can be useful for them as well, there is never a reason to feel forced to take a large risk.
4. Fabbing builds overlap with machine hacking builds. This is a bit overly convenient, as machine hacking is one of the most consistent ways to make 0b10 floors easier in the midgame. This ease of blazing through the midgame, combined with their strong lategame, makes fabbing strategies far too consistent and trivial.
5. Setting up a fabbing-centric build is too straightforward. Fabbing builds require little to no resource-management. Their game-plan consists of a very small number of uncomplicated steps. Get hackware; hack for schematics; fabricate your build; equip the parts and win. This again leads to a lack of meaningful and interesting decisions when playing fabbing builds. (Not because of the lack of risk, which is already covered in 3., but rather because of the lack of meaningful resource management and adaptivity.)



Example proposal of altered system;
Fabbing items requires cartridges. Blank cartridges are a limited resource, and can be obtained as branch rewards, or by prevailing against similarly difficult challenges. At terminals, the player can hack for a schematic to write it onto a blank cartridge in inventory. Once a schematic is written onto a cartridge, it can not be overwritten. Cartridges need to be inserted into a fabricator to fab, and are returned after the item is fabricated (possibly losing some integrity, so use is limited?). In addition to these changes, the hacking difficulties for both schematic pulling and fabricating are drastically lowered.

These changes will have the following consequences:

1. The number of (distinct) items that can be fabbed is limited by the number of cartridges the player acquires. This means it is no longer (easily) possible to fabricate entire builds.
2. Compromise builds are valid. Since the hacking difficulty is lower, even builds with lower amounts of hackware can meaningfully supplement their build with a small number of fabbed items.
3. Incentivizes risk-reward. Cartridges require taking risks to obtain, making it more challenging to get into a position where you can fab a large number of items.
4. There is only small overlap with machine hacking. This makes fabbing builds less oppressive and omnipotent in the midgame.
5. The setup process a little more complex. There are a larger number of decisions to make, such as which items are completely necessary and which a luxury. There is a larger number of non-trivial steps involved in getting your fabbing build into a position where it can take on the lategame.


In short, I believe the current balance of fabrication strategies can be massively improved. There are obviously a myriad ways to go about implementing such a balance change in terms of mechanics. The above contains a description of what I consider the be one example of such an implementation. In replying to this, I would appreciate it if people could distinguish between disagreement with the named issues and disagreement with the proposed example of a way to implement fixes to these issues. I think discussion about the prior is more useful, as kyzrati is unlikely to be worse than me at thinking of a system that fixes these issues.

[Pimski]

Addendum;

To add to the previous post: the most obvious issue is that cartridges would require a lot of inventory space. If this is judged to be too harsh, it is a problem that can be easily solved. Simply replace the idea of cartridges with the idea of memory slots integrated into the core. These then take no inventory space, and otherwise function in exactly the same manner.

[Pimski]

Addendum 2;

Rather than distinct memory slots, a more granular memory capacity is also an option. Then higher tier prototypes could take more memory than lower tier regular parts.

[tiniuclx]

TL;DR: What we, the players, need to do is achieve consensus on a particular issue. If we can do that, Kyzrati has a great track record at fixing said issue. Pimski's post is a great start because it explains "why" and "how" something is not fun - it's not just about something being vaguely broken. The more people we can get to agree that this is a problem, the stronger a signal it will be for Kyzrati.

Community solutions matter a lot less than community consensus on problems because none of us have actual experience with fixing the game. Kyzrati, however, has been doing it full time for the past five or so years!

Pimski's post is a great starting point for identifying the problem. If you agree with the quoted text, say so in this thread! If you don't agree, also say so in the thread, so we can find what the actual problem is.

...
1. Hacking-focused builds can fabricate an entire extended build. This method feels somewhat illegitimate, as it is considerably easier to execute than most other strategies for assembling extended-viable builds. Because of this discrepancy with other strateges, on a lot of the faster build archetypes preparing for extended through fabbing feels rather mandatory. Especially on such builds, the strength of lategame fabbing serves to invalidate scavenger-style gameplay to some extent. This is unfortunate for the people who enjoy such gameplay more.
2. There is no compromise-option; either you are fully equipped to fab, or you can hardly fab at all. If you have enough hackware to fab semi-reliably, the only real limit in the number of items you can fab is the fabricator quarantine. Hackware builds can consistently fab enough in this allotted time to get together a complete build. Scavenger-style builds that run no or little hackware can rarely even fabricate a single item. Destroying hubs is somewhat of a remedy against this, but arguably the contrast between these two extremes is still too stark.
3. Fabbing strategies disincentivize risk-reward options to some extent. Scavenger-style builds are often incentivized to take on branches and fight dangerous out-of-depth enemies for rewards. Fabbing builds don't need to rely on such rewards; they only need hackware, and their extended succes is already pretty much guaranteed. Even if branch rewards can be useful for them as well, there is never a reason to feel forced to take a large risk.
4. Fabbing builds overlap with machine hacking builds. This is a bit overly convenient, as machine hacking is one of the most consistent ways to make 0b10 floors easier in the midgame. This ease of blazing through the midgame, combined with their strong lategame, makes fabbing strategies far too consistent and trivial.
5. Setting up a fabbing-centric build is too straightforward. Fabbing builds require little to no resource-management. Their game-plan consists of a very small number of uncomplicated steps. Get hackware; hack for schematics; fabricate your build; equip the parts and win. This again leads to a lack of meaningful and interesting decisions when playing fabbing builds. (Not because of the lack of risk, which is already covered in 3., but rather because of the lack of meaningful resource management and adaptivity.)
...

I think Pimski is onto something here! I think the summary of the problem is on point, and there is nothing here I diagree with. For me, the most fun way of playing Cogmind is by dealing with problems as they come. I don't really like planning out my entire run in advance, I want my games to surprise me! Some of my most fun runs happened when I was in a position to be greedy and do something stupid. When it pays off, it feels great! And even when it doesn't, I know I was getting greedy and I still had a fun time doing it.

However, when I was playing fab builds, it was more about avoiding doing anything risky so that I can fab what I need. That, and staring at spreadsheets. Granted, we have better spreadsheets these days, but I'd rather be actually playing the game!

Pimski's cartridge idea is definitely interesting, and it solves some problems, but it introduces quite a few more. If cartridges are items, then the schematic rewards of DM and Zh need to be redesigned, and inventory management becomes even more painful. I have touched on the latter point in my previous post.

If they're not items, but something intrinsic to Cogmind like RIF abilities or the currently known schematics, the UI may get more complicated. As a returning player, I'm actually having trouble grok everything the UI is trying to tell me, and it is already hard enough to find out how to do something if it's not all that common (such as opening the RIF upgrades window - I play almost exclusively in keyboard mode, so the button wasn't even there for me). This would be even harder for new players, of course.

However, I think it would make the gameplay quite interesting: finding a cartridge is now an opportunity to fix something about your build, or just to get greedy and prepare for endgame.

My advice to Kyzrati is to listen to us, but only a little bit. The community used to complain about bot hacking being either broken or boring, and about there not being much of a reason to go into garrison unless you were trying to break the game ^{*cough* Pimski *cough*}. The community did not come up with RIF, which I believe addressed all of those problems, and created an entirely new style of gameplay that's actually quite a lot of fun.

Then, the community complained about RIF not scaling into the endgame, so Kyzrati added RIF upgrades, which at the very least are very fun, and they add a healthy amount of variety to RIF runs. They also encourage greed, which is very fun. I don't know if RIF is viable in endgame, but the RIF upgrade system are a very fun change that the community couldn't have come up with.

Finally, mines were boring and new players seemed to get stuck in mats, so the Exiles were added, which I believe are loved by old and new players alike. The exiles in particular, and all of their items, are not something that can just be designed by the community.

[GJ]

I largely agree with Pimski's identification of the issues. Personally I think the main issue with the current system has much more to do with what happens when you're fast or hacky rather than the accessibility of fabbing to slow builds without a hack focus. Partially this is because like Vectis, I dislike wishing mechanics and prefer fabs/repstations to have real variance in their value and occasionally not do much.

A potential downside of making wish-y schematics more accessible to builds across the board is that it will exacerbate balance asymmetries that are not currently an issue. It's a semi-obvious truth that powerlevel variance is not inherently bad, one could argue it's the opposite, and things are only "overpowered" when they somehow warp the game around themselves. This can end up happening by making an item more accessible without changing its powerlevel. There are schematics where if a no-/low-hacking slow combat build could consistently acquire them, they should wish for them every game, this is one of the issues fast builds suffer from right now. Currently there are relatively few value schematics that a slow, not-a-hacker build can consistently acquire, ultimately I think it's much more fun to just either find those items/schematics or not find them in a run.

Let's look at what fabs and scanalyzers actually do for slow builds without an explicit hack focus:

1) You find a high-tier item in e.g. Chutes: faulty, broken, functioning, whatever. You can gain additional value from it by scanning and fabbing it, processors in particular you only need 1-2 functioning instances to have them last about the entire game. Even with zero hackware in Chutes it's not particularly difficult to find floor hackware or grab it from operators to do one scan + fab at some point.

2) OOD preloads in fabs, I believe this is a semi-recent addition. I once got to fab an Exp. Force Field in Factory, this sort of variance as an alternative to just slapping a trojan(hauler) on the fab seems fun. Fabbing the preload is potentially easier than fabbing a schematic you already have, which is an interesting nuance. You might also want to fight an investigation to get the fab off, given you don't have the schematic, and there is that one force hack to consider too.

3) Non-core shieldings are low-ish ratings. This means Imp. shows up early, and can be scan+fabbed with some ease. This is a main way for combat to find value in fabs/scans. Instead of having to find multiple backups of some item that's valuable to your build, you can extend its life with shieldings. As is evident from my call to nerf these, I actually think these are a little bit too good across all builds and even just finding imp. shieldings on the floor is quite powerful.

4) You can get a fab to make you one of the schematics you got from DM/Zh.

[Kyzrati]

I've been making a bunch of modifications this past week, one of which in particular has a bearing on some discussions in this thread, so to bring it to the forefront:

- All special-purpose terminals, including any door terminals, will no longer be hackable except to open the door or do specifically what they were meant for. They're all level 1 terminals, after all, and having access to that many, especially in certain areas, always made it way too easy. I always liked the thematic concept of using door terminals to hack unrelated systems, but it's OP and not really necessary. In any case, we'll see what kind of effect this has.

RE Metafield: I can understand Pimski's arguments from his POV, but others have good reasoning as well.

but my point is these effects are extremely damaging to low integrity propulsion and as a result are only used sparingly.

I think that's probably the point, especially considering that speed is already quite good and not being able to maximize your potential speed all the time is a nice balance goal.

In my opinion if metafield also degraded prop the benefits would not be worth it over just overloading standard cld propulsion because:

But if the new balancing factor is part integrity, Metafield's other drawbacks would likely be reduced to compensate! We don't need to make the assumption everything else would remain static in this case...

RE Fabbing:

5) Magnify the penalty for pulling schematics that are prototypes, and possibly be more strict about making high-value items prototypes, lrn. sensor array comes to mind.

I'd take this a step further. Remove direct hacking schematics. I hate scroll of wish mechanics.

I think you meant indirect hacking here? They're definitely important to the design in terms of allowing for attempts to get a few pieces of a build together, though yeah we can nerf fabbing a bit overall, on which most everyone's in agreement. Part of the issue people see is that flight has a much easier time actually putting together an entire build since they're less likely to lose parts at all, anyway (and generally have a bunch of hackware), while the fabbing system is meant to still be somewhat accessible to combat as well (which it is).

At the same time, flight with hackware is... kinda meant to be able to do this in the first place?

I do think Pimski's of "cartriges" is a neat idea. It would be a lot of work across the board in terms of mechanics, balancing, and lore, but who knows something like that might work.

At the same time, honestly this alternate system could potentially be easily implemented using the existing fabrication component system which we're simply not using yet, the one that requires providing additional components in order to build a given item. Some of you probably don't know this already exists, since it's never been used, but it's in there...

It's an alternative way to limit fabrication without attacking it from a schematics angle (although it's just a limitation in number rather than by type, so somewhat different in substance).

How would you guys feel about the overweight penalty kicking in sooner?

Indeed we covered that earlier in the thread and that's something which is happening.

I never want to be hurt by seeing a certain stream where a firepult is hauled from mats to -1/C and never get used.

Sorry that run hurt you, Vectis. I repeatedly found that unfortunate myself :P

If buffing storage units and giving them <no_stack> makes the game too easy, make the world generally harder to compensate?

Actually I think the idea is that for a lot of people it would actually be the exact opposite of that, making the game harder xD

If you disregard all of that, though, the biggest takeaway I want to throw into storage units is that *storage unit coverage and integrity is whack*. It just feels so weird to manage storage unit health... They are so tanky that it feels like they might as well not break at all. I don't know if that's a good thing; tbh I'd be fine if storage units got shot off more often and were harder to come by. Maybe that could be your hcp nerf, since you don't find those naturally in the complex.

No, losing storage is terrible, so it's balanced such that you might need to slowly work towards getting replacements, but otherwise it's going to be pretty reliable in the short- and medium-term. We've already been there before in alpha, and it's very very clear that having unreliable storage is like the fundamental bane of fun.

I think those aspects of it are in a fine place.

1. I think you shouldn't be able to see the mass of unidentified parts until you attach them.

Joshua and I have had this discussion before. It's rather high on the list right now, although I hadn't yet gotten asking around what more people thought of that.

Yeah, and I'm really down with the idea somebody mentioned of scattershotting out builds and forcing playtests to see which are best.

Yes that was my idea, and the plan, actually, for example starting with a basic <no_stack> test just to see, but honestly these things take time to properly set up and test so they have to really seem worth it in order to invest that effort, and the support for <no_stack> has surprisingly been very lackluster. People do clearly want change in the storage area, and that's happening for sure, but <no_stack> is a step too far for almost everyone!

[Tone]

All special-purpose terminals, including any door terminals, will no longer be hackable except to open the door or do specifically what they were meant for. They're all level 1 terminals, after all, and having access to that many, especially in certain areas, always made it way too easy. I always liked the thematic concept of using door terminals to hack unrelated systems, but it's OP and not really necessary. In any case, we'll see what kind of effect this has.

This sounds like a fair change, is fitting in theme (the terminals may be locked out of the wider terminal network), and adds an appropriate difficulty to some of the research branches in particular where these are most common.  How would this look on prefabs where the door is already open, like the Extension and Quarantine entrance variants?

[Kyzrati]

How would this look on prefabs where the door is already open, like the Extension and Quarantine entrance variants?

No different, just same old Door Terminal.

[zxc]

If I were designing a complex I'd definitely have the door controls be on a separate network to the rest.

I've been liking a lot of the posts recently. Pimski's summary of the issues of fabrication I largely agree with. I'm not sure about the suggestion, though. I'd like items and inventory to be used less, not more.

I like the changes Kyzrati has mentioned. But I'll say that I'm not too keen on metafield having a drawback related to integrity. Whether or not it's balanced, it 'feels bad'. I'm also opposed to propulsion overloading for the same reason. Exile items being balanced like that makes sense though, to me.

[muxecoid]

Door terminal change will make -9 storage significantly harder. Anything to compensate?

[Kyzrati]

Door terminal change will make -9 storage significantly harder. Anything to compensate?

No, it's fine, and harder is good if true. If referring to non-/low-combat builds, then indeed it should be harder for them--Storage was always meant to be that way, a low-depth dangerous but potentially high-reward area.

Really the lack of door terminal hacking naturally increases difficulty to some extent across many areas, which is the point of doing it

[GJ]

It's a bit inherently "unclean", but I'll say it out loud in case it has some merit: how about two_stack instead of no_stack? As in your third storage unit does nothing, your second one does. For now let's ignore the question of whether this would allow you to equip 2 humpbacks, that's not too important and the "real" storage units matter more. There's a few things this specific middle-of-the-road aims to achieve:

• As with no_stack, it solves the issue of lots-of-storage feeling almost mandatory by putting a cap on it. In a game of attrition it's almost inevitable that you want as much storage as reasonable: your build-type will have some extremely high-value utils that it wouldn't drop for extra storage, and anything below that line it willingly replaces with storage(=additional backups). This results in same-archetype builds looking very similar across runs with no small optimizations of less-obvious utils to fit the specific situation, they just run the same-ish great-value utils and storage.
  
  In practice most builds run lots of inventory spaces and the ones that don't can't fit that much mass. It's a bit difficult for mass alone to balance the question of storage, often you should downgrade to lower-mass parts, more support or overweight in order to run more storage and carry the world, resulting in quite a bit more inventory management than the game needs to feel good. There is some nuance and build-variety to the mass-equation, but I feel loads-a-backups is at least a bit too oppressive for mass considerations to truly deal with it in a way that's satisfying. To some extent the "unlimited" flexibility you have to go for additional storage warps the evolutions players are willing to go for in favor of an even greater utility focus than they would otherwise have, this is another issue.
  
  
• A potential issue with no_stack is a too great loss of flexibility. It's more flexible than storage units not existing and simply giving Cogmind more inherent inventory slots, but you run into issues like... carrying a storage unit you plan to upgrade to feels bad when you can only equip one at a time. Two storage units allows you the nuance of something like Lrg. with another Lrg. in inventory, eventually putting on the second one. Or Lrg+Med with a Lrg. in inventory to eventually go Lrg. x2.
  
  
• It may well be reasonable at current numbers. You could interpret humpback as 2x storage units, or you could allow players to equip two if they really want to carry tons and then they have to deal with the unusual mass and coverage of double humpback. You might play a wheels build like that. 2x Hcp. for 20-inventory slots seems a reasonable size that isn't annoying to use, you can genuinely carry stuff but it's a manageable inventory.

More than anything this is meant to share my perspective on storage, so I will add an anecdote about the evolution of storage on combat builds. In late Alpha average combat capacity was around 20, it didn't feel like an unusual amount of inventory-paralysis relative to the average RL, though maybe by just a little bit, possibly that's just inherent to Cogmind where you have to think more about your inventory items than you would about potions. Since then both support and inventory-per-util-slot have gone up, relatively often I find it a no-brainer in terms of winning or playing the build well to go for an inventory size where scrolling through it annoys me. I don't have a strong grasp of what the average capacity is nowadays, it might even be around 30, and really large inventories are more common.

[mtf]

Alright, I'm a man of my word, so I'm going to make a post that goes against everything I believe in...

I support nerfing storage.

It's clear to me now that even some of the game's most difficult challenges can be (fairly) taken on even with minimal storage, and if that's the case then the only argument remaining to keep storage un-nerfed is that it allows players to carry extremely large fun/meme items. While I do feel like nerfing storage will probably increase the overall difficulty of cogmind, it will probably make the game more interesting overall due to the extra slots that are available to use for other utilities and things. It will also reduce inventory paralysis which I know is a common complaint about the game currently. I'm not sure if I support the no_stack variety of the storage nerf, but I can agree that something should be changed, and I'm optimistic about trying out a no_stack build of the game to see how it works for myself.

So lets throw some storage nerfs at the wall and see what sticks. I'm going to go take a shower now, but after writing this I'm not sure if I'll ever feel clean again.

PS: If you want to see what changed my mind, just watch GJ assault the W base with minimal storage:

[Kyzrati]

So yeah as I've mentioned before and GJ reiterates above, no_stack has the unfortunate side effect of likely reducing build flexibility a bit too much.

"two_stack" is an interesting idea that doesn't seem to have been brought up before, and having two storage units does indeed allow for quite a lot of flexibility and what I also feel is "enough" storage for even combat builds--overall somewhat more challenging but also more fun (which is why I tend to run two myself unless the run gets weird or I'm doing RIF). two_stack is also kind of a weird concept due to how arbitrary it feels on the surface, without having been used anywhere else and thus being hyperfocused on storage here... Of course, storage is also a very central and unique part of a build, so special treatment is not unwarranted.

Honestly in terms of balancing future numbers that was kinda my intended goal, to have approximately two build-appropriate storage units being optimal in many cases, though this is hard to balance in practice due a combination of the potential flexibility of mass support and the amount of storage capacity you get from a single unit.

Anyway, at this point we can only speculate so much and some test builds are in order. Right now we're behind where I wanted to be on that front due to all the work I've been putting in elsewhere, but anyway it'll happen before Beta 11.

[zxc]

Whatever the gameplay potential, two_stack bugs me as too arbitrary.

A potential issue with no_stack is a too great loss of flexibility. It's more flexible than storage units not existing and simply giving Cogmind more inherent inventory slots, but you run into issues like... carrying a storage unit you plan to upgrade to feels bad when you can only equip one at a time. Two storage units allows you the nuance of something like Lrg. with another Lrg. in inventory, eventually putting on the second one. Or Lrg+Med with a Lrg. in inventory to eventually go Lrg. x2.

I'm not buying this. With no_stack, you can do the exact same thing of carrying a lrg storage unit while you have med equipped, and hoping to upgrade soon. The only question is how many 'steps' of unique storage units there should be, and what the thresholds should be.

It may well be reasonable at current numbers. You could interpret humpback as 2x storage units, or you could allow players to equip two if they really want to carry tons and then they have to deal with the unusual mass and coverage of double humpback. You might play a wheels build like that. 2x Hcp. for 20-inventory slots seems a reasonable size that isn't annoying to use, you can genuinely carry stuff but it's a manageable inventory.

This is basically the same as 2x original number no_stack. What is the difference between no_stack and two_stack, then? two_stack has the issue of being arbitrary, and it allows for more steps between capacity thresholds. The former is clearly a downside. As for the latter, we can compensate by introducing more storage unit types, say a couple more. But I kind of like having a substantial capacity difference between the storage units so that your choice is more decisive and consequential.

Oh and another difference is that no_stack saves a slot. I think that's a good thing as you get more slots to play with. Perhaps it makes the game easier but I'd rather compensate for that elsewhere.

For those who think no_stack would not allow hauler-type builds, I think humpbacks could serve the niche fine. For two slots, you could get say, 24-26 inventory capacity increase for a total of 28-30 inventory capacity. This is still a substantial inventory. Perhaps you could introduce a Mega Humpback which is three slots and gives even more. But the objective of limiting inventory size overall would be achieved. We won't have people running around with 50+ anymore, and reaching 30 would be a very deliberate strategic choice rather than something which just happens naturally when you slap on yet another storage unit. Oh and you even get humpbacks from exiles, which is exactly where people like to engorge themselves on meme items.

Another reason I like no_stack is because you can design the storage units for different efficiencies. E.g. sml storage would be the most mass-efficient. Hcp the most slot efficient. Humpback the most storage at the expense of slot efficiency. Med and lrg being all-rounders. You can also tweak the values without concern about what happens if you combine them, making for easier balancing. You could ditch the current scheme of +2 inventory for 2x mass of the previous storage tier if you wanted to.

Ultimately, storage units are less interesting than parts that actually modify your combat abilities or infowar capabilities. no_stack does shift the emphasis away from storage units, and I would argue that that's a good thing. There are lots of interesting parts in Cogmind, and it's a shame to pass them up all the time, especially in the early-game, because filling your slots with storage is a necessary evil.