Teykn
-
Posts
18 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Teykn
-
-
Heyo, is there anyway to create a list from 2+ other lists in CC?
What I'm trying to do is something like:
QuoteDATA
{
type = List<Vessel>
requiredValue = true
validVesselList = $stationList + $highOrbitList
title = Must have a valid vessel
}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?
-
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.
-
On 1/28/2022 at 5:36 PM, Teykn said:
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":
PARAMETER
{
name = vesselGroupLaunch
type = VesselParameterGroup
title = Put your first Space Station in Orbit
notes = The station must include at least 1 Docking Port and support for at least 3 Crew
define = spaceStation
defineList = spaceStationsEarthPARAMETER
{
name = NewVessel
type = NewVessel
title = Launch a New Station
hideChildren = true
}
PARAMETER
{
name = Crewmembers
type = HasCrew
minCrew = 0
maxCrew = 0
title = Uncrewed
hideChildren = true
}
PARAMETER
{
name = HasCapacity
type = HasCrewCapacity
minCapacity = 3
title = Space for at least 3 crew
hideChildren = true
}
PARAMETER
{
name = DockingPort
type = PartValidation
partModule = ModuleDockingNode
minCount = 1
title = Have at least 1 Docking Ports
hideChildren = true
}
PARAMETER
{
name = Orbit
type = Orbit
minPeA = 250000
maxApA = 2000000
targetBody = HomeWorld()
title = Reach Orbit with a Perigee greater than 250 km and an Apogee less than 2,000 km
hideChildren = true
}
disableOnStateChange = true
}VPG #2, which comes after VPG #1, and uses "spaceStation":
PARAMETER
{
name = stayOnStation
type = VesselParameterGroup
title = Keep at least 2 crew aboard the station for 30 days.
vessel = spaceStationcompleteInSequence = true
PARAMETER
{
name = CrewmembersDuration
type = HasCrew
minCrew = 2
title = Have at least 2 crewmembers on board
hideChildren = true
}
PARAMETER
{
name = OrbitDuration
type = Orbit
minPeA = 250000
maxApA = 2000000
targetBody = HomeWorld()
disableOnStateChange = true
title = Remain in a Stable Orbit
}
PARAMETER
{
name = Duration
type = Duration
duration = 30d
startCriteria = PARAMETER_COMPLETION
parameter = OrbitDuration
parameter = CrewmembersDuration
preWaitText = Transfer to the station in the specified orbit.
waitingText = Orbiting...
completionText = Stay completed, you may return home now.
}
}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?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.
-
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":
SpoilerPARAMETER
{
name = vesselGroupLaunch
type = VesselParameterGroup
title = Put your first Space Station in Orbit
notes = The station must include at least 1 Docking Port and support for at least 3 Crew
define = spaceStation
defineList = spaceStationsEarthPARAMETER
{
name = NewVessel
type = NewVessel
title = Launch a New Station
hideChildren = true
}
PARAMETER
{
name = Crewmembers
type = HasCrew
minCrew = 0
maxCrew = 0
title = Uncrewed
hideChildren = true
}
PARAMETER
{
name = HasCapacity
type = HasCrewCapacity
minCapacity = 3
title = Space for at least 3 crew
hideChildren = true
}
PARAMETER
{
name = DockingPort
type = PartValidation
partModule = ModuleDockingNode
minCount = 1
title = Have at least 1 Docking Ports
hideChildren = true
}
PARAMETER
{
name = Orbit
type = Orbit
minPeA = 250000
maxApA = 2000000
targetBody = HomeWorld()
title = Reach Orbit with a Perigee greater than 250 km and an Apogee less than 2,000 km
hideChildren = true
}
disableOnStateChange = true
}VPG #2, which comes after VPG #1, and uses "spaceStation":
SpoilerPARAMETER
{
name = stayOnStation
type = VesselParameterGroup
title = Keep at least 2 crew aboard the station for 30 days.
vessel = spaceStationcompleteInSequence = true
PARAMETER
{
name = CrewmembersDuration
type = HasCrew
minCrew = 2
title = Have at least 2 crewmembers on board
hideChildren = true
}
PARAMETER
{
name = OrbitDuration
type = Orbit
minPeA = 250000
maxApA = 2000000
targetBody = HomeWorld()
disableOnStateChange = true
title = Remain in a Stable Orbit
}
PARAMETER
{
name = Duration
type = Duration
duration = 30d
startCriteria = PARAMETER_COMPLETION
parameter = OrbitDuration
parameter = CrewmembersDuration
preWaitText = Transfer to the station in the specified orbit.
waitingText = Orbiting...
completionText = Stay completed, you may return home now.
}
}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? -
Is there any way to have a PartValidation Parameter detect specifically Cupolas? I dont see a partModule for cupolas hence why I ask.
-
2 hours ago, Caerfinon said:
The data node is convenient for only having to define the key once in a contract and then just use the variable in all other VPG in the contract. I find that having the duration in the VPG where the vessel is defined seems to work better. But I don't really know why it does.
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?
-
On 5/26/2021 at 3:10 AM, Caerfinon said:
This is possible, but the duration parameter needs to be nested in the VesselParameterGroup. The following example from one of my contracts has a 3 day timer that persists through Scene changes and stays associated with the defined Vessel.
// The unique vesselID DATA { type = string craft = "KSRGAPKGOCampsite" hidden = true } // The VesselParameterGroup with the duration timer PARAMETER { name = CampSite type = VesselParameterGroup title = Create a Camp within 500 meters of the marker define = @/craft PARAMETER { Title = in your Rover Camper name = VesselIsType type = VesselIsType vesselType = Rover } PARAMETER { name = HasCrewCapacity type = HasCrewCapacity title = have total crew capacity for 4 kerbals minCapacity = 4 completeInSequence = true disableOnStateChange = false } PARAMETER { name = HasCrew type = HasCrew title = have a pilot trait = Pilot minCrew = 1 hideChildren = true disableOnStateChange = false } PARAMETER { title = Have @/scientistKerbalName on board name = HasPassengers type = HasPassengers kerbal = @/kerbalScientist.ElementAt(0) } PARAMETER { name = VisitWaypoint type = VisitWaypoint index = 0 distance = 500 showMessages = true hideOnCompletion = true targetBody = @/targetBody } PARAMETER { name = ReachState type = ReachState title = Stop and set up camp targetBody = Kerbin situation = LANDED maxSpeed = 0.0 hideChildren = true } PARAMETER { name = CampSite type = Duration duration = 3d preWaitText = Waiting to establish camp waitingText = Camping at site for: completionText = Camping Completed! disableOnStateChange = true } }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.
-
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?
-
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?
-
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?
-
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?
-
23 hours ago, Caerfinon said:
You could set up a parameter that if it failed would subtract failureFunds
// The various parameter-level rewards and penalties. // // Type: float // Required: No // rewardScience = 100.0 rewardReputation = 20.0 rewardFunds = 100000.0 failureReputation = 10.0 failureFunds = 10000.0Regarding 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?
-
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?
-
On 11/22/2020 at 8:13 AM, YaBoyShredderson said:
Any contract packs supported by ro and rp1 that add plane contracts? Like a giving aircraft a purpose kind of thing? Because beyond x planes at the start of a career theres not much point in them, and GAP is a must for my career modes as designing and flying planes is one of the most fun bit of ksp for me.
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.
On 10/13/2020 at 10:48 PM, Сквайр said:Hello. Are there plans to add support for the KSP Interstellar Extended mod and contracts for it?
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.
On 2/1/2021 at 4:13 PM, RP1IsSuperior said:can you build self sufficient bases? I want to combine this with KSPI to visit some exoplanets
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.
-
I would not recommend trying to get RO to work on 1.10. It is not officially supported. Expect things to break or bug out. There's not much to be gained from moving from 1.8.1 to 1.10 though.
-
A LOT of progress has been accomplished. Presented are 4 mission report highlights of a Lunar flyby/impactor, a Lunar Orbiter, an Entry, Descent, Landing Bio Package (EDLBP), and a Venus Flyby!
Presented first is Chang'e's Beryl Tiger, a Tiger-Class LV.SpoilerThe LV stands proudly on the launchpad Striped Tiger (which is limited to rockets that are 60t or below)
Nominal Ignition!
Liftoff!
The Lr79 first stage burnout complete, and the 2nd stage decouples fine. It coasts for around a minute (not captured. The Japanese interfered). Shown here is the Aj10-37 engine ignition if it fails you're fired
After a nominal burn out ok you're getting a raise the Impactor's antenna extends, and LEO is achieved.
TLI stage, featuring a XASR Aerobee (Spacebees are love, Spacebees are life). Shown here is the Ignition.
With a nominal burnout, the probe is on it's way to murder a Lunarian. The moon-dwellers be damned.
Terra, Luna, Sol, and the stars. Space is quite magnificant isn't it except for those damned Lunarians.
Approaching the Moon. One murdered Lunarian coming right up!
This is a gorgeous shot of the moon, don't you agree Chang'e?
Falling
A Lunarian be damned! A successful hunt! A Lunarian and his rabbit have been successfully exterminated. Mission Success, Impact achieved. 2 more shall suffer.
Presented next is Chang'e's Beryl Tiger Eye, so we can keep a track on the Lunarians' population. They must be eradicated. The mission is to send a scientific probe into orbit of the moon.
SpoilerLunar Orbit is harder than murdering a Lunarian so presented is a stronger LV, with an uprated Lr79 and an Aj10-42.
Burnout of the S-3D Lr79 and stage seperation
Ignition of the AJ10-42
Burnout successful. LEO achieved
Due to some horrible negligance you're under arrest for sabotage , There're no images of the Aj10-27 aerobee TLI stage. What's presented next is after the burn was completed and the orbiter was seperated.
Arriving to spy on the Lunarians
After a successful burn (unluckily not captured due to the negligance by the employee that shall be executed soon for treason), Chang'e's Beryl Tiger Eye now spies upon the evil Lunarians.
The EDL mission, launched on the uprated LV used for the Lunar Orbiter, has not been properly documented due to the importance of dealing with the Lunarians. The EDL also occured during the night, which makes for a horrible missionreport. What's presented next is very poor, something China's pride would never allow. Nevertheless, here is the EDL mission:
Spoiler
Successful landing.
Finally, the mission China has the most pride in so far: The Venus flyby, with advances in Communication and Solar technology, and the necessary advance in Avionics technology, since we can know fully control probe beyond Earth. The Probe was launched on a new LV: Leaping Rabbit.
SpoilerLeaping Rabbit on the pad. First stage composes of 3 Single-Chamber Lr87s, burning Kerosene and LOX.
Ignition!
For the first time in a LV past the Sounding Rocket Era, the 2nd stage Lr91 necessitates the usage of hot-staging, due to the lack of power from the RCS. Nominal Ignition is shown here.
LEO successful.
Seperation of the TVI stage. The engine being used is one someone found from the scrapyard. It is the Xlr81 Agena engine. Our tests show that it has a worse failure rate than the aj10-37, which is notorious for being an unreliable engine. Despite this, use of it was necessary due to the lack of power from the Aj10 engine series.
Successful ignition!
Burn Complete. This Scrap engine will never be used again, until it no longer is scrap.
Probe seperation. The 2 solar panels shown are the first solar panels to be flown into space. What's also new is the better antenna, running on the new S-Band. This new band is a lot more efficient, but is solely for Beyond-LEO missions only.
The probe in front of the sun. It is on a 160d transfer to Venus.
After time passed, the probe arrived at Venus, and completed it's mission of a flyby. Interestingly enough, this probe, if it survives, will encounter Venus in the next 6.5 to 7 years.
I hope you guys are enjoying this RiS. While there've been spots that have been demotivating, it's certainly been interesting learning new things. This is my first time playing Rp-1 on ROKerbalism and RealAntennas. Hopefully I don't drop out.
-
Hello, Teykn here, with two mission report highlights. As soundnfury said above, my launch site is in Xichang, China. You'll see a rocket that reflects the location of where it came from.
First up, the 3Mm Downrange contract. (Launch month and year lost due toa launch failure. This is the 2nd attempt. China don't censor me!incompetency.)SpoilerDownrange Rocket HeR-1 stands on the pad. The 1st stage is a standard, tried and true RD-101 engine
borrowed from the Sovietsand a XASR Aerobee 2nd stagestolen from the Americans.
Nominal ignition and burn so far.
2nd stage ignition
From this point, the contract was complete. The aerobee stage will proceed to blow up. It is currently reentering the atmosphere.
Big explosion!
Last up is the First Orbit contract, completed in October of 1954.
SpoilerOx-Class Prideful Needle ignites on the new 60T pad, using improved technology developed locally, featuring an RD-103 engine 1st stage
again borrowed from the Soviets. Stop covering me up!, 2 Aj10-27 Aerobee engine 2nd stage, and the Last stage consisting of the XASR AerobeeYes I understand that you love the Aerobee engine series but we need to be honest.
Nominal flight so far
Stage Separation of the 1st stage. The RCS quads ignite to provide control and ullage, due to the Aerobee's lack of gimbal.
Nominal ignition of the 2nd stage.
2nd stage burn has completed, and the 2nd stage hangs on for a little longer in order to spin stabilize the final stage.
Final stage ignition. This is the final burn before Low Earth Orbit is achieved.
Orbit successful! This Ox-Class Launch Vehicle (OCLV) is the first of its kind, but it will be short-lived. A few more missions are planned, including a Scientific Orbit with advanced science instruments.
[1.10.1+] Contract Configurator [v1.30.5] [2020-10-05]
in KSP1 Mod Releases
Posted
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?