Follow

Client Automation

Automation on top of the existing game client is currently permitted.

Adding files to the directory hierarchy of the game is currently permitted. Modifying any existing files is not permitted.

Modifying the game client in any way is not permitted, this includes memory modification, code injection, client file modification, etc, and is considered a 'custom client.'

Viewing game client memory is currently permitted.

---

I highly recommend not running other player's scripts or mods on your own machine. Unless you can fully understand the scope of the code that you are running, this is very unsafe.

If you can safely read and run others' code, then you can probably write it yourself, which is much safer.

Was this article helpful?
2 out of 2 found this helpful
Have more questions? Submit a request

18 Comments

  • 1
    Avatar
    Siim Põder

    IDK if you'd care to clarify or leave this vague to leave more room for judgement, but I'm currently automating my client and am a bit worried about crossing any lines.

    Is it OK to:

    • Send keystrokes to the hackmud client from external scripts?
    • Get output from hackmud client from external scripts?
    • Screencap the hackmud window?
    • Automate any minigames (in particular, kernel.hardline)?
    • Attach a debugger to hackmud client to glean state straight out of the client memory?
    • Run automation to drive the hackmud 24/7 (for example, scraping NPC accounts)
    • All of the above?
    Edited by Siim Põder
  • 0
    Avatar
    seanmakesgames

    Will be clarifying debugger attachment part, as modification of the client is not allowed.

    driving hackmud 24/7 is permitted, as long as it is in the bounds of 'player speeds' of input

  • 0
    Avatar
    Keith Hanson

    Where does modifying your .macros file stand within these rules?

    IE: a ruby script (running on my laptop) picks up the changes from my shell.txt that has /macro = output, and moves them into macros for copy/pasteless macro'ing of the output of a program (generally used with scripts that need locs for mining/pvp).

    Thoughts?

    Edited by Keith Hanson
  • 0
    Avatar
    dtr

    Can you clarify what 'Adding files to the directory hierarchy of the game is currently permitted. Modifying any existing files is not permitted.' means? In particular, is 'the directory hierarchy of the game' the app files themselves, or where the save files are? (i.e. the .macros files and our scripts). That is ambiguous and could be read to mean that editing our own scripts is illegal, as that is modifying a file in the directory hierarchy of the game's save files.

  • 0
    Avatar
    dtr

    One other clarification I would like here.

     

    I have heard of at least one credible report of a sustained, hours-long (i.e. 20 hours and counting) attack on a specific user, using out-of-game automation to send a near constant stream of transactions to the victim. (In this case, since hitting a glock requires a second user to feed, I am assuming it is actually two coordinated out of game bots working together against a single target)

     

    If this is achieved without exceeding any client limitations using out of game automation, are such attacks (which effectively if not technically deny the victim the ability to play the game) allowable? Or has that strayed into the realm of personal abuse (forbidden by the login screen), regardless of whether the underlying automation techniques used are otherwise acceptable?

     

    If it is not acceptable, where is the line between a legitimate PVP attack (glocks force any legitimate coordinated attack to flood the target with transactions, and if we are not allowed to hack other users, what is the point of all these locks! And a legitimate manual attack by underprepared attackers against a prepared defender could take a few hours) and a mild denial of service? 

     

    ( In addition to transactions, I have also heard concerns raised by several players about the possibility of using a constant stream of chats to target specific users. Even while obeying all the rate limits, a sufficient volume can be generated to render the game nearly unplayable, especially if multiple users turn their bots against the same victim )

     

    TL/DR: Even if the automation used is 100% within the rules, can the result of an directed automated attack still fall afoul of other rules, or is anything done with allowable automation acceptable?

  • 0
    Avatar
    Dave Coleman

    I'm of mixed on the automation discussion. It seems the game is based around perpetual conflict, and is available 24/7. It also encourages the players to provide the majority of the in-game services. There are a lot of services needed to flesh out the game world, and a limited player base currently. This makes 'manned defenses' infeasible for more than a small number of services, since humans sleep, and there isn't enough awake time to go around even with scheduled watches. However, automated defenses feel a little unbalanced as well, and encourage an arms race with automated attacks. I agree that there is a fine line between in-game competition and griefing/abuse, especially when automated tools extract maximum cost from the victim at minimal cost to the attacker.

    I don't have a proposed solution. There was discussion of a Mute functionality, so you can ignore incoming notification from a specific user. That seems a useful first step.

  • 0
    Avatar
    dtr

    I agree, Dave. My personal opinion is that automation should be kept out of PVP and NPC harvesting. For PVP, that includes offense and defense. For NPC harvesting, I mean, no clearcutting the entire crop with auto hot key. 

    That would leave automation for value-added services, like payouts for games and banks, or exploration (i.e. joining all the channels and looking at who is there), or data crunching (brute forcing high value locs, analyzing collected data, etc). 

    But that is STILL a fine line, because banks can be used for PVP (under attack? Stash your GC), and if we want to say 'no' to PVP, where does that line go?

    Basically, it is a hard problem to solve. Outright banning automation at all is probably best (I say this as someone who is planning to open a bank that will rely on automation to function), but also impossible to define. Is a gaming keyboard with macros automation if it presses 2 keys every key press? What if it presses 20, or 20,000? 

    Ultimately, we need clarification, or else soon various automated platforms will likely consume all available workers, and out-compete people just trying to play the game. 

    Perhaps something like a time limit? Like, any commands executed when a human isn't at the keyboard must be at least 5 minutes apart. (or 1 minute, or 10, or an hour, whatever). Impossible to enforce, but so far it seems like people are [fairly] reasonable on discord, so having a concrete line in the sand to point them at might help. 

  • 0
    Avatar
    Dave Coleman

    It feels like automation should be explicitly forbidden except through an automation-specific set of commands, that have Sean's desired limitations built into them. Any automation detected outside of those commands would be grounds for disciplinary actions.

    Except this is an enormous amount of work to prepare, and Sean wont be able to anticipate every creative automation usage.  I also have doubts that we can detect every source of automation and prevent it.  If someone is attacking me, there is very little visible difference between me calling a script by hand every 10 seconds, and AHK calling it for me.

    The negative outcomes of automation are what we're really trying to prevent, so maybe we should brainstorm how to define and identify those outcomes?  I dunno; still trying to get my head around the boundaries of this problem.

     

    Edited by Dave Coleman
  • 0
    Avatar
    dtr

    Really what we need are the (planned) in-game bots and then a ban on all out of game automation. But again, detection. A viable by-hand attack on someone is nearly indistinguishable from automation. Timing statistics could be gathered, but then automation can just fuzz timings....

  • 0
    Avatar
    Dave Coleman

    Yup, detection will be a huge problem.  As a hardware guy, I could bypass most detection schemes in a couple hours, and I'm not nearly as skilled as many of the players. Automation is going to be a permanent, perpetual problem with Hackmud, so mitigation of abuse and policies focusing on results, not methods, may be the best approach.

    Edited by Dave Coleman
  • 0
    Avatar
    snowgirl

    I think the key point here is that people shouldn't be trying to rules lawyer. If you have to ask yourself if doing something will make the game unbalanced or unfair, then the answer is in all likelihood “yes”.

    Basically, the Wheaton's Law: don't be a dick.

    If one is using automation then one need realize that if it's unbalancing the game or making it unfair, then well, one might get banned for it.

    Ugh, the glock sending the defender lots of money sounds horrifically inconvenient in many cases, and yes, is likely to just spam one with transfers… but I think sometimes, it can be clear if someone is doing it to harass someone, rather than making a genuine attempt to PVP.

    Like, if a person keeps hitting the glock with 1GC in your balance, then it's pretty clear that they're not even trying to break the lock. And perhaps the lock itself could recognize this sort of thing, and lock someone out entirely if one just spams it like that…

    Uh, I'm rambling which I tend to do, but one last thing, it should be clear that one shouldn't be DoSing someone or make the game unplayable for them. Unintentionally doing something like that? Eh… oops. But we're all hear to play the game, don't make it unplayable for anyone else.

  • 0
    Avatar
    Dave Coleman

    I'm honestly not keen on creating a game of botwars, but some of the limitations on game functions highly encourage automation to a certain degree. I will happily draw the line at Don't Be A Dick, but there's still a lot of gray area between there and fully manual all the time.  I like your ideas for detecting obvious intentional griefing.  edit:  I have trouble trusting that other users won't exploit areas near the boundary of the rules, so it makes it a difficult balance.

    Edited by Dave Coleman
  • 0
    Avatar
    dtr

    Is automation unfair if it is within the rules, though? We need the rules changed before we can say it is unfair. Otherwise it is just people not taking advantage of opportunities. Unbalanced? Sure, but plenty of the core mechanics are unbalanced too (shadow NPCs, for ex).

     

    basically: don't be a dick only works if people give a damn about it. And most people whoa re inclined to be a dick won't. So we need a hard and fast rule. This far, no further. Toe the line, fine. A millimeter over it, expect a warning followed by a ban. 

     

    We have such a line now, but it is (IMHO) far too permissive. (again, said as someone who is currently using such automation to add value to the game )

  • 0
    Avatar
    Alan

    I am in agreement with dtr here.  Without a hard fast rule, just saying 'Don't be a dick' becomes the hard fast rule and it's a rule with a very open interpretation that will inevitably upset people.

  • 0
    Avatar
    Dave Coleman

    I have to agree that we need a hard fast rule, but we have one now. Does the rule need to change, or do we need better tools to prevent abuse, or something else?

  • 0
    Avatar
    Alan

    Wait.  No.  This is what I actually want to say on the matter.  I agree with dtr in the sense that if we are going to put any sort of ban on automation, then yes I agree.

    However, what I fundamentally disagree with is putting any sort of ban on automation.  Let us not fight this war against automation.  Let us embrace it.

    Instead, what I propose, is that the correct course of action is to balance the game.  I believe there would be far more interesting discussions to be had were we to instead brainstorm ideas that counter automation.  I think a few creative balance changes would be all the we need.  Not some convoluted rule system.

    Here's the bottom line.  Any sort of rule against automation is going to be nigh unenforceable.  Let's say people were able to come to an agreement on what kind of automation is or isn't allowed, who's going to enforce it?  Sean?  How?  The problem is that there is too much crossover between how much a human can act like a robot and how much a robot can act like a human.  It's just not possible.

    EDIT: derp

    Edited by Alan
  • 0
    Avatar
    Chance

    DDoS client flood should probably be expressly disallowed.

    With chats, just letting them turn chats off entirely as an option to defend against such a thing seems reasonable.

    With transactions... well, they can't keep sending you money forever and if they can, maybe it isn't such a problem? Although, I do distinctly dislike the idea of nt+glock combos being automated and unbreakable. They're neat, but the way they work now seems a little bit OP.

    Some of that stuff should probably have rate limits.

    Automated lock-busting is tits.

    Automated services are tits.

    The automated NPC harvesting is not bad, but it should really have its limits. I think the trick is just that the rewards increase proportionally with the effort to automate. Risk will tend to scale with reward anyway.

    Off the top of my head, an interesting approach might be rationing or even commoditizing the use of scriptors.

    Another might be some sort of rolling-time-window of diminishing returns for hacks on the same tier of NPC where you get less and less until the window resets.

    I don't think automated clear-cutting will be a problem as it stands now.

    Maybe enough people get into it and do it that T1's exhaust regularly. That creates a problem for newer folk, but there are lock sims they can use, and if not already, there could be corp sims as well, or a static T1 corp with a few locs that never die, but pay diminishing returns all day.

    If people want to try to clear-cut stuff < HIGHSEC, I have a feeling that will sort of work itself out.

    EDIT:

    /southparkbanker

    Aaaannnnd it's gone. Well, I didn't check around and whatnot but some claims last night suggested the T2's were clear-cut and I had more time to think.

    I'd welcome less safety in general and more things that present danger/threat to automation.

     

    Edited by Chance
  • 0
    Avatar
    Chance

    I do really like the idea of the diminishing returns by NPC tier on a rolling window though.

    Maybe even with ways to reset that window that all involve "manual" hacking.

    24 hours of consideration also makes me think that maybe GC should not move so freely as it does.

    Maybe how you gain GC determines some time period that particular GC can't be moved again. It must stay wherever it most recently landed for at least some period before it can be moved. This is not entirely different from the way banks really work and kind of sort of for similar reasons. Like your available balance vs your current balance.

     

Please sign in to leave a comment.