Ship Equipment Overhaul - EquipSet v2 #5734
Conversation
|
Hey @Web-eWorks , this looks like a big step in the right direction. Your ShipBuilder API is similar to what I started doing on my pirates branch but I think I called it ShipOutfitter. However, with the equipment changes it looks more straightforward. As such I've been thinking in that area for a while so I'm very happy to pick up the TODO's around using this throughout the missions and then also extending it, if that works for you. If you're happy with that, can I send PR's to your working branch? |
That would be absolutely excellent, thank you! I'll double-check the settings on my fork but you should be able to open PRs there. I'll try to squash together the fixup commits sometime tonight and see if I can rebase this on the current release. EDIT: you should be able to open PRs to my fork from this page, just select the correct branch on your end. Web-eWorks/pioneer@equip-v2...JonBooth78:pioneer:master |
|
Rebased onto 2024-02-03, will rebase onto current master soon:tm: once we push the last hotfix for the year out. |
- Allows forward-compatibility with mods and other values in ShipDef without requiring C++ changes to load and store the new values
- All equipment items defined in Lua are treated as prototypes storing shared data. - When adding an equipment item to a ship, create a new instance of it and add the instance to the EquipSet. - This allows tracking per-instance details such as durability or storing specific equipment item instances at a station.
- Promote old equipment prototypes to use top-level mass/volume properties
- Split existing items into various internal slots by size - Add select new variants of existing items for testing slot sizes
- Ship.cpp no longer holds a reference to an EquipSet, uses LuaComponent system instead
- Unify background drawing across callsites - More efficient and resilient draw cursor manipulation - Better handling of whole-card vs detail tooltips - Reserve space for "highlight bar" drawn in left margin
It's the UI's responsibility to render item stat comparisons; the stats module should just be concerned with formatting raw values into something that can be consumed and compared
- Function prototypes for installing/removing EquipType items - Separate cabins into their own EquipType subclass - Use the LuaSerializer persist functionality instead of serializing equipment directly
- Was originally "removed" in 2013, but some references crept back in. - Prefer using properties defined directly on a Ship object instead
- Amend documentation for C++ set ship properties - Temporary re-definition of freeCapacity before deprecation
- ShipType capacity is now a floating-point number defining equipment volume - Added a new cargo value as a migration path for slots.cargo - Add Lua type definition file for LuaShipDef
- Replace the shared capacity metric with separate cargo and equipment volumes. - If needed later, cargo and equipment space could potentially be "converted" into the other.
- The counterpart to a ShipDef, a ShipConfig is concerned with expressing the slot arrangement and equipment capacity of a specific version of a ship's hull - The default configuration for a ship is loaded from the ship.json file, but additional ship configurations can be supported with minimal effort - Each ShipConfig is comprised of a set of slots with unique identifiers - The default set of slots can be modified or overridden entirely from within the ship.json file by specifying key-value pairs in the equipment_slots object
- Unlike the previous iteration, EquipSet v2 is concerned with modelling individual equipment items installed in unique slots - It also supports "loose" items which are installed somewhere in the ship's equipment volume without requiring a slot - Equipment volume is now completely separated from cargo volume and equipment cannot be installed in cargo space or vice versa. - Support for trading off equipment volume for cargo volume may be added later if deemed a good idea from a gameplay balance perspective.
- Moonscript - although quite expressive - does not have enough tooling support to be a viable option for writing Pioneer code - Remove old ship spawner UIs - Give RPG debug tab the money icon, change commodity tab to cargo icon
- Contains utilities to spawn ships according to predefined templates, inspect existing ships, spawn missiles, and perform debug travel - Allows in-depth investigation of all ship hull configs in the game - Enhanced ship spawning controls allowing ships to be outfitted according to a number of different templates - Inspect equipment of spawned ships with greater detail than target scanner
Be compatible with new EquipSet v2 PR #5734
- These slots are not common to all ships and are better to set up with each individual hull
- Set up S1-S5 shield generators - Stat hyperdrives for S1-S5 (and S6/S7 though they won't be used on flyable ships) - Separate scoops by cargo/fuel/generic slots - Interim missile definitions until missiles are reworked - Add missile rails/racks for external missile carriage - Add internal missile bay equipment for Bowfin
- Bowfin, Coronatrix, Lunar Shuttle, Mola Mola, Pumpkinseed - Most ships increased in hull mass overall - Structure and Armor mass are enumerated separately for future work - Many ships expect an internal jump fuel tank integral to the hyperdrive and do not have extra cargo space for jump fuel
|
This branch is now officially testable! All S1 ships (Bowfin, Coronatrix, Lunar Shuttle, Mola Mola, Pumpkinseed) have received an initial slot layout pass and have functional cargo and equipment capacity numbers. This should provide enough ship variety for most combat and non-combat missions. Most of the mentioned ships above have changed in hull mass and cargo volume; consequentially, deltaV will have changed for most ships with common equipment loadouts. Feedback on the changes to ship performance would be quite nice if anyone feels so inclined! Note that selecting any start other than Mars is non-functional and may error, and you'll need to use the debug tools to cheat money and switch ships rather than using the new game window. You can find screenshots of the new ship debug tool here if you're confused as to how it works. |
| for k, v in pairs(b) do | ||
| if predicate then k, v = predicate(k, v) end | ||
| a[k] = v | ||
| if predicate then |
There was a problem hiding this comment.
Sorry, change the name please. Predicate returns bool. Maybe "transform" will do?
|
Equipment Market : Overall fantastic improvement over the current system. Nicely done!
|
|
Thank you for the testing and feedback! I very much appreciate people willing to try WIP stuff and provide feedback before it's been merged, especially when the diff and changeset is as daunting as this one! I'm writing answers in long-form here as much for future reference as I am to respond to your feedback, so please don't feel like I'm dog-piling on a specific point or providing all of the reasons why it "wouldn't work". 😄
This is intentional. This allows the user to quickly fill multiple slots with similar equipment, e.g. missile rack slots where you want to buy 5x of the same Guided Missile equipment. Requiring the user to manually select an equipment item and click Buy/Sell takes significantly longer. I might be able to instead persist the selected item so that when the selection automatically advances to the next slot the purchased item is selected and the user can instead click Buy multiple times to fill the slot. However I think that would be even more confusing than the user explicitly double-clicking, as there's no longer the pause required to start a new "double click" action.
Ah, but you see... they're not essential yet. 🙃 Specifically, in the The primary focus of this branch and PR (given the monstrous amount of code involved) is to replace the underlying equipment system and migrate everything that directly interacts with its API. Game mechanics are slated for rework/improvement in an additional set of PRs, known as "Stage 2". Part of this work will include (see the TODO at the top of the post) the ability to require equipment slots be non-empty, and determining which items should be installed by default in a slot. TL;DR: not intended in the final version, acceptable deficiency in this specific PR.
Eeeeh... technically no. The old equipment system I believe had no compunctions about allowing you to buy multiple copies of CLS, and it's something we could lean into by saying that a single CLS unit only provides life support sufficient for N units of cargo. Autopilots definitely shouldn't let you double-up, however I've deferred support for more rigorous checks and restrictions on installation (and communicating those restrictions) until we have a better picture of the constraints we need to support. That is going to be a Stage 2 thing; as more systems are changed and redesigned to make better use of the equipment model, we'll have a better picture of the constraints arising from those systems. There is also the lingering question of whether we want to support equipment redundancy, or if redundant systems are merely an internal "lore" property of an item which is represented as the integrity threshold at which an item starts failing or malfunctioning.
Short answer: you can't physically install a passenger cabin on your specific ship! Passenger cabins are installed in a "cabin" equipment slot. This is one of the slot types that are intended to be non-empty, supporting either additional crew quarters, passenger cabins, perhaps a "smuggler's hold", or just bare metal additional living space (with the lowest mass cost of all the options). They also don't support directly installing equipment into their space, as "cabin" slots are directly connected to the living spaces of a ship and aren't counted in the game's abstraction of "equipment capacity". (In technical terms, cabin equipment items consume 0 volume.) The Coronatrix is too small to both have a cargo bay, space for a single crew member (you!), and passenger cabins. All of the small ships have received a physical layout pass (you can see an example here and here of larger ships which will be added with the next batch of shipdef updates) and have been diversified based on role. To equip passenger cabins in the current state of the branch, you'll need to switch to a Pumpkinseed or a Lunar Shuttle. This is something I'd like to address in the future with a "Hull Variant" system, introducing various aftermarket "rebuild models" of ships, e.g a VIP Transport modification of the base Coronatrix hull which replaces the cargo hold with two passenger cabins. For the future: this should be communicated to the player in a more obvious way that they may have to seek specific ship models to be able to carry large quantities of passengers. There's your wall of text for the evening! Thank you again for taking the time to play through the branch - feedback on this PR (especially finding "papercuts") is invaluable. |
Personal preference. Perhaps make it a "Game Option"? As for myself, I would definitely prefer to spend more time clicking than potentially losing a large amount of money and/or losing a bunch of progress if needing to revert to a previous save. Alternatively: How about adding a "Quantity" similar for commodities when purchasing consumable items such as missiles?
I changed my ship-type to one of the large passenger ships specifically to try this (I think it was the
I just tried again with the EDIT: Those linked pics are nifty - is there a list of these as, presumably, this was done for most/all of the ships? Google has failed to find anything and I find Imgur impossible to use. |
Sounds good! I'd ideally like to implement an "undo purchase" button, but that gets into a thorny tangle of needing install/remove equipment options to be fully invertible and if it is as easy to install an item by mistake as you say we'd likely need to keep a history of recent transactions and support reverting more than one purchase.
This was briefly tried. I found two (well, three) problems with it:
The equipment screen operates on the abstraction level of individual slots. Trying to retrofit in adjacency support for switching to the next empty slot was difficult enough; adding support for the player being able to buy multiple missiles at once across multiple slots - which have to be filtered and constrained by type and size - is something I deemed well out of scope of the initial implementation effort. I'd certainly welcome alternate (concrete and detailed) proposals for dealing with the problems laid out above, but so far solving them has not worked well.
The Blender source files for those component layouts are in the pioneer_looks repository under We tend to use Imgur as a "dumb image host" and pretend that the site has no front-end at all outside of the upload button 😄 |
|
Do you have anything specific you want people to test here? Being newly-back to Pioneer I'm not sure what, if anything, I should be paying attention to. So far things seem to work just playing the game, within the limits of these changes (eg, empty engine slots and no equipment for them, or ships not yet updated for the new equipment setup). Alternatively, is there something people can help with to achieve the full implementation (ie, the next stages)? Finally, are there plans to add things like budget passenger cabins which could be fitted into cargo holds for ships like Couriers? With these changes it seems ships are much more restricted with the kind of extra equipment that can be fitted to them than previously, although that might be by design. |
I used to remember what I wanted people to test, then my brain overwrote that information while reviewing other pull requests. 😅 At current and near future (i.e. when we push the rest of the ship layouts) the main thing I want testers to do is to hunt crashes and/or non-functional missions which interact with the new equipment - i.e. purchasing used equipment from the BBS, passenger delivery missions, cargo scoop missions, etc. Initial feedback on "game feel" with the new equipment system is useful, but limited in scope as many of the planned systems and changes are not yet implemented.
Absolutely. There is a lot of work that needs to be done regarding that. One of the bigger things that "anyone" can do during Stage 2 is to write English description strings for equipment items (and then translate them once merged, of course). Another thing that would be very helpful is for someone to take time during Stage 2 to tune and balance the various ship templates that are used by different mission modules and "properly" generate a threat value for spawned encounters - the current threat value (used to select and outfit enemy ships) is very hacked-in at current to just approach parity with the old version of the mission module. One of the things I'd personally like to see from a "lore" perspective is to define in-universe manufacturers for different equipment items or types of items. This is low-priority however, and something that will be looked at near the end of Stage 2 if at all. I would very much appreciate some design/ideation work being done on additional uses for passenger cabin slots, and new equipment items for computer and utility slots (as well as providing variants for larger sized slots with different benefits/tradeoffs). We've kicked a few ideas around on IRC before, but shelved them as Stage 1 was nowhere near complete. On the "highly familiar with the game code" end, we need to split engines out into equipment items, rework missile code almost entirely, and implement several new systems. I don't have enough brain at this juncture to fully enumerate this.
This is mostly by design, as we consider carrying passengers to require intentional design work on the part of the ship manufacturer and not something that can just be easily retrofitted in at the player's whim. You will be happy to know that most of the larger ships contain affordance for cabins even if not specifically designed as a "passenger ship", and we plan to add multiple uses for "cabin slots" beyond just carrying passengers. Of note - one of the core decisions of this rewrite was that equipment can never be installed in cargo volume. The old equipment system functioned that way (worse, it considered cargo to be just another equipment item) and it was the single biggest source of player confusion, bugs, and over-complicated code in the equipment system. To provide similar flexibility to the old system (and provide the player with "meaningful choices"), we do plan to introduce a "hull variant" system which would express these larger changes to a ship's internal layouts in a more permanent fashion - for example, providing a VIP version of a courier hull the player can purchase which replaces the cargo hold entirely with a set of passenger cabin mounts. |
Uh.. I feel responsible.. 😅
Hmm, this design decision prevents players from being able to react to current mission offers. Currently I can (mostly) change my ship loadout to suit a lucrative mission opportunity, but with the new system I guess I would have to buy a new ship? |
With (what we're internally calling) S1 ships, this is by design. They physically do not have enough space to be true "multirole" ships, and as a consequence limit the activities you're able to take on in the early game. If you've started in a light combat-courier (Coronatrix), you won't be able to take on bulk cargo contracts or commercial passengers. If you've started in a passenger ship (Lunar Shuttle), you might be able to take a small cargo delivery "along the way" but will mostly be focused on hauling people around and completely incapable in combat. While the old system was more flexible in this regard, ships under the old system were also extremely over-tuned and their stats were quite divorced from the actual size of the ship. Do note that I think there's potentially a bit of crosstalk happening here - under the new system, you will still be able to do "a bit of everything" in most ships, and I intend to add some more "entry level" mission profiles during Stage 2 which are tailored to the new capabilities of ships. However, we intend to provide "meaningful choices" to the player - if they want a ship that is specifically tailored for fighting, they will have to sacrifice a lot of multirole capability. If they want a multirole ship, they won't be able to take on the most difficult and lucrative domain-specific missions (e.g. combat, bulk cargo, bulk passengers, etc.) as easily or at all. To answer your specific question, players are intended to still be able to change up their equipment loadout to adapt to missions - but not to the same level of insane flexibility as before. Hull variants are intended to complement this design decision, allowing players to "specialize" towards a specific capability or activity - but with a greater level of commitment than "just change it out at the next station". |
|
Purchasing used equipment from BBS:
|
Creating as WIP PR for visibility and collaboration purposes. No guarantees this runs or is fully functional at this juncture, though I've tried to ensure I have a working test case during most of development.
This branch is the culmination of several years of sporadic design discussion about Pioneer's current equipment system and the problems it presents for certain important gameplay systems we'd like to enable.
We've been laying the groundwork for a replacement system on IRC and in the dev docs for quite some time, and enough ducks lined up in a row to be able to put fingers to keyboard and start writing the replacement for the existing system.
The Problems
laser_front) an item is installed inThe Solution
We've settled on a logical extension to the slot-based design of the prior equipment system, but allowed players to interact with the individual slots on their ship as first class features rather than hidden constraints.
Slots have type and size constraints (potentially extended to resource availability, e.g. power/ammo in the future) which limit the types of equipment that can be installed and allow some additional stratification of ship roles; an AC33 is probably not going to be happy with a shield generator designed for a Pumpkinseed, and a 20MW pulsecannon cannot physically be connected to a Coronatrix no matter how much you shuffle around the insides.
To complement this system, all equipment items that are installed on ships are now thin instances of equipment item "prototypes". This allows for very easy future support for individual equipment item state, like damage/wear, power on/off, and "tuning" equipment items to be better in specific capabilities (at the expense of others).
Status
This branch is by no means feature complete. As of time of writing, the diff is 4k lines added, 1.8k lines removed, and quite a bit more is expected. I'm creating this PR now to collaborate with other contributors and to seek some feedback from interested parties on anything I might be forgetting.
The overall effort to move to the new equipment system is broken down into three stages:
Obviously, there's a lot of work to do, far more than I can accomplish on my own in a reasonable timeframe. I likely won't have as much time to dedicate to Pioneer moving forwards as I did this year, so I hope other developers can help share the load and move towards getting this feature complete.
TODOs:
Update new game window to support new equipment systemDEFERREDEquipment list spreadsheet
CC @JonBooth78 @Gliese852 @bszlrd for feedback and collaboration.