Skip to content

Make vehicles upgradable (and refactor part exchanger system, oops) - #4798

Open
arimah wants to merge 2 commits into
new-frontiers-14:masterfrom
arimah:vehicle-upgrades-and-rped-rewrite
Open

Make vehicles upgradable (and refactor part exchanger system, oops)#4798
arimah wants to merge 2 commits into
new-frontiers-14:masterfrom
arimah:vehicle-upgrades-and-rped-rewrite

Conversation

@arimah

@arimah arimah commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

About the PR

This PR does two things I probably shouldn't have mixed but couldn't really separate.

Firstly, this PR reworks PartExchangerSystem to be less of a horrible copy-pasted mess. Don't get me wrong, it's still a mess, but less so.

Secondly, this PR enables vehicles to be upgraded, by adding a new component and tweaking the way the RPED interacts with it. Only hoverbikes and the hoverchair are made upgradable with this PR, but the new component also makes it trivial to make more vehicles upgradable in the future, and paves the way for allowing other aspects of a vehicle to be upgraded. (E.g. maybe we want ATV lights to be upgraded with capacitors in the future.)

Why / Balance

I love hoverbikes! They're so much fun, and travelling through space on a hoverbike with no ship to your name is awesome. However, it's painfully slow at times, especially now that the sector is really spread out and big. By upgrading your hoverbike with 8 super capacitors, you can reach speeds of 13.6 m/s – considerably faster than the standard 8, still much slower than a ship. Get lucky enough to find bluespace caps and you can get all the way up to 16 m/s, twice as fast as usual.

RPED is required to upgrade hoverbikes. It is not possible to disassemble the bike and tear out the components yourself. You have to right-click and select the 'Upgrade' verb. Left-click and Alt+click both interact with the storage system, oops. (For the YarRPED, the text changes to 'Downgrade'.)

I settled on the values as follows:

  • I don't want hoverbikes to become obscenely fast. Not only is it hard to control, it also gives them WAY too much utility in combat situations. I could imagine people using them to clear vgroids very fast, but this is balanced largely by the inability to use a two-handed weapon on a hoverbike, and gathering loot is much harder too.
  • Even a maxed-out hoverbike should be slower than a ship. They are much smaller and weaker, of course. And you should always be able to catch up to a hoverbiker with your ship.
  • 8 capacitors because it visually has four thrusters, and I figured two capacitors per thruster would make sense. Arbitrary roundish number of capacitors that takes a little bit of effort to find if you don't have science help.

For the hoverchair, I just kinda picked values that seemed to make sense. Even with full bluespace capacitors, it's (slightly) slower than speed boots, but of course does not suffer slowdown from your hardsuit and weapon. It's probably fine. This vehicle is basically never actually used.

Technical details

Re PartExchangerSystem: It was extremely confusing how some logic happened in one method, some other logic happened in another method, and nothing was named in a way that aided comprehension. InContainer? Which container – the RPED or the machine?! I've tried to rename things in a way that's hopefully sensible and straightforward, as well as use Entity<...> to pair IDs with components where appropriate. I'm not 100% fond of the callback hooks I needed for machine frames, but it's either that or duplicate an uncomfortable amount of code. I chose callbacks.

The vehicle upgrade stuff should ideally be pretty self-explanatory. As it's currently written, VehicleUpgradeComponent does not actually depend on VehicleComponent; you could slap it on any old entity to allow its speed to be upgraded. But the naming is meant to suggest that it be used for vehicles, and in future we might add more UpgradableVehicleProperty members for vehicle-specific things.

I also moved the client-side VehicleSystem to _NF/Vehicle/EntitySystems for better symmetry with Shared and Server.

How to test

  1. Spawn yourself a hoverbike, any hoverbike.
  2. Spawn an RPED, put some fancy capacitors in it.
  3. Right-click the hoverbike and pick 'Upgrade'. Wait for the RPED to do its thing.
  4. Inspect the hoverbike's speed and note that it's been upgraded and improved and stuff. Now take it for a test drive and enjoy LUDICROUS SPEED!
  5. Put some basic capacitors in a YarRPED and note that you can also 'Downgrade' the hoverbike. Amazing! Try to get its speed back to normal.
  6. Spawn a hoverchair and repeat the process. Since the hoverchair has no storage, you can also just click on it to upgrade it.
  7. Also, try to upgrade some machines with an RPED, to make sure I haven't completely botched that part of the game.
  8. And try to finish constructing some machine frames, too. Test with machine frames that have none, some and all of their machine parts.

Media

https://streamable.com/6w895m

image image image image

Requirements

Breaking changes

Changelog
🆑

  • add: Hoverbikes can now have their speed upgraded with an RPED. Put some capacitors in it, right-click and upgrade!
  • add: Hoverchairs can now have their speed upgraded with an RPED. Put some capacitors in it, click and upgrade!

@arimah

arimah commented Aug 14, 2026

Copy link
Copy Markdown
Contributor Author

Okay, I forgot the mail carrier, NFSD, syndicate and pirate hoverbikes had their own completely separate parents BECAUSE WHY NOT. I will fix.

@CrimsonSilverRez

Copy link
Copy Markdown

For what it's worth, I approve of this! Space is big and Void-Gliders should still be viable.
Maybe down the road this can lead to fully tinker-able and customizable hoverbikes, and let gear-heads have fun decking out their space-hogs.
Like cup-holders!
Or integrated Mass Scanners.
Or the ability to make them a grapple-target so someone can jet-ski behind you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants