Still working on the contract pack. I have a second contract file 90% done. However, I need to take breaks from writing cfg files. :P
Setting up a GitHub ... thing ... for hosting the raw files on this project, as well as making sharing it in various places easier.
Idea:
Current requirements of the orbital missions (not the initial mission, but the general ones) are such:
Possibly add -- or replace Gravioli with -- this:
Idea: additional story mission type: establishing & upgrading a Remote Tech communications satellite network.
You can format code better by using markdown https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet
Put:
(tripple) ` language
(code here)
(tripple)
Ok, I feel like I lost something fundamental I should know re: your post here.
I apologize -- I must seem thick as a wall right now. But part of my reasoning for doing this is to push myself into learning at least some practical coding.
No. I mean format on the forum.
#include <iostream>
using namespace std;
int main(){
cout << "Format like this. It's on the cheat sheet I gave to you\n";
return 0;
}a lot of people neglect such a nice plugin.
I tried it and it worked, so I left it. Thanks!
ReadMe on GitHub formatted.
OK, so I put another 16h into this, apparently. :)
We are a lot closer, I did a lot of the foundational contract-writing stuff.
But I also removed a lot of mods (will edit here & github in the morning) for performance reasons. I don't like this much, but playability has to be a primary objective. Maybe I'll put a little money into a quad core later in the month, see if that's going to change anything. If it does, I'll probably list 4 cores as recommended min-spec and just go from there.
Okay, started with the mod pack, so far so good... Eagerly anticipating the scenarios/ custom missions... I forgot how much grind early space exploration is in ksp... Luckily I pretty much chose my system set up for ksp so running okay with all listed mods, but can try on my nuc over the weekend if you want testers? Personally I just think this is an awesome project, and deserves attention
(edit..spelling...)
Thank you, @Trooper_ish. Being limited to a dual core right now, I would drastically appreciate any testing.
I took yesterday off from working on the project. Don't want to burn out. I may return to it today, depends on other work.
cool beans, and a well deserved rest sounds needed from all the hours trying to wrap your head around the contracts thing!
Well, back to work. :)
I think I'm going to add "major scansat body scan" to the body orbital missions as a requirement, "major remotetech coverage" (65%) as a pre-base but post-station mission for each body, a repeatable mission for rovers on bodies with bases, going out to a random coordinate and returning.
Thoughts?
So in order to protect the progression in both ways, to keep the mission order moving along a progression, while keeping it from being too difficult randomly, I believe it's best to use Contract Configurator's Persistent Data Store feature. However, I'm uncertain that I know how it works, and I'm uncertain that even if I am using it correctly, I'm using it with the proper code efficiency.
Why are we using PDS instead of DATA nodes? Because I want contract a to be able to unlock contract b, and DATA nodes are specific to each contract .CFG file.
To start, I'll quote the above linked section from the CC Wiki.
Contract Configurator contains a persistant data store that may be used by extension modules. This is intended for storing values that need to be tracked across different contracts. To store data for a parameter, store it using the OnLoad/OnSave functions of the ContractParameter class. To store data for a contract, store it using the OnLoad/OnSave functions of a ContractBehaviour class.
The persistant data store is access by calling one of the two following methods on PersistantDataStore.Instance:
void Store(string key, T value) - This will store the value under the given key. Try to make the key include a prefix for your module to ensure that it unique across all possible Contract Configurator modules.
T Retrieve(string key) - This will retrieve a previously stored value.
So how do we use this in Exodus? Starting at the beginning, we have to initialize the data store, presumably in Exodus.cfg's CONTRACT_GROUPs, like this:
... stuff you can see on GitHub ...
CONTRACT_GROUP
{
name = ExodusStory
displayName = Exodus Story Contracts
ContractBehaviour
{
void OnLoad = A1, A2, A3
}
}
CONTRACT_GROUP
{
name = ExodusDisaster
displayName = Exodus Disaster Contracts
ContractBehaviour
{
void OnLoad = B1, B2, B3
}
}
... stuff ...What we want here is to generate 3 data stores (lists/arrays/whatever) that can store various bodies. In ExodusStory they pertain to Orbited, Station Built, and Base respectively. In Exodus Disaster they similarly refer to Satellites, Stations, & Bases.
What does this let me supposedly do?
Starting at the beginning with the initial doom-confirming Kerbin orbital mission, A1 & all the rest should be empty. When the player completes the mission, the mission file with execute these snippets:
CONTRACT_TYPE
{
.... the rest of the contract stuff ....
CONTRACT_COMPLETED_SUCCESS
{
void Store<A1>(EX01,Mun)
void Store<A1>(EX02,Minmus)
}
}What does it do? By itself, nothing, of course. But if we add to the Orbitals.CFG mission file that determines all other pre-station orbital missions:
... stuff ...
DATA
{
targetbody1 = void A1 Retrieve<A1>(Random)
}
... stuff ...Then the orbitals mission should retrieve a target body value from A1 -- currently EX001 or EX002 (Mun or Minmus) that the player is expected to currently be capable of reaching.
Then, the Orbitals.CFG config file should also include:
CONTRACT_TYPE
{
.... the rest of the contract stuff ....
CONTRACT_COMPLETED_SUCCESS
{
void Store<A2>(EX01,Mun)
void Store<A2>(EX02,Minmus)
}
}Then we can move on to the stations where it should list:
... stuff ...
DATA
{
targetbody1 = void A2 Retrieve<A2>(Random)
}
... stuff ...As you can see, the PDS is being used to unlock mission types via location. Bases will unlock further locations, where the Orbital > Station > Base main tree will repeat.
However, this will tree to a point. Bases & stations both unlock random missions of both the disaster & science lists (B1 & B2, C1 & C2); as well as RemoteTech missions (C1, C2, C3; B3, C3) that can also serve as story mission prerequisites.
So why did I post this....?
Well I have no clue as to whether this should work. As you can see from my quote at the top, there's very little explanation & very few examples given as to how PDS can/will work. So I could be entirely wrong as to how I can implement this feature, or as to my basic logic surrounding how I wish to use this.
Hence, I'd like some input from the many coders on the forum.
So where are we at?
Well, the move is coming into full swing and I've made no progress in the last 2-3 days due to being elsewhere. If I can get my head in the game, I'll work further on the contract pack today.
So I've actually been using GitHub REALLY, REALLY, WRONG.
PSA: Github isn't just a place to park your code.
0.0.1 has been pushed to Github. So has 0.0.1.5 because I forget an important progression clause in the Kerbin Station mission.
It's entirely untested, but I've rewritten the initial Kerbin Station mission to be a more reasonable open-loop system at first. I believe that both the original mission and the initial mission should be completeable at this time. I will be attempting to test this for the next little while. We'll see what happens.
Current status: 2nd "story mission" contract fails out. And it fails out silently. A line out to the Contract Configurator dev, we'll see if he can help.
So I've been playing with the mod list for the last couple of weeks, and boy does the usi lifesupport pack make it challenging! Rip Jeb and Bob... Tried to get the story missions to work without success, will try again tonight, guess I haven't got CC running yet. Or maybe a new start is needed (time to resurrect Jeb and Bob...)