* preliminary elements needed to battle frame robotics; mostly from previous branch * introduction of FrameVehicleStateMessage and anticipated event system paths for BFR's; spawning amenities for BFR's are parsed and built from the zonemap files, but their coordinates are currently incorrect, and the resulting entity will not function atm * bfr's spawn correctly; default arm weapons will spawn correctly; bfr rearm terminal added but arm swap not working correctly; bfr shields charge if not full; proper separation of vehicle spawn pad types * arm weapon swapping in bfr's; swapped weapons switch, contextually, to either *_left or to *_right depending on the mounting; partial support for entities that do not have an OCDM packet form * crouching improves shield regeneration * some projectiles damage the bfr regardless of its shield * delay the final vehicle explosion; start of vehicle subsystems * handling for bfr shield ui updates; more of vehicle subsystems; corrections to TradeMessage packet; clarifications for FrameVehicleStateMessage package; report on flight status of bfr's * control agency support for vehicle subsystems for arm weapon fire control * vehicle capacitor, for what it's worth; shield and capacitor are influenced by recharge freeze and drain * initial packet and tests for AvatarAwardMessage; update the fields of FreindsResponse, DetailedCharacterData, and LoadoutType for FavoritesMessage; corrections to intiailization packets in SessionActor; players start as imprinted by default * support for GOAM and GAM integration into vehicle control agencies using a basic actor superclass; addition of vehicle subsystems; modifications to bfr control agency to allow for weapon handiness and subsystem control; fixed Fit mapping for vehicle override; made mountable seat transcoders independent * delayed explosions to accompany the delayed death for the bfr; bfr terminal window closes on successful purchase * the bfr armor siphon works * clarification for bfr inventory item manipulation; corrections to length of bfr transcoder for flight variants; everything else in in support of the various arm weapons that can be assigned to the bfr, including damage proxy support for causing/interacting with/cleaning up after radiation cloud projectiles * fixed the apc emp burst; fixed bfr arm weapon manipulation for activated subsystem; armor and ntu siphon support * battleframe loadouts available upon vehicle spawn (vs and tr only) * adb values for siphons; subsystem update message; some repairs * cargo vehicles are subject to radiation damage; damage for battleframes are different depending on shield evasion status; battleframe loadout deleting supported; bfr kill box; automatically wire bfr sheds, includeing the ones in sanctuary * proper bfr spawn angles; bfr vehicle timers; projectiles are no longer radiation clouds by default; better remote projectile cleanup; resolving incorrect weapon arm enabled states for bfrs * added tests for FrameVehicleState and GenericObjectActionAtPosition; pass around maximum sector for zone interactions * changed the triggers for the stamina regeneration timer * potential fix for issue related to finding arm weapon mounts * modifications to how vehicle subsystems are automated; jammer field updates; support and passing around custom block map ranges; does include activated dev tests for battleframe PAM, which will need to be stripped out later * commit while working on subsystems mk2 * subsystems fail when jammed; an unoccupied bfr does not have shields active; pulling a bfr of one variant should block the other variant too * fix distance check with radiation clouds; blocked bfr weaponry from anywhere but bfr arm mounts and cursor; ammunition depletion of aphelion laser; bfr shields deactivates when unoccupied * significant modifications to vehicle subsystem operations; disambiguation of weapon subsystems; debuffs to charge rate and use rate for the capacitor and shield of bfr; test for ComponentDamageMessage; somewhat proper jammering operations for bfr |
||
|---|---|---|
| .github/workflows | ||
| config | ||
| notes | ||
| project | ||
| scripts | ||
| server/src | ||
| src | ||
| tools | ||
| .codecov.yml | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .jvmopts | ||
| .scalafix.conf | ||
| .scalafmt.conf | ||
| build.sbt | ||
| docker-compose.yml | ||
| Dockerfile | ||
| LICENSE.md | ||
| README.md | ||
| renovate.json | ||
| THANKS.md | ||
PSForever Server

Welcome to the recreated login and world servers for PlanetSide 1. We are a community of players and developers who took it upon ourselves to preserve PlanetSide 1's unique gameplay and history forever.
The login and world servers (this repo runs both by default) are built to work with PlanetSide version 3.15.84.0. Anything older is not guaranteed to work. Currently, there are no binary releases of the server as the state is pre-alpha. You will need to have a development environment set up in order to get it running. If you just want to play, you don't need to set up a development environment. Join the public test server by following the PSForever Server Connection Guide, which has the instructions on downloading the game and using the PSForever launcher to start the game.
Server Requirements
- sbt (Scala build tool)
- Java Development Kit (JDK) 8.0
- PostgreSQL
Setting up a Build Environment
PSF-LoginServer is writen in Scala and built using sbt, which allows it to be built on any platform. sbt is the Scala version of Make, but is more powerful as build definitions are written in Scala. sbt is distributed as a Java JAR and the only dependency it has is a JDK. Follow the quick instructions on Scala's home page to get a working development environment and come back when you are done.
In order to compile scala, scalac is used behind the scenes. This is equivalent to Java's javac, but for the Scala
language. Scala runs on top of the Java Virtual Machine, meaning it generates .class and .jar files and uses the
java executable. Essentially, Scala is just a compiler that targets the JVM, which is its runtime. All of this runs in
the background and is packaged automatically by your IDE or sbt, which automatically downloads the right version of the
Scala compiler for you.
If you have Docker and docker-compose installed on your system, you can get a complete development environment up by
running docker-compose up in the source code directory. Otherwise, keep reading.
Using an IDE
Scala code can be fairly complex, and a good IDE helps you understand the code and what methods are available for certain types, especially as you are learning the language. IntelliJ IDEA has some of the most mature support for Scala of any IDE today. It has advanced type introspection and excellent code completion. It's recommended for those who are new to Scala in order to get familiar with the syntax.
Download the community edition of IDEA directly from IntelliJ's website. Then get the required Scala plugin for IDEA.
Next, you need to get a copy of the LoginServer code. It's recommended that you perform a git clone https://github.com/psforever/PSF-LoginServer.git using your favorite git tool. You can also work from a downloaded ZIP
of the source, but you cannot track/commit your changes.
Once you have the code downloaded, you will need to import the project into the IDE. Follow these instructions from
IntelliJ to import an sbt
project.
Once you have successfully imported the project (and setup the DB), create a new run
configuration with the server/run sbt task and click run to launch the server.
Using sbt and a Text Editor
If you are not a fan of big clunky IDEs (IDEA is definitely one of them), you can opt to use your favorite text editor (VSCode, Sublime, ViM, Notepad++, Atom, etc.) and use sbt to build the project. The only dependency you will need is sbt itself. Download sbt for your platform, install or extract, and open up a command line (cmd.exe, bash, CYGWIN, Git Bash) that has the Java Development Kit in its path.
At the command line run the following commands:
git clone https://github.com/psforever/PSF-LoginServer.git
cd PSF-LoginServer
sbt server/run
This will clone the repository and sbt will compile and run the login server (make sure you have set up the
DB). Note: sbt is quite slow at starting up (JVM/JIT warmup). It's recommended you have an
open sbt console (just run sbt without any arguments) in order to avoid this startup time. With a sbt console you can
run tests (and you should) using sbt test.
Setting up the Database
The Login and World servers require PostgreSQL for persistence.
- Windows - Official Downloads
- Linux - Debian or Ubuntu
- macOS - Application https://www.postgresql.org/download/ (or
brew install postgresql && brew net.psforever.services start postgresql)
The default database is named psforever and the credentials are psforever:psforever. To change these, create a
configuration file at config/psforever.conf. For configuration options and their defaults, see
application.conf. The database user will need ALL access to tables, sequences,
and functions. The permissions required can be summarized by the SQL below. Loading this in requires access to a
graphical tool such as pgAdmin (highly recommended) or a PostgreSQL terminal
(psql) for advanced users.
To get started using pgAdmin, run the binary. This will start the pgAdmin server and pop-up a tab in your web browser with the interface. Upon first run, enter your connection details that you created during the PostgreSQL installation. When connected, right click the "Databases" menu -> Create... -> Database: psforever -> Save. Next, right click on the newly created database (psforever) -> Query Tool... -> Copy and paste the commands below -> Hit the "Play/Run" button. The user should be created and made owner of the database.
CREATE USER psforever;
ALTER USER psforever WITH PASSWORD 'psforever';
ALTER DATABASE psforever OWNER TO psforever;
NOTE: applying default privileges after importing the schema will not apply them to existing objects. To fix this,
*you must drop all objects and try again or apply permissions manually using the Query Tool / psql.
The server will automatically apply the latest schema. Migrations can also be applied manually using the Flyway
CLI. Existing databases before the introduction of migrations must be
baselined using the flyway baseline command.
Becoming a GM
By default users are not granted GM access. To grant a created user GM access execute the following query:
UPDATE accounts SET gm=true WHERE id=your_id;
You can find your account id by viewing the accounts table.
Running the Server
To run a headless, non-interactive server, run
sbt server/run
PlanetSide can now connect to your server.
To run your custom server with an interactive scala> REPL, run
sbt server/console
To start the server and begin listening for connections, enter the following expression into the REPL:
Server.run
This process is identical to running the headless, non-interactive server: PlanetSide clients can connect, logging output will be printed to the screen, etc. The advantage is that you now have an interactive REPL that will evaluate any Scala expression you type into it.
The REPL supports various useful commands. For example, to see the type of an arbitrary expression foo, run :type foo. To print all members of a type, run :javap -p some-type. You can run :help to see a full list of commands.
Creating a Release
If you want to test the project without an IDE or deploy it to a server for run, you can use sbt-pack to create a release (included with the repository). First make sure you have the sbt tool on your command line (or create a new task in IntelliJ IDEA). Then get a copy of the source directory (either in ZIP or cloned form). Then do the below
cd PSF-LoginServer
sbt packArchiveZip # creates a single zip with resources
This will use the sbt-pack plugin to create a JAR file and some helper scripts to run the server. The output for this
will be in the PSF-LoginServer/target directory. Now you can copy the ZIP file to a server you want to run it on. You
will need the Java 8 runtime (JRE only) on the target to run this. In the ZIP file, there is a bin/ directory with
some helper scripts. Run the correct file for your platform (.BAT for Windows and shell script for Unix).
Generating Documentation
Using sbt, you can generate documentation all projects using sbt docs/unidoc.
Current documentation is available at https://psforever.github.io/PSF-LoginServer/net/psforever/index.html
Tools
decodePackets
The decodePackets program can be used to decode GameLogger .gcap packet captures. Requires
gcapy to run, unless the -p flag is used.
To build, run:
sbt decodePackets/pack
The output will be in tools/decode-packets/target/pack. The bin folder contains scripts to
launch the program. On Linux, you can use the Makefile to install the files to any path:
make install PREFIX=$HOME/.local
Now you can run the program like that:
psf-decode-packets -o ./output-directory foo.gcap bar.gcap
By default, decodePackets takes in .gcap files, but it can also take gcapy ascii files with the
-p option. Run psf-decode-packets --help to get usage info.
Contributing
Please fork the project and provide a pull request to contribute code. Coding guidelines and contribution checklists coming soon.
Get in touch
- Website: http://psforever.net
- Discord (chat with us): https://discord.gg/0nRe5TNbTYoUruA4
- Join the #code channel and ask any questions you have there
License
GNU GPLv3. See LICENSE.md for the full copy.



