Jump to content

Teykn

Members
  • Posts

    18
  • Joined

  • Last visited

Reputation

5 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Heyo, wondering if anyone has knowledge on nested ALL parameters. Have a contract that is structured like this: PARAMETER { name = OrbitWrapper title = Complete both orbits type = All notes = These orbits can be completed in any order. completeInSequence = true PARAMETER { name = Orbit1Wrapper title = Complete orbit 1 type = All disableOnStateChange = true PARAMETER { name = Orbit type = Orbit minPeA = @/startPeA minApA = @/startApA maxApA = @minApA + 100000 targetBody = HomeWorld() } PARAMETER { name = Duration type = Duration duration = @/FirstDuration preWaitText = Stay in specified orbit for waitingText = Orbiting... completionText = Orbits completed, you may alter your orbit now. } } PARAMETER { name = Orbit2Wrapper title = Complete orbit 2 type = All disableOnStateChange = true PARAMETER { name = Orbit2 type = Orbit minPeA = @/startPeA minApA = @/endApA maxApA = @minApA + 200000 targetBody = HomeWorld() } PARAMETER { name = Duration2 type = Duration duration = @/SecondDuration preWaitText = Stay in specified orbit for waitingText = Orbiting... completionText = Orbits completed, you may fire retros when ready. } } } However, in game, I've noticed that the Orbit parameters do not display the requirements for completing the parameter. CC debug menu says that hideChildren is set to false, so I am not sure what else could cause the orbital requirements to hide beside it being a nested ALL parameter. Any idea what could cause this?
  2. Heyo, is there anyway to create a list from 2+ other lists in CC? What I'm trying to do is something like: where stationList and highOrbitList are both lists of vessels. I doubt this is the correct syntax though, since + is used mostly for numbers afaik. What should I use here?
  3. Ok, with further testing, it seems the issue is NOT in the HasCrew parameter, but with how CC updates i think. If VPG #1 defines a vessel and there is a VPG #2 that uses the vessel, then whenever VPG #1 completes, which changes the state of the vessel, all of VPG #2’s child parameters are satisfied no matter what. EDIT: Issue has been fixed. Turns out completeInSequence = true is needed for child parameters as well to ensure they don't break. I'm... not sure why they're needed or how that fixes it but I'm not going to question why.
  4. Ok, did some more testing, here's what I found and I am very confused about it. Launched a new station, blah blah, VPG #1 is satisfied. Under VPG #2, HasCrew is satisfied and so is Orbit, but the Duration did not start. I thought it was a visual bug I decided to go back to the space center, to the tracking station, and back to the station, to see if anything changed. HasCrew became unsatisfied, which I thought was good, but the Duration started, when it shouldn't be, since the 2 parameters needed weren't satisfied. I am now 200% more confused.
  5. Question regarding the HasCrew Parameter, and overall how CC tracks and updates parameters: I've been experimenting with the parameter in a contract, specifically in a VesselParameterGroup. Currently having trouble within 2 VPGs. See below: VPG #1, which defines the vessel "spaceStation": VPG #2, which comes after VPG #1, and uses "spaceStation": When testing, I sent a station up with 0 crew first, and it satisfied the HasCrew parameter in VPG #1. No problems so far. What I did notice however, was that the uncrewed Station was satisfying the HasCrew parameter in VPG #2, which requires a minimum of 2 Crew members be on board. This has led me to question how CC saves the properties of vessels for VPG parameters. I'm not sure how a 0 crew vessel is satisfying a 2 crew parameter, which is really bad, because I don't want the Duration parameter in VPG #2 to start until it has crew. Any ideas?
  6. Is there any way to have a PartValidation Parameter detect specifically Cupolas? I dont see a partModule for cupolas hence why I ask.
  7. Hmm, there's not a lot of cases where I would have a duration in the same VPG where vessel is also defined. Afaik defined vessels can be used across different CONTRACT_TYPEs in the same .cfg file, which is what I am currently doing. However, this does not allow for tracking in different scenes besides flying the vessel directly. Would having a vessel DATA node be set to the vessel defined in the VPG in the first CONTRACT_TYPE allow for better tracking to occur with VPGs in the second CONTRACT_TYPE?
  8. Hmm, I'm guessing that having the Vessel stored in a DATA node allows it to be tracked across all flight scenes? I've tried it with just a regular "define = targetVessel" in one VesselParameterGroup and have it be "vessel = targetVessel" in another VPG, which is the one where i'm wanting to track the vessel duration.
  9. Heyo, Just wondering if there were/are plans on changing how vessels are tracked, if possible, or if it's possible to change how it's tracked via extending nodes like parameters? I discovered recently that, with a vesselParameterGroup with a specific vessel and a time requirement (e.g. stay in orbit for 30d) that CC only tracks it while in flight or in the Tracking Station (i think). I'd like CC to track the vessel (and the contract parameters pertaining to said vessel) across different scenes, but I'm presuming that this functionality hasn't been added due to KSP limitations or something?
  10. After doing some more editing, I think I've figured most of the things out, however there's something that I find odd and I don't know why CC is working this way: I have an int DATA node in the Groups.cfg for a funds multiplier like this: DATA { type = int title = Fund Modifier fundModifier = 1 } and in a CONTRACT_TYPE, I have this: advanceFunds = 10000 * @localMod rewardFunds = 5000 * @localMod DATA { type = int localMod = $fundModifier } BEHAVIOUR { name = NoFailureProfit type = Expression CONTRACT_COMPLETED_SUCCESS { $fundModifier = 0 } } Now, my intention with this is for Contract 1 to be completed once with a >0 advance and reward fund. And imo this should, in theory work. However, CC seems to register localMod as 0, even though $fundModifier hasn't been, or shouldn't've been affected by the BEHAVIOUR node. Is there any way to fix this problem? Any alternate solution I should use?
  11. Sorry for even more questions lol What might cause the HasCrew parameter to break? I have such a parameter that detects if a vessel has 3 crew members on board, yet whilst the vessel is uncrewed, it satisfies this parameter somehow Are you able to use BEHAVIOUR nodes to adjust data created by another BEHAVIOUR node in another contract? E.g. Contract 1 creates "TestValue" by a BEHAVIOUR. Contract 2 wants to edit "TestValue" with a BEHAVIOUR. Is there any way to deduct funds if a vessel is terminated from the Tracking Station? A VesselNotDestroyed PARAMETER does not work when a vessel is terminated sadly. What is the priority between PARAMETERs, BEHAVIOURs, and REQUIREMENTs with checkOnActiveContract = true?
  12. Sorry for so many questions: If a contract is accepted, and then after a requirement is not met, does the contract fail? Can I use an inverted ValidVessel Requirement inside a contract, and have the ValidVessel target a vessel that is going to be defined in the same contract?
  13. Regarding this, my main goal is to have something that can detect if a vessel exists that can ALSO subtract funds if it doesn't exist. So regarding this, would it be possible to make a Parameter that checks if a vessel exists?
  14. Heyo, I have a few questions. Hope you guys can answer. 1. Is it possible to use a BEHAVIOUR to subtract funds? 2. Is it possible to use a REQUIREMENT for detecting if a vessel exists, so that if it isn't detected, the contract fails? Could it also work with BEHAVIOURs as well?
  15. There aren't any contract packs for Rp1. If you want more xplane contracts, please go to the Rp1 github and/or discord (in #rp1-feedback), and suggest so. I believe the devs think the current quantity of contracts is sufficient, but idk. Do note that it is Realistic Progression 1. The methods of propulsion in the game have a basis in reality (whether it be flown or theoretical engines). Interstellar travel is impossibly difficult with what is in game, thus KSPIE is most likely not going to be supported. With what's currently in ROKerbalism, I don't think so. ISRU stuff is in development though iirc. Feel free to check the rp1 discord in #rp1-kerbalism. Refer above for info about KSPIE.
×
×
  • Create New...