Computer Hacking - too fast !?

[Enoch]

According to a post somewhere else, difficulty is based on spent AP

...which I find hard to accept, Taipei as a 2nd hub was a lot harder than Moscow as a second hub, mini-game wise.

 

It's actually "earned" AP that's taken into account and not "spent" AP. It's just that usually people spend every AP that they earn, so it's difficult to tell the difference. But if you hack the ini file to give yourself 10,000 AP when you level up (which is more than you can ever use - the most you can ever spend is a little under 500), then you'll instantly fail any hack job that you attempt.

Well, that explains why I'm finding the hacking much easier in my playthrough with a "Recruit" background.

[junior]

According to a post somewhere else, difficulty is based on spent AP

...which I find hard to accept, Taipei as a 2nd hub was a lot harder than Moscow as a second hub, mini-game wise.

 

It's actually "earned" AP that's taken into account and not "spent" AP. It's just that usually people spend every AP that they earn, so it's difficult to tell the difference. But if you hack the ini file to give yourself 10,000 AP when you level up (which is more than you can ever use - the most you can ever spend is a little under 500), then you'll instantly fail any hack job that you attempt.

Well, that explains why I'm finding the hacking much easier in my playthrough with a "Recruit" background.

 

And Hacking isn't the only thing affected by earned AP. When I increased my AP to 10,000, one of the things that I did was Darcy's "bet". I set the stun traps as usual, and the guards triggered them... but weren't instantly knocked out! Instead they were dazed - stuck standing in place semi-conscious during which I could walk up to them and disable them just as if I'd managed to sneak up behind them. After a few seconds, they returned back to normal and started pursuing me again.

[JamieKirby]

According to a post somewhere else, difficulty is based on spent AP

...which I find hard to accept, Taipei as a 2nd hub was a lot harder than Moscow as a second hub, mini-game wise.

 

It's actually "earned" AP that's taken into account and not "spent" AP. It's just that usually people spend every AP that they earn, so it's difficult to tell the difference. But if you hack the ini file to give yourself 10,000 AP when you level up (which is more than you can ever use - the most you can ever spend is a little under 500), then you'll instantly fail any hack job that you attempt.

Well, that explains why I'm finding the hacking much easier in my playthrough with a "Recruit" background.

 

Yep, but playing a Veteran is more easier, since you start with 120ap, which enables you to start with 5 stealth, which gives you the radar thing.

 

But overall, you can safely give yourself 320ap without the mini-games going crazy, since thats how much the Veteran gets, 120 at start and 200 from levelling.

[Ginx]

Then why the hell isn't there an upper limit to how many AP points can influence the difficulty? When the possibility of such things is left open in the game mechanics the programmers basically open the door to bugs. Lazy programming.

[Oner]

Because you can't reach gamebreaking levels without cheating?

[Tigranes]

Ain't the devs fault if you cheat and then the game breaks.

[Ginx]

It's not about cheating. It's about leaving the door open to game crippling bugs. Any programmer knows this; if you don't confine your scopes properly, you may end up with bugs that can be nearly impossible to trace. This case in particular isn't *that* bad, but as an indicator of the general level of strictness of coding it's not good. A bug in anything that influences AP count could potentially break the game in this way - that is not good coding!

 

Besides, this is getting off track - the point here is to figure out what config settings may influence the hacking timers. It's not just needed for this, since there may be future mods with different AP settings and they'll need to reign in unwanted effects like this one. I've gone through the game four times without any modifications, now I'm just messing around with the configs to figure out what does what and see how the game reacts.

Edited June 24, 2010 by Ginx

[alanschu]

It's about leaving the door open to game crippling bugs. Any programmer knows this; if you don't confine your scopes properly, you may end up with bugs that can be nearly impossible to trace. This case in particular isn't *that* bad, but as an indicator of the general level of strictness of coding it's not good. A bug in anything that influences AP count could potentially break the game in this way - that is not good coding!

 

With proper unit testing and regression, it's not bad coding at all. Adding in additional constraints on a system that is already supposed to work in a particular way is just as likely to introduce bugs that could be difficult to trace.

 

Besides, the bugs would not be difficult to trace as the metrics that exist to affect minigame difficulty appear to be game difficulty, AP points, sabotage skill, and equipment. Occasionally intel provides an additional metric. This is not a lot of variables that can affect this system.

 

Furthermore, constraints clearly do exist, as there are some hacking panels in the end game that are easier than ones in some of the open world hubs.

 

Are people getting bypasses with thousands of nodes in a fraction of a second because they have thousands of AP assigned to them?

[Ginx]

No, as I've said before the problem is with the hacking minigame only. The bypass and lockpick minigames *are* constrained to a maximum level of difficulty (13 nodes in bypass, six columns in lockpick, both of the games have a minimum timelimit that they don't go below). I still stand by what I said about bad coding, and I *did* add that it wasn't that bad in this case (limited number of influencing variables makes tracing relatively easy even in worst-case scenarios).

[Thorton_AP]

So the hacking game will get to a point where the time requirement for it is instantaneous?

[Baeus]

Maybe. But nobody's getting that far unless they've hacked their game, and if you've done that, well, you can't cry that things don't turn out well.

[Tigranes]

It's only if you give yourself a thousand AP or something stupid. Anyone who's ever played around with mods and file edits know that when you input outrageous values, you might get outrageous results. Would be a giant waste of time to 'fix'.

[Ginx]

I'm not looking for a fix, because that would involve constraining the timer variable and that requires a coder who has access to the source code. What I am looking for is second way to influence the timers, or the effect that AP has on the timer, within the confines of the config files. By pointing fingers and throwing around words like "hacker" and "cheater", you are being entirely unhelpful and I am starting to think that my time would be better spent figuring out the internals of other games for modding purposes.

 

Modding tends to involve "breaking" things and then figuring out creative ways to "unbreak" them. Mods don't get far if they have to stay within the dogmatic constraints of the original system. We're supposed to push the limits of what we can do, not constrain ourself by what we "should" (and shouldn't) do. Now stop being unhelpful. If you don't have anything to say, then don't say anything. Otherwise, at least try to help out here.

Edited June 29, 2010 by Ginx

[Tigranes]

What? This thread was discussing hacking in terms of just playing, not modding. Then you came along and gave multiple complaints and accusations about 'lazy coding'. Nowhere did you mention what your purpose was behind the fiddling - what do you expect?

 

Anyway, alright. I guess in the end we're saying the same thing - that we should expect things to break, and meanwhile try and find creative solutions. I'm certainly not saying leave things alone.

 

I haven't yet found any variables for the minigames themselves, though.

[Ginx]

No, this thread is rather specifically about the timers (absolute timer and reconfig timer) in the hacking minigame and whether or not it is "too fast". The timer speed (count) is influenced negatively by AP and positively by equipment mods (integrated circuits etc) and skills. I had noticed that during normal gameplay the timers sometimes were *really* low, approaching worst-case impossibility (worst case being the codes being diametrically opposite the starting corners of the target boxes), which I think is rather silly for such a minigame - it essentially reduces it to a luck-based activity. Anyway, I decided to test the sensitivity of the hacking minigame by messing around with the AP counts. That's when I found out that there wasn't any limitation to the impact of AP on these timers. The hacking minigame is the only minigame which doesn't have constrained difficulty variables. This, to me, suggests lazy coding - or it could be that some coder just forgot to define the limits, and it slipped through QA. Either way, it *is* a mistake - but what's done is done, and what I am trying to do is to figure out a way of compensating for it. I haven't made any complaints (except for the complaint about unhelpfulness), I have made observations and one accusation (which I stand by).

 

Anyway, if anyone finds any variables that influence the minigames - specifically the timers, but anything else would be helpful as well - please say so in here.