Proxy Accounts

Hey Everyone,

I wanted to throw an idea out there for the developers and script creators in the community. As we all know, Torn has strict (and necessary) rules against multi accounting. However, for those of us building tools, scripts, or apps for the community, this rule makes testing our projects incredibly difficult.

Currently, if I want to test how my tool interacts with specific scenarios, like faction management or company features, I am forced to rely on other people's time. I have to ask them to test it for me while I watch, which is a huge bottleneck.

I have mentioned this to a Velthir, and I wanted to bring it to the forums to see what the community and staff think.

I wrote the following with AI for convenience but still my idea and instructions + edits :

Create a system that identifies actual tool developers and allows them to generate a temporary, sandboxed "dummy" account linked directly to their main account.

This would act like a virtual machine or hypervisor specifically for testing, strictly adhering to Torn’s rules by ensuring the dummy account cannot interact with the real game economy or players.

My idea is that it will have :

• Zero Game Functionality: The account would be completely stripped of all competitive gameplay features. No attacking, no trading, no sending items/cash, and no API access to real-world players. Just a basic view and interface for testing.

• Simulated Scenarios: The ability to generate a fake faction or fake company, fake trades with themselves or something, fake money to request from themselves, all within this isolated environment. This allows devs to test API calls, scripts, and layouts without needing access to a real faction or company.

• Time-Based Auto-Deletion: The dummy account would be strictly temporary. For example, it could automatically delete itself after 24 or 48 hours unless the developer clicks a button to extend the testing window.

• Fully Linked & Transparent: The account would be hard-linked to the app developer's main account so staff always know exactly who owns it and what it is being used for.
  
  

Its pretty self explanatory and where the benefit of these suggestions come from and how it can benefit the whole community as a followup, but let me know what you think or any ideas, suggestions, changes, anything related to this suggestion as an extended functionality to those who actually need.

Cheers!

very reasonable and solid development mindset. +1 to op. 

Upping this, because it NEEDS visibility and some type of attention

I can see where you're coming from with this, but I can think of a few reasons why this likely won't be implemented.

First and foremost, from a gameplay perspective, this looks like a great way to kill the game. Plenty of games that include built-in cheats that allow you to trivialize the actual gameplay end up dying pretty hard, except for a small niche community that enjoy the game. Implementing a sandbox environment for Torn might not be enabling cheats, per se, but it provides the same experience. Once players can go into this sandbox simulation of Torn, suddenly, a lot of the gameplay of Torn becomes instant access. Why would I spend x number of years building up my battlestats and finances when I can just mess around with the sandbox and give myself quintillions of stats and dollars? Even if it's limited, you open up the floodgates for other things like perfect optimization. Suddenly, every company/faction is identical because AndyMan was given access to a Proxy account where he was able to determine the absolute best possible way to structure your company or faction to maximize profits.

The other thing I see preventing this from being implemented is just... why? Developers currently have the ability to develop their tools, scripts, websites, etc already. Why should Torn develop and implement a system that opens them up to having exploits discovered and tested far easier by players? I know that's not the intent of this suggestion, but that's what would end up happening.

#chedging

I don't think it would be worth the time it would take to develop this, nor the money Ched would have to spend paying developers to. It'd also be explicitly encouraging more script-heavy gameplay directly in the game itself, which while we all know using scripts/tools/etc is very helpful to playing competitively, I don't think is something they actively want.

Something else to keep in mind, is adding something this significant and involved parallel to the actual game, is every time there'd be a change to the actual game, how it affects the sandbox would need thoroughly tested as well, presuming you're not talking about this being an entirely separate test server. Because there would be bugs; it'd be inevitable. And it would be very difficult to find them all until changes go live, resulting in devs' workload being increased quite a bit (plus regular updates potentially taking longer due to additional testing being needed).

And of course there would be players stupid or malicious enough to look for ways to actively find and exploit these to the benefit of their actual account. Sure, they would probably—hopefully—be caught eventually, but it's still adding fairly large potential messes, and for what? Just to not have to get other players' help testing scripts? In a social game, nonetheless...

I will use this as a conductor to reply to you as well as @Apate, and although I completely agree and understand what both of you are saying, I do have to begin by saying, we have thousands of scripts and many hundreds of actual developers who are using Torn for what it offers in order to optimise their game to the maximum and that is not something that anyone can disagree with. We have small time scripts that can help visualise data better, and scripts that alter the gameplay entirely by optimising the most miniscule aspect of it, but in the end, because we have been given the ability to pull this data via the API's that we have been handed, and they are VERY extensive as they quite literally break down most functional behind the scenes data that we generally arent interested in seeing on the frontend.

Now, in terms of the actual negatives, and again, I completely agree with both of you that it could take away the fun of discovery and just playing the game for what it is by min maxing the FUCK out of every aspect and creating the perfect case scenario of gameplay, I do have to say that for the few developers such as the developers of TornTools for example, FFScouter, BSP, and I can keep going but just to name a few majors out there, they would need an environment to make sure that certain scenarios do not occur based on the tool that they are building, aspects such as data leakage, further improvement and development, potential security flaws where through these scripts you can access other aspects that you should, or tap into it. There is alot, hence why I also mentioned the limitations behind this. 

The security behind this would limit it to verified and known users, which I believe is important as all those scripts mentioned above are there to serve the community in a beneficial way, and I see no maliciousness there, neither would I see it if they tried to strengthen their tools. And I believe the same for myself and tool I am currently creating. I would simply love to see directly what I am building in a way in which "Hmm maybe they should see this" or "maybe I can improve this" aspect. 

But again, I also agree with what you guys are saying