-
Notifications
You must be signed in to change notification settings - Fork 302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NETSCRIPT: Add functionality and support to fully allow Players to use IP addresses in place of hostnames #1990
base: dev
Are you sure you want to change the base?
Conversation
This is a great addition, kuddos for the attention to documentation |
…gument + print IP Address on connect if an IP address was the argument
…versByIP' methods to the NS namespace.
… ensure consistent use of 'host', 'hostname', and 'ip'. Added guards where hostnames are required to prevent the use of IPs
3575ea4
to
e4f1b3b
Compare
Rebased onto version 2.8.0 final release. |
…hostname or IP address) gets returned from applicable methods
Summary of cumulative changesRemoved from PR
New Terminal Command
New API Methods
Changed API Signatures
New NetscriptHelper Functions
Other Changes
Considerations
New Demo Scripthttps://gist.github.com/NagaOuroboros/552ce05724831e5368592f89ba8e6d1a |
Motivation
While looking through the source code, I noticed that the game widely has the ability to accept IPs where it accepts hostnames. This intrigued me since IPs are randomly assigned at reset/install, making them dynamic as opposed to the static hostnames.
I began considering the idea of using primarily IPs instead of Hostnames as a challenge/aesthetic option, but quickly hit a few obstacles to doing so:
connect
terminal/Singularity command fails to properly use IP addresseshostname
terminal commandns.getServer("hostname").ip
ns.scan()
, return only hostnames, even though the terminal equivalent displays both hostname and IPScope
This PR's goal is to remedy these obstacles so that IPs can be consistently accessed and used across the game at the Player's option. In pursuit of this, I took the following approach:
In most cases, a simple documentation change and edit to variable names to indicate an IP address is a viable input was all that was needed.
In cases where a new method made the most sense, I implemented them with functional parity to their hostname counterparts where applicable.
Where it made no sense to pass an IP address instead of a hostname, I instead shored up the string checking to ensure an IP cannot be successfully passed.
In all cases, I ensured proper and consistent use between 'host', 'hostname', and 'ip' in both documentation and player-facing code.
Splitting this task into multiple PRs would not make sense, in my opinion, as the individual changes do not stand on their own and are more properly rolled into a single feature. This PR should be feature positive and make no regressions or major breaking changes.
New Terminal Command
ipaddr
- Prints the current server's IP to the terminalNew API Methods
ns.getIP()
- Returns the IP address of the script's current serverns.scanByIP(host)
- Functionally identical tons.scan
, but returns IP addressesns.getPurchasedServersByIP()
- Functionally identical tons.getPurchasedServers
, but returns IP addressesns.dnsLookup(host)
- Given a hostname, returns its IP address; or given an IP address, returns its hostnameMajor Changes
connect
- Both the terminal command andns.singularity.connect(host)
now allow IP addresses as argumentsns.purchaseServer(hostname, ram)
- Will not accept an IP-formatted string as ahostname
ns.renamePurchasedServer(hostname, newName)
- Will not accept IP-formatted strings in either argumentConsiderations
An argument could be made that dealing with the dynamic nature of the game's random IPs could merit a cheaper RAM cost than the equivalent hostname methods as a trade-off, however this PR defaults to parity in RAM cost.
The new
ns.dnsLookup
method is given a RAM cost of 0. Given that you must already have an IP or Hostname to use this method, the bidirectional conversion should be costless, as there's no functional difference in gameplay.An argument could be made that
ns.dnsLookup
should be split intons.dnsLookup
andns.dnsReverseLookup
, which is more true-to-life. However, given the simplicity of the actual operation being performed, I found making one method instead of two was the more ergonomic choice.The name for the new terminal command
ipaddr
is not necessarily final. Suggestions for an alternative, more 'CLI-flavored' name are welcome, and I'll happily change the name to conform whatever is more desired.Demo Script for new NS functionality
https://gist.github.com/NagaOuroboros/6c27c61f2f478f8cb22f71c1ba894d05