-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
basecamp, faction camp: start merging faction camps into basecamps #26764
Conversation
c80f2c3
to
d8a9354
Compare
8c65900
to
ed16f0b
Compare
ed16f0b
to
26a8aaf
Compare
26a8aaf
to
fe7e5bf
Compare
fe7e5bf
to
7be8430
Compare
Don't know if this is related yet, started a camp and upgraded it to the level that has crates, dispatched menial laborer, and encountered a segfault when I recovered them:
|
In basecamp_menial_return(), p.companion_mission_points is empty, but it gets dereferenced. |
I think I've figured out the upgrade issue: editmap::mapgen_set creates a new tinymap at the existing overmap tile position and copies stuff over from the existing overmap tile's submaps to the new tinymap's submaps. It's supposed to copy over the basecamp:: but the implicit assignment operator isn't working or something. |
64a400c
to
43ee1ea
Compare
Okay, what was happening with expansions:
I still need to write test cases. That's going to be a few days but the rest can be reviewed. I'd be fine with submitting them as a separate PR, actually. |
43ee1ea
to
ba63617
Compare
I'll accept this without unit tests, just pointing out that the cost/benefit ratio seems likely to be favorable since it's so hard to test manually. |
Started work on the unit tests, but the actual code flow depends on pop-ups and the test harness handles those poorly as far as I know. Refactoring everything to be easier to test would be a large task. It will probably happen as part of moving this stuff to JSON but I don't see an easy way to do it now. |
Not sure if this one is related, it might be pre-existing. I debugged in some NPCs and used mind control on them. I picked one and told them to be camp manager, then they were bugging me about not being able to breathe so I accepted their mission and gave them an inhaler. Now they're marked as a Camp Manager, but they don't have any dialog options for it. Teleported to an entirely different zone, made sure to satisfy the new NPCs mission needs, then started a camp. I can enter the manager dialog now, but if I select "What needs to be done?" I get "There are no missions at this colony.". Possibly pertinent minutiae, I'm mind controlling NPCs like crazy, teleporting all over the place, and I think I have 6 active camps scattered around at this point. |
No missions at this colony probably means that something went crazy with finding the basecamp. I'll see if I can reproduce it. |
ba63617
to
e58a3b6
Compare
camp_farm_description and camp_farm_return used a triplet of booleans to indicate if the description or return involving plowing, planting, or harvesting. Replace those booleans with an enum for clarity.
move become_overseer() into faction_camp.cpp for clarity correct test the npc_list in the hide start functions for !empty instead of empty. make the function to find a basecamp slightly less inefficient.
add data structures to hold faction camp data to the basecamp class, along with some functions to manipulate them. faction camps are defined by: * the overmap position of the camp * a vector of tripoints holding the sort points * a vector of string directions indicating active expansions * a map of string (directions) to expansion data expansion data consists of a string indicated the type of expansion, an int indicating the level, and a tripoint holding the overmap position. With this commit, these are empty data structures.
e58a3b6
to
e7f2d8c
Compare
The logic for finding a basecamp was indeed messed up. I have unmessed it up, I hope. |
Jenkins rebuild |
This pull request has been mentioned on Cataclysm: Dark Days Ahead. There might be relevant details there: https://discourse.cataclysmdda.org/t/aircraft-in-game/17669/6 |
After many many weeks of upgrades, I encountered this segfault when retrieving a blacksmith from a crafting job:
|
add a function to check if a basecamp is at a global overmap position and create one from an existing faction camp if there isn't. Replace all references to faction_base_* as a way to determine a faction camp's upgrade level with calls to basecamp. Delete some now obsolete code in talk_function::.
e7f2d8c
to
e85de45
Compare
Dangling basecamp pointer resolved. |
I was testing with a basecamp, spent hours on it. |
Summary
SUMMARY: Infrastructure "basecamp, faction camp: start merging faction camps into basecamps"
Purpose of change
Faction camps use the omt_terrain of the overmap tile containing the camp overseer to determine camp progress. This is bad and needs to be changed in order to do any serious improvement of faction camps, especially to make them more JSON friendly and to allow alternate upgrade paths.
Step 1 is to find some alternate persistent data structure that can hold faction camp data. The existing basecamp class is barely used. This PR moves some of the faction camp data into basecamp, with the short term goal of removing all uses of omt_terrain to determine faction camp upgrade process, aside from a single migration function for existing basecamps.
Describe the solution
the basecamp class gets heavily revised, picking up several members:
Various functions for manipulating these structures are introduced in this PR, and some existing talk_function:: code dealing with faction camps have been moved inside basecamp:: if those functions needed access to basecamp:: data internals.
Describe alternatives you've considered
Like everything else in faction camps, there's a bunch of different ways to start this process. I have to start somewhere.
Using the overmap terrain id as a data store is not great design for a bunch of reasons. It's just not compatible with a flexible faction camp design that includes the option to upgrade parts but not all of an overmap tile or take over existing buildings. So while it would be possible to continue with faction camps using the overmap terrain id to determine upgrade process, doing so is not my plan.
I could have moved more functions into basecamp::, but this PR is large enough as it is.
The map of string dir to expansion data isn't as useful as I hoped. A future commit will probably replace it with a fixed array indexed via an enum, but the current string indexing is built fairly heavily into the code and I don't want to do the necessary surgery at this time.
Additional context
This PR is going to be the first in an extended series that will eventually see the removal of the camp overseer role, the removal of the restriction on upgrading with vehicles on the map, and eventually JSON defined faction camps with multiple upgrade paths, including the ability to take over existing buildings. All of that is gated on NOT using the omt_terrain ID to measure faction camp upgrade progress.
The data structures introduced in this PR are not intended to be the final design of faction camps/base camps. They're being introduced to smooth the transition from the current state to the long term improved state.