nobodyhasthis2

On another topic. Some thinking about my next playthrough that might amuse people .... Following the brilliant Hard Core playthrough but with more mods. I had a better start using k-OS script from the Achive that runs science on launch pad before and after launch. That elimitates ground testing missions early game. Just make sure there is enough power to transmit of all the data. Brining down the collection to 10 seconds helps too if your trying to catch another biome early on. I got very desperate for science early game. Unlocked early flight and used Airplane Plus to supply a Barnstormer Cockpit. Then used it to launch my single pilot on a solid rocket. She bailed out and used her own chute to land giving me EVA report from flying low. There was no way to recover the craft with a survival node unlocked. Dangerous but nessary. The question is this just a bit cheaty? Feeling ok with this at the moment. Early aircraft are still potential "Kerbal killers" to quote Spink. It works but it is an expensive way to unlock another node as the craft get destroyed. All that I could get was EVA report and had to transmit everyting else before ejection. Also there is chance that there is no pilots at the start of the game if Earn your stripes changes does not use the famous four. Getting a pilot after start is expensive. Had fun and then considered using the mod EVA Parachutes & Ejection Seats a bit to expand on the idea of bad starting panes. As the through of "punching out" of crappy early aircraft that don't land correctly is a bit crazy. Could also be the abort escape on the later Kemini launches. Before escape tower ejection on Kpollo mun missions. Will have to experiment more here. Another play balance decision during testing was think about using the early launch stands from Sounding Rockets. Not a recommended mod for conversion with all the extra science experiments and super op command module. However it does come with a launch stick part ( SR_LaunchStick ) that kind of fits in. Experimented with "aiming" for other nearby biomes using launch sticks that drop off with the wind after launch. Not too unbalancing as getting the flight right with no steering was trickey and had plenty room for error. Will probabley leave them out of the playthrough for now as everything else was in the mod was op and needed cut out with Janitor. One thing I really must do is nerf all the technology unlocking costs for the starting structure parts. The steel beam at the start is way too expensive. Building test stands should be possible early on.

Fixed by forcing update to latest as it is backward compatible. Orginal install was: Test build for debugging the logic. No othe mods apart from dependancy files. Running KSP 1.6.1 Unkerballed Start 1.0.4 Missing History 1.7.2 ReStock 0.1.3 I am curious. Did you release 1.0.4 twice to Spacedock without a version number change ? Just bumped versions on CKAN and that fixed it. By the way Is the source code up on Git?

Is anyone else seeing a issue with misplaced build nodes on LY10 Spacely ? I am asking to check if it is just a buggy install for only me. I have got nodes way above and below where the are supposed to be. I can easily use the node code from same sized engine to fix but want to know if this a standalone issue or a broken mod. EDIT: Issue is with Missing History. It breaks the connection nodes.

@SpinkAkron Noticed that unlocking aeronautics does not get wing parts with the rest of early plane parts. Wings cost one extra science point and have there own node. Wondered if you got that idea from the SETI tree? There is a reason we did it that way. B9 Procedural wings where used instead if available. If a player did not have that mod installed there was an option to use the stock wings. Yemo did however did not want to "clutter up" the VAB &SPH with parts that he was never going to use. So the compromise he came up with was an extra node just for wings at one extra science point. That way players that wanted stock wings saw them appear easily for one science point. Whilst players on procedural wings did not see them. It was a good compromise that kept everyone happy. I just thought you might like the story of how that wings node got created in the old SETI mod. Just a through. It is up to you and this is a brand new mod. The cost of these things is $10,000 each without modification. I bring them down in price and place them in with rest of the early plane parts. However here is just some code to move them for now. Try them and see how it feels. Finally thank you very much for sharing this mod. I really like it //aeronautics @PART[B9_Aero_Wing_Procedural_TypeA]:NEEDS[CommunityTechTree,B9_Aerospace_ProceduralWings]:BEFORE[zzzUnKerballedStart] { @TechRequired = aeronautics } @PART[B9_Aero_Wing_Procedural_TypeB]:NEEDS[CommunityTechTree,B9_Aerospace_ProceduralWings]:BEFORE[zzzUnKerballedStart] { @TechRequired = aeronautics } @PART[B9_Aero_Wing_Procedural_TypeC]:NEEDS[CommunityTechTree,B9_Aerospace_ProceduralWings]:BEFORE[zzzUnKerballedStart] { @TechRequired = aeronautics } @kcs123 Ha ha, sorry just noticed that you mentioned B9 wings early on in the thread and the old story of the SETI compromise. Shame that thread was lost again. Nice to see your still around on the forum . I will leave this post up anyway it case the code is still useful.

Check a few pages back. Just take out the third conditional statement in each MM patch. Some of us would gladly patch it for you but not under ARR. Sorry if I am not being specific about changes. I am not trying to be rude. I am just in a rush today.

My version runs perfect because I followed the mutiple folders procedure. One for each version release. SETI is fine in KSP 1.3.0. Up to now setting Max KSP version to 1.99.99 did what Yemo needed to do. However now it should really be capped to 1.3.0 to stop people from automatically installing it into the current version of KSP. Installing the correct build used be as simple as selecting KSP version number in CKAN. However the problems with spacedock version numbers (only one number) or poor version control (version locking where required). Will mean at least 15 or so mods will need to be checked for compatibility. There is also instructions on how to update for latest changes in MM in this forum. If people do want to play in KSP 1.3.1. Although as some key mods used alongside SETI where never updated from 1.3.0. There will never be the full experience anyway. This is the reason there was no update in SETI. That combined with some personal stuff means a new SETI will not come out quickley. If at all.

First off all the costs are all over the place in stock KSP but we come to that later. The planned effect is space craft need big battery packs. Or need to carry fuel cells and tanks of fuel. To support the eletrical systems. Then we get solar and problem goes away. Here is the design choices that where being made. At this stage I confess this all happened over a two year period and I am working from memory only. A lot of this dates back to KSP .90 after all. The old forum content is not around anymore. Yemo may remember it diffrently and it that case. I support his version of the following events. This can be dated back to the movement in solar panels. Without a downward movement on RTG technology. Your probes are supposed to to something useful and then die gracefully. Power generation was through fuel cells and not solar panels early on. The choice made here is turn up the energy density. This is most noticed in the procedural parts code. The original was TANK_TYPE_OPTION { name = Electric // Dry density for the battery banks for Z-200 and Z-4k is 0.163, // and the Z-1k is 0.184. We want to keep this to some 'roundish' // number so the max volumes don't end up as weird fractions of // pi, so will round it a bit. dryDensity = 0.1875 RESOURCE { name = ElectricCharge // All stock parts are the same. This translates to 3500 U / kL unitsPerT = 20000 } } The SETI change was: TANK_TYPE_OPTION { name = Battery // These multipliers give 100 electric Charge at 30 funds cost for // a volume of 2L, comparable to the Z-100 battery. dryDensity = 2.5 costMultiplier = 61.22024 RESOURCE { name = ElectricCharge //unitsPerT = 240000 unitsPerKL = 50000 } } So that gives you a clue as to how energy density (how much juice by battery mass) was set. However we also have a issue with costs right across the board. After kicking around all sorts of solutions the one Yemo landed on was this. //---Until there is an attempt to balance the entry costs, they had to be removed to provide a balanced gameplay on all preset difficulty options @PART[*]:HAS[~category[FuelTank],~category[Aero],~category[Structural],~name[*Tac*],~title[*HexCan*],~title[*Container*],~manufacturer[*Umbra*]]:FINAL { @entryCost = #$cost$ @entryCost *= 3 @entryCost ^= :\.[0-9]*:: } That does not apply to a whole host of basic parts. So things like fuel tanks don't become expensive. Those items have a flat rate 1 'kerbuck' price point. That is pretty much how SETI works with all the dependanies installed. The issue or battery costs dont come in manned flight because it is assumed to be all in cabin: @PART[*]:HAS[~name[RetroMk1inline],@MODULE[ModuleCommand],#CrewCapacity[*],~CrewCapacity[0],~author[*RoverDude*]]:NEEDS[!TacLifeSupport]:AFTER[SETIrebalance] { @RESOURCE[ElectricCharge] { @maxAmount = 205 @maxAmount *= #$/CrewCapacity$ @maxAmount += 310 @amount = #$maxAmount$ } } Of special note is Remote Tech integration in all of this. Here the whole balance of RT has been changed. When it loads you can pick which set up you like. Or can even go and change the settings. The units set on the command seats for example are: %MODULE[ModuleRTAntennaPassive] { %TechRequired = None %OmniRange = 24000 %TRANSMITTER { %PacketInterval = 0.3 %PacketSize = 2 %PacketResourceCost = 5.0 } } If you want to lift up the EC drain but increase battery weight. That is possible.

The answer is complicated but here goes. Before SETI probe parts the only way to launch unmanned was to put a probe core in the start node. Then we got SETI probe parts as another [optional] addon. Which also moves other probe cores to start. That lets you make more aesthetically pleasing sounding rockets. Especially with procedural parts addon on as well. The probe cores should be giving at most stability assistance. Fancy functions come later with better computer technology. The catch is all of this is a moot point now with some of the other things that changed a long the way. First we had kOS added to all probes. So those people doing unmmaned missions by through computer programming. Had something to play with. Of course not everyone does that. However it formed the basis to remove all control on mech jeb. With that the selection of probe parts become irrelevant choices. So it all depends on exactly what else you are installing with the basic SETI mod. The addons all effect probe use. SETI also kind or requires a "sense of roleplay". It is possible to easily by pass some of career restrictions early on and that why there is some suggested rules to follow under the mega mod pack thread. Basically no matter where they are moved to. Somebody else will need them move again. The best option really is to think about how you want to play and move them to your preference depending on other mods being used.

It does not matter as communications will automatically link up if in range. Exception is when playing with the remote tech mod. More on that if you are. At default settings in career mode. Mech jeb functions are unlocked as part of tech tree progression so you will not see everying at the start of a career game. You will also need to have the mechjeb part attached to your rocket in order to use the interface during flight. In sandbox games. Just add the the mech jeb part as eveything works from the start.

This is not choice between two functions. It is a vote to remove one function. People are being asked if they want the forum choices removed. We currently have two methods. If you just want to have a question answered. A voting forum does that quickley. Putting wrong or irrelevant answers in chronological order does not help anyone. New players would have to read through all the stupid advice to get to the correct answer. Why do we need to read the whole thread just to get one post. When we are asking the community to provide the single best post? Anyone who wants a conversion in chronological format can simply start a new thread that does that job. Best of both worlds. Would you like to do this if there was a risk that it can create extra work for moderators? At least with simple Q&A sub forums we can self regulate through voting. The very fact that people are saying "I want chronological order with voting" is a reason to upvote your point about that fact they can't have this as a change. Simply because that is how things already work right now. Either we have the current system or Remove it completely. Dumb things down to one forum choice. Then possibly create extra work for moderators. There is no halfway house here.

We can't have two instances of Nebula. However there is a way two still have two completely different behaviours depending on the data present. This is one instance that changes decals as required. In theory.... Warning "Here be dragons". Test this in a development game first. I may be mistaken. it has been a while since I did mid game changes...... OPTION ONE One possible solution is to pick generic names for both sets of data. Say you have a red text and a blue text option. If both options share the same name, like "NASA". Have each choice in their own sub folders. Remember that they share names with each other so cannot occupy the same folder. Without changing any coding. It is possible to change text color by dropping in the right file from the sub folders. It gets copied into real working folder that Nebular has been told to use . What will happen is the existing color flag will be overwritten and the new color one appears in game. Nebula here is still using the same config and still pulling out the decal called "NASA". From the same place. What it does not know. And does not really care about. Is sometimes "NASA" is a red flag. Sometimes is is a blue flag. Depending on which option was dropped into the working folder. RISK: You can't do both options at the same time. Is that a limitation. Needs to verified in game too. OPTION TWO Actually have diffrent names for all graphic files. Put them all in the same folder. Modify the MM patch as required to only include names you want. @textureNames = dcl2;nebula;esa1;esa2;nasa1 nasa1 option appears in list. @textureNames = dcl2;nebula;esa1;esa2;nasa2 nasa2 option appears in list. RISK: This type of MM patch only works on game load. So will need a game reboot to make the change. A perk is the change only affects new builds. Old ships with attached parts don't change and it is possibe to have diffrent colored ships. Again test things. Please don't take my word for it. Try things out and see what works for you. Have fun

A word of caution here. Sharing from my own experince this is more trouble that it is worth. Simply becuase it is so easy to add in custom graphics. For example putting the letters N A S A into the folder separately. Then onto a ship in game. Takes longer that to just creating the whole NASA acronym as a single resizable flag . It is up to you of course on game preferences. All I am saying is for me personally once I had a good work flow going. I could write decals faster doing them as singe parts. As always your mileage may vary here. Depends on why you are asking.... If you need two copies of Nebula doing two different things. The answer is no way. In fact it is hard to come up with a use case for that setup. or If you are asking if it is possible to add in colored letters an numbers. In multiple fonts. On demand. The answer is "possible with effort". Using the MM patch shown above I was able to introduce new content at will. Without having to change anything in the original mod. If the mod is updated it does not affect my custom decals. So maintence changes are super easy to cope with. The reverse of this is also true. I can dynamically change decals by simple drag and drop. The changes are in my own custom folder and are nothing to do with the original mod. Each variation folder just has the relevant MM patch that tells Nebula where to look for the new content. Again possibly not the answer you where looking for. I was hoping to give you some ideas on some different approaches to adding content here. Nebula Decals can be a powerful little mod once you get used to feeding it data in the right format. It is totally worth it what ever angle you take.

Known bug reported a few pages back. Does not normally come into play as you can switch off KER parts in the in game interface. If you want to clear it the error altogether here is the patch. If you don't want to just delete the mistake. As a personal rule of thumb it is better to use a custom config that tweaks SETI. @PART[*]:HAS[@MODULE[ModuleCommand]]:NEEDS[KerbalEngineer]:AFTER[zzzzSETIrebalance] { !MODULE[FlightEngineer]{} %MODULE[FlightEngineerModule]{} } Have not looked into it but a similar patch can set @TechRequired = unresearchable which removes parts. Also note that "The Janitor's Closet" mod can hide parts in game. To give you a better idea of a patch here is me doing it for SXT @PART[SXTFuel625m]:NEEDS[SXT]:FINAL { @TechRequired = unresearchable } Hope that helps a bit

Worth noting that runways are special KSP biomes. As such landings and takoffs can be recorded during career contracts with the right coding. Although not found in stock contracts the coding potential is there. See the old GAP contract pack for an example of how a mod can detect where your flight start and finish point is. What this means in the future. Is it quite likely that new mission builder will support contacts that require the runway to be used. If it allows specific goals to set by biome detection. If you don't use the runway the you will fail the contact in some missions. Depends on how creative the community gets when the new stuff is released.

@politas could you take a look at the above please. Looks like a more complicated work around that is necessary. I think this a case for resetting MAX_KSP_VERSION on older release. Can you cap Earn Your Stripes version 1.1.1 to max KSP 1.3.0. Then that way the new release just needs one file as before with MIN KSP 1.3.1. to ensure compatability. Ckan will then know exactly what the original intention was here. People will only see the right version of the mod for the current install then. ckan will download the right one. Looking the above might also help with recent work on version control with other mods. @severedsolo sorry to intrude. Trying to help here. The issue of backward compatability recently came up on the ckan thread. Metadata in this case might require some fine tuning and by calling on @politas for help. I was hoping that it saves you time going back over the same ground. That causes a little bit of frustration especially when your not a ckan fan. With a bit of extra support here things could made easier for you long term.

There is your problem. Your own personal design is not catered for. With a modular build system this it gets fixed. Everyone gets to do their own design and can share them with each other here. I really hope you, me and everyone else gets a chance to move things around to our hearts content. There no reason for for one DLC to depend on another here. Unless there a compelling reason to share previous assets. Given the nature of things now and how contracts have beeing developed in the past. It is not likely that new content will have a tech tree dependancy that some how prohibits modification later. Yet we have to wait to see how the current work is implemented to know for sure. Right now modding support has been promised and the DLC is completely optional. As far adding more later on goes. The only thing I will point out again is the limiting factor of economics. That has nothing to do with coding. It is just fact of life that there would be need to be a commercial success across all platforms on the first DLC release. The bottom line for you personally here is skipping a DLC is likely to have no effect long term. A new DLC option to self mod the tech tree is a possible fix but a long time away. I hope you get it at a decent price.

Stock game changes are never going to happen now. So lets look a DLC opportunity. Essentially extentions that do rewrite the game. The mission contract system was a bit problematic through much of development. We finally got something that works as stock. If that is not enough fine tuning is available via the mod Configure Configure. Yet even that holds us back when doing a history simulation. You see it is possible to program the whole thing again but it is awkward to do so. Even if a mod author does it for you it might not be exactly what you want. So lets stick in a GUI on the process and anyone can write contract progression. This way everybody wins by getting the contract progression they want. Now consider tech tree mods. There are all essential the same thing. I can tell you that coding a new tree is a pain. Doing the later part placement is easy but really time consuming as well. Yet at there heart evey variation of tech tree is doing the same thing. So I would say that a second idea for a DLC (which is of course econmically dependent on the first one currently in progress ). Is to again automate the process. Make each tech node an object that can be moved in relation to other nodes. Drop the automatic assignment of parts to a fixed tree position. Allow a default in the parts.cfg as normal but that can be overruled in the tree GUI though a look up table. Of Partname = newnode. As an extra bonus. Allowing players to reset costs via the same table mechanic also solves another problem. Game balance then becomes completely user defined. This way anyone can move things at will. This way everybody wins by getting the tech tree progression they want. People can start with rockets or do planes first. Whatever they want. Plus they can change things around at will to keep things fresh. We also get a flourishing of ideas here on the forums for new challenges. Where new custom setups are recommended. No need for tech tree mods anymore. Today the current situation is all of the above can be done right now. Every choice discussed in the thread so far. However it takes some programing knowledge and lots of time to achieve personal choices. The system I am proposing is a method where all barriers are removed and anyone is free to create their game own experience.

They are not considered compatible unless explicitly stated as such. Some mods complied for 1.3.0 can crash in 1.3.1. I will not post examples for the sake of brevity. Updates on 1.3.0 should be capped with MAX_KSP_Version where this happens. To stop them appearing as updates in 1.3.1. Not all mods do this and end users need to be aware of only the ones that do. Unfortately there are some poorly defined .version files out there that don't refect this. Also note that Spacedock does not even take multiple versions. Therefore CKAN can't block updates with the poor data being supplied. I would strongly advise checking the forum and release notes first befrore accepting any more updates to 1.3.0 builds. As far as doing a SETI build in 1.3.1 goes. There still a few key mods missing from the whole SETI experince. Procedural wings and Procedural parts to name a few. However the mod pack will still work for those that want to beta test it. Share your finds here on what works and what does not. Temp problem on Spacedock side. The ssl certificate needs a update. VITAS poked at to fix but it is the weekend. So small delay expected.

Is really difficult and it is true that the system is only as good at the data provided. As a case in point I have just been watching the following thread after seeing an odd update note on Github. My 1.3.0 build is asking for update to 1.2.0.1 which is a 1.3.1 build. The danger is So therefore that update box should not showing. So indeed cap the ksp_version_max of the previous release to 1.3.0, and set the ksp_version_min of the new release to 1.3.1. However change in progress so this may already be getting done. None the less it just happens to be a good example of how things can change between KSP versions.

Ok good to know. What I was thinking about is mod authors handle it as individuals. There are no hard and fast rules here. Spacedock also only has one KSP version number as well to work with ? I could be wrong but there still think a mod with assumed compatability. Say max KSP 1.3.99 should be listed as available to a KSP 1.3.0 install. That bit is alright and it has been done this way for a long time. However when the mod updates and the notes only say "recompiled for KSP 1.3.1". There would be absolutely no way we can tell if it still works in 1.3.0 without testing it. So the upgrade box appearance here is at risk. Unless the the mod author explicitly says mod update not backwards compatible to an early version of KSP. In which case the upgrade option box should not appear at all on those early versions. The installed version is then the highest we can go without a full reinstall to the next KSP build. Just for clarity here. I am one of those people that sit on old KSP versions until nearly all mods get released for the new game. Since I normally play with around 100 - 175 mods. It takes a while to move across. I get mods in the available pile that are not compatible. There always some uncertainty leading up to a KSP change over.

Agreed. I don't think people realise how much hangs on accuracy of the version data handed in. However may I ask a question. Are we not always bound to the limits of MAX and MIN version setting? VERSION - Required The version of the add-on. KSP_VERSION - Optional, Required for MIN/MAX Version of KSP that the add-on was made to support. KSP_VERSION_MIN - Optional Minimum version of KSP that the add-on supports. Requires KSP_VERSION field to work. KSP_VERSION_MAX - Optional Maximum version of KSP that the add-on supports. Requires KSP_VERSION field to work. If the MIN/MAX is not provided correctly the wrong mods get listed. People can come all up with all sorts of alternative methods of sorting but the bottom line is still in the accuracy in data supplied. I still think people should be reading the mod updates notes first before accepting the supplied version data. Even if says mod update is both MIN 1.3.0 and MAX 1.3.1 compatible in CKAN. I also find using the forum link to greatest CKAN feature ever for working out if a mod upate is safe for an old KSP install. If am not sure about a mods version control. I jump in to the forum and see if people are encountering problems. I also jump to the source page and read up developer notes. If things are looking good at this point I still export the installed mods to a test build to prove the supplied version data. Is this the right way to go about things or I am wasting my time here double checking the up date process?

As another possible alternative. People might like to try out Kerbal Planetary Base Systems. I think it fits in well with late game SETI without modification. Supported by CKAN and works with TAC too.

I think it is creative and useful. Thank you very much. Agreed there is huge potential here. I am kind of seeing this now being added in to the game via Image Viewer at the very least.

Yeah, your right of course. My only concern here is people may be asking the wrong question. The question is do people actually mean they want the "old version". Say 'AwesomeMod=v3.4 ' instead of 'AwesomeMod=v4.0' ? Or do they actually want the "not marked compatible version". AwesomeMod marked KSP 1.3.0 only to loaded in KSP 1.3.1 ? I think what people usally want. Is most often is the second choice. Is to not have to wait for a mods CKAN metadata to be updated when KSP upgrades. A way to get mods not marked as compatible when KSP upgrades. In rare cases we do want we do want to go backwards to a old version of the mod and the CLI choice is the way to go for those happy to use it. However for most people if they change the current KSP version. Load pervious mods. Then revert upwards to the real current KSP version. They get the mods not marked compatible with the current KSP version. Which is normally what they are really after. The logic that I am using here could be flawed but it does have some historical significance. The email traffic for "when is the mod on CKAN?" jumps up after a KSP version bump. This used to be a huge issue when we moved to 1.0.4 With more stable KSP builds authors did not always feel the need to update .version files, or update their mod's metadata coming out of the old * site. Since then we all moved on and things are better now. None the less I still feel the real issue is a lack of patience on the part of end users that just can't wait to use mods on the latest KSP build. Who can blame them, KSP is awsome. Whilst the same can be said of mod authors who already give us so much of their free time. This consumer behaviour of demanding updates is what got us into the whole " fuzzy version number" debate a few years ago. Which is concept we should not be going back to now. On the other hand. In the case where people do actually want a mod downgrade. The requests for down grading mods against the current KSP version seem rare to me. Normally they happen when a new release is broken in some way or there is some other mod conflict. Your mileage may vary here on how common the problem of going back to an older mod version really is. I also must say, to be totally honest here. I may be a little bit bias here in terms of CKAN development time. I would rather encourage people to investigate the current solutions before asking for yet another way to force updates. Up or down. For the majority of people the solution may closer that they think and saves the CKAN team a lot of time in the long run. It is a tough one but there is perhaps bigger issues in CKAN to handle first? So I say try the Compatible Ksp Versions window first please. If that is not the GUI your looking for. No harm done. There is always the CLI if there is really a burning need to have a particular mod version.

It can also be done in the GUI now. Not elegant but possible. I am not sure how well documented the feature is. Since the Compatible Ksp Versions window can allow older mods to appear. Use it to select the older prior versions and then update in again to make the list of mods current. The nice thing here is warning text on the GUI. End users should accept full responsibility if they force install. I found this to be a quick way to check out old mods after a KSP update.