Print

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

[mindreader]

Since every hack and trojan I know of has at most one argument, would it be possible to accept both alert(purge) and purge(alert)?  I hope it might be a really small code change, depending on how you implemented it.

I realize there is already a little leeway, but I'm really bad about this and often times I'll do something like squad(enumerate), fail, then try squads(enumerate), which also fails, but penalizes me (I'm not sure if one of those is correct or not).  And so I have to search through my history, make a guess or else refer to a cheat sheet for lesser used operations.  And it doesn't help that sometimes the verb is the function and sometimes the verb is the argument (I think).

I've also seen very new players struggle with this for early commands like alert(purge).

[Kyzrati]

It's true that the nouns and verbs don't always appear in the same order (it would be ideal if that could be consistent...), though that was unfortunately required in order to maintain a more important prioritization where multiple related hacks share the same first word.

I feel that also allowing reversal would lead to more confusion--I'd prefer players learn the logic behind the existing commands rather than allow multiple different commands for the same hack, so this isn't a change I'd really like to make. (That said, I've been thinking of another potential solution to your issue which I'm not ready to talk about right now.)

Anyone else feel free to chime in on this, too, though!

(Also, for common manual hacks you do make use of the command buffer, yeah?)

[Decker]

Anyone else feel free to chime in on this, too, though!

I agree that it'd be nice if the reversals were accepted too. Or maybe just don't penalize codes that don't map to anything because of typos. Some players might use the opportunity to launch a dictionary attack to discover unknown codes, but I don't think it's a big problem in practice. It's easier to just look up the spoilers.

[Kyzrati]

Alright, I just came back from a bike ride (where pretty much all my better ideas come from ), and have a new feature that will solve all of these usability issues in one go. So say no more, Alpha 12 will include something cool... I'll get back to this thread after I implement it at some point

[Kyzrati]

Latest new manual hacking feature #1: May I present autocompletion

[Happylisk]

That feature owns.  I'm sure it'll exclude the trojan and brute force hacks, which is ok since they're secret anyway and the ones you commonly use are easy to remember.

[zxc]

Can it include secret hacks once you discover their respective lore entries?

I'm sure Kyzrati has thought of this and just hasn't shown that part because it would be spoilery.

[Kyzrati]

it'll exclude the trojan and brute force hacks

Oh no it's much smarter than that . It adds Trojans to the pool automatically as NPCs/lore teach them to you (or if you use spoilers or whatever and type them in directly yourself at least once). Type in "Tr" and bam, all your applicable Trojans are listed.

No halfway decent implementations here!

[Decker]

(Unrelated, but since we're talking about hacks...)

Shouldn't force(jam) succeeds much more often than it does already? It seems like I have a higher chance of success of sealing a garrison using the direct seal command than by jamming it.

[Kyzrati]

You're right, that was the intention, which is why Jam has an 80% base success rate, compared to 30% for Seal. But as an indirect hack it turns out that Force(Jam) is actually a little harder than sealing on a tier 2 or 3 Garrison Access (not quite what was intended...). On tier 1 it's still 65%, so more than twice as easy as sealing.

What I need to is put all the hacking values into an actual spreadsheet and adjust/finalize all the values taking into consideration all tiers and indirect hacks. I've planned to do this for a long time, but have wanted to wait until all the hacks are in the game to balance them all at once. We're at 82 hacks now and that's the majority of what will be in there, so I'll do a sweep and see what needs to change.

That said, tier 2/3 machines are always going to be quite difficult to hack without any hackware, by design.

[Decker]

Glad to know it wasn't my imagination this time

With respect to the chances of hacking, they seem rather reasonable to me right now, except for level-2/3 fabs. Even with 2 advanced hacking suites, you don't have much chance to build a high-level part.

Currently, level-1 machines are pretty much always better than higher level machines, unless you're a hacking god. Then you either don't care or want the faster build times on fabs (but tracing is still a problem). That is especially true for terminals where level-1 indirect hacks are still better than level-3 direct hacks. Since you intend level 2-3 machines to be generally useless to everyone but a great hacker, I guess that means your design is working well

Generally hacking suites are much better than system shields. It sometimes causes problems when all you get are system shields from operators, but it's a minor issue.

I've been thinking about what could be done to make hacking viable for a combat build. Unfortunately it's not easy. I would favor reducing the coverage of hackware from 2 to 1, but it still doesn't solve the fundamental issue. Over time all your hackware is going to be shot off if they have a non-zero coverage value (flak cannons are especially nasty), and it usually doesn't take long. But if you reduce coverage to zero, it'll become overpowered.

I toyed with the idea of equipping nothing but hackware, and using improved utility shields to protect it. That's a rather extreme and limiting option, though. Equipping any high-coverage utilities like sensors, armors, storage units render the shield useless.

With that said, I'm off to try that melee build. It seems a rather bonker concept since melee is slow and you get only one attack. Even if you do 3 million damage per hit, most of the time you will still hit some non-core part and waste your attack with anything but a spear. Spear gives you +33% chance to hit the core, so I guess that's about 60% chance to hit the core. With microactuators and melee analysis suites there might be a way to make something work.

[Kyzrati]

Since you intend level 2-3 machines to be generally useless to everyone but a great hacker, I guess that means your design is working well

Yep, intended, Mr. I-don't-use-much-hackware

Generally hacking suites are much better than system shields. It sometimes causes problems when all you get are system shields from operators, but it's a minor issue.

Yeah this is intended, too. They're generally more of a secondary hackware option for when you already have good enough attack and would like to get more uses out of a single terminal (or protect allies from Progammers, which will come into play with certain ally-based builds that will continue to see increased viability).

I've been thinking about what could be done to make hacking viable for a combat build. Unfortunately it's not easy. I would favor reducing the coverage of hackware from 2 to 1, but it still doesn't solve the fundamental issue. Over time all your hackware is going to be shot off if they have a non-zero coverage value (flak cannons are especially nasty), and it usually doesn't take long. But if you reduce coverage to zero, it'll become overpowered.

It's not really intended for combat bots, but my experience with hackware-plus-combat has been different. It tends to last plenty long (usually forever), but then I also favor real armor over propulsion-armor, as the former does a much better job of protecting weaker parts like processors.

Even if you do 3 million damage per hit, most of the time you will still hit some non-core part and waste your attack with anything but a spear.

Actually, just a little while ago on chat we were talking about allowing damage overflow transfer, which is something I'll be looking into. That could have some nice effects for combat, including melee. It could also be quite OP since the game wasn't balanced for it, but we'll see. Melee is definitely pretty viable as of Alpha 11, though it's still not easy to get a perfect build up and running since you have to collect several different parts before it's decent.

[zxc]

Damage overflow transfer would be a flight nerf and a combat build buff. It would make armour more important for flight (and I've already been leaning on armour heavily). It would also buff the 'superweapons' you can find in the Research branches.

Can it include secret hacks once you discover their respective lore entries?

I'm sure Kyzrati has thought of this and just hasn't shown that part because it would be spoilery.

it'll exclude the trojan and brute force hacks

Oh no it's much smarter than that . It adds Trojans to the pool automatically as NPCs/lore teach them to you (or if you use spoilers or whatever and type them in directly yourself at least once). Type in "Tr" and bam, all your applicable Trojans are listed.

No halfway decent implementations here!

I'm starting to come to terms with the fact that higher level machines are pretty much worse unless you have a stupid amount of hackware. It helps to make Access a lot harder, as you're pretty much only finding level 3 terminals.

[Kyzrati]

Damage overflow transfer would be a flight nerf and a combat build buff. It would make armour more important for flight (and I've already been leaning on armour heavily). It would also buff the 'superweapons' you can find in the Research branches.

Yeah, later on I was thinking that while it was introduced during a conversation talking about the increased effectiveness of Cogmind's attacks, the impact on the player's defenses could be quite significant as well! Definitely something to consider...

There could be other rules to balance it out, like the player is immune to overflow transfer, or maybe transfers less (player is already inherently stronger against EM and crits than other robots...).

Or another idea: Maybe overflow always targets armor if the robot has any (including you). It'll still be a pretty big drawback in terms of stripping your armor quicker, but then you'll probably also be taking them out faster, too, so for combat builds it balances out, while at least for flight builds the damage effect is a little more predictable.

[Decker]

I don't like the sound of damage overflow transfer. It would re-value propulsion armor since it's got the best integrity per slot after armor and much higher availability. It would also make non-melee combat more effective, so it doesn't really help to buff melee combat vs non-melee combat.

The main issue is that single weapons are underpowered because they won't generally hit the core (spears excepted). There already exists a mechanism to partially solve the problem: core analyzers. A buff and perhaps some restrictions would make melee and sniper-style combat more viable.

On another topic, I notice that the new utilities are devaluing weapon slots.

I propose to have a thread where people can pitch on about how combat (utilities) should be rebalanced.

[Kyzrati]

I'm not worried about revaluing propulsion-armor, since that's not meant to be armor in the first place and is something that just kinda happened.

I'd be more worried about any normal balance features it could throw out of whack.

It would make non-melee more effective for sure, but definitely also boost melee (especially utility-backed melee) because melee weapons are for the most part the highest-damaging weapons in the game. In principle I don't think maintaining equal viability between melee and non-melee is necessarily important here, but we'd have to see.

Either way, it's certain to have a pretty large impact on the gameplay, so I'd have to test this more thoroughly than the usual balance changes and yeah, if it creates more problems than it solves then it's not happening. It was just a sudden conversation we were having yesterday, and I like the premise so want to see where it might lead.

I propose to have a thread where people can pitch on about how combat (utilities) should be rebalanced.

That would probably be best after Alpha 12, because I've already made some balance changes there as a first stage. I'll put the thread into my post-release plans.