Jump to content

[1.10.1] UnKerballed Start v1.2.0 (Under New Management Aug 28, 2020)


Recommended Posts

1 hour ago, Beetlecat said:

I was toying with the idea, but I have Zero bandwidth for the near term. :)

I took a break today to weed out bugs on KSP and other stuff on my pc, but back to work tomorrow for tantares and some of bdb

Link to post
Share on other sites
9 hours ago, JadeOfMaar said:

In regards to this snippet, this is not how MM works. If it does work, do let me know, otherwise, this is a recipe for bad behavior from MM.

// detect combination of already installed mods
@something[]:NEEDS[ModName1,ModName2]
{
    // declare new name that MM is aware of and that can be used for other patches
    :FOR[ModCombination1]
}

 

Yep, I know that is not proper syntax, it more proposal that MM may be upgraded for something like that. More a wish that MM can do something like that than it already is that can do that. As I said:

On 8/30/2020 at 8:07 AM, kcs123 said:

And sorry for being a bit offtopic, but since I watched TS and MM thread and knowing about need for agreement of proper order how MM patches are executed, some idea have arised about it. I don't know if it is possible, or it may require changes in MM itself, but would be possible to have something like this:

I didn't wanted to bloat this thread too much, since it it more relevant of latest conversation in Tweakscale thread and MM thread where new problem arised with too many competitive mods that racing with each other with LAST and FINAL command. Issue is that for example mod "B" and mod "C" attempt to modify same part defined by mod "A". Both of patches in mod "B" and mod "C" use LAST command in patches. And therefore errors due to  bad patching poping up. And it is not only mod B and mod C, we already have situation that tens of mods compete with each others with LAST command. With more new mods publishing situation is going to be more severe each day.

So, all that talk about FOR command and how it work gave me idea that it may be good if it can be used as mentioned in example above. It might allow to create other MM patches in more convinient way than it is possible now. Sorry, I again going too offtopic for this thread, MM thread might be better place for this.

Link to post
Share on other sites
10 hours ago, Beetlecat said:

I was toying with the idea, but I have Zero bandwidth for the near term. :)

Suddenly, you realize your +1 Free Internets token had a shorter half-life than usual.

Spoiler

American internet providers, am I right? LOL

 

Link to post
Share on other sites

One more thing I'd suggest, again from practical balance standpoint: The MK1 cockpit and passenger cabin don't really make much sense that far down the tree. The reason why it's the starter aircraft cockpit in stock is because it's both cheaper and only has one node. I understand that the reasoning behind this was biz-jets, but that's far from the only use for those parts. Mk1 should essentially be made available when the first jet engine is, cause the only reason to chose it over inline is 1. aesthetics, 2. lower the part count by one, which is soon to become a moot point by this point. The cabin on the other hand can be replaced with 2 inline cockpits, again forming an ugly monstrosity and circumventing this limitation for the cost of one additional part and own sense of aesthetics, it doesn't accomplish what it's set out to do.
What is an actual limiting factor is availability of engines and wings, passenger cabins and cockpits of form factor similar to KSP size 2 have been a thing since WW2.

Link to post
Share on other sites
13 hours ago, JadeOfMaar said:

In regards to this snippet, this is not how MM works. If it does work, do let me know, otherwise, this is a recipe for bad behavior from MM.

This is EXACTLY how MM functions. (And, I might add, proper.) 

As @Lisias has demonstrated (in his modA, modB, modC example) and I pointed out. Any config with an unmet :NEEDS is thrown out BEFORE MM's :FOR declaration functionality comes into play. This is because MM loads every config it finds indiscriminately and only then performs :NEEDS checking to discard those configs as superfluous. (Why process that which you already know will fail.)

So, any config which contains a :FOR[modA] that also contains a :NEEDS[modA] will rightly and PROPERLY be discarded before pass parsing begins.

I don't think this behavior can (much less should) be changed in any way without a serious and in-depth code overhaul. I'll also add, that this helps with proper temporal placement of :FOR between :BEFORE & :AFTER.  

Link to post
Share on other sites
3 hours ago, TranceaddicT said:

This is because MM loads every config it finds 

That's the magic: MM does not loads configs. KSP does that, all at once and on startup, and then MM takes control and walks all the GameDatabase looking for patches, applying them (or not, see :NEEDS) and then declutter the GameDatabase from them.

The difference is subtle, but terribly relevant: MM is not a pre-processor as we are used to use on ANSI-C. By the time MM starts it magic, every config file (being a patch or not) is already loaded, and by the time MM had done its job, it's not possible to redo the process as the patches are not there anymore.

Edited by Lisias
hate typing on mobiles...
Link to post
Share on other sites
1 hour ago, Lisias said:

That's the magic: MM does not loads configs. KSP does that, all at once and on startup, and then MM takes control ...

Right, got it.

The important takeaway being that the :NEEDS validation process (and discarding those not met) happens before any pass processing. 

Link to post
Share on other sites
6 hours ago, Bombaatu said:

Are there any plans to add support for the Wild Blue suite of mods (MOLE, PathFinder, DSEV, etc.)?

You could probably make out your idea for initial placement, post that here, and discuss it further.

Link to post
Share on other sites

Any guidance on whether KSP-IE or the Near Future pieces "fits" the intended progression better?  I haven't used either but notice they both have custom configs...

Also, man am I enjoying this mod.  Though I will admit that until I got up to control wheels I had some serious issues getting any height out of unmanned systems.  

Edited by Kikanaide
Link to post
Share on other sites
18 hours ago, Kikanaide said:

Also, man am I enjoying this mod.  Though I will admit that until I got up to control wheels I had some serious issues getting any height out of unmanned systems.  

Yes, that is why I suggested long time ago to slightly increase part numbers for level one building. It is necessity to use RCS ports early on, and you only got limited unlocked RCS parts too. Key is to reduce thrust on those RCS ports, so that is not too powerful for early light probes/rockets. It is harsh, challanging, but possible to put rockets in orbit. I played on hard settings (everything but quick saves and reverting flight due to possible crackens). Also with all ground stations disabled and only with KSC as part of ground comm network. Long story short, I was able to establish comm network of sattelites, earn money from contracts and started to create space stations and send large expedition to Duna before I put my career on hold in KSP 1.7.x. Enjoyed all mission progress.

Link to post
Share on other sites
  • 1 month later...

@theonegalen Noticed the S variants of the Rotors (EM-16S,EM-32S, EM-64S) havn't been placed properly in the new tree, Especially considering their non-s counterparts. Currently they are in Advanced Landing, Scanning Tech, and Advanced Motors, Respectively. Their part names are rotor_01s, rotor_02s, rotor_03s Respectively.

They fall under the Serenity Expansion

Edited by A lazy noob
Typos
Link to post
Share on other sites

hi - im excited to try this progression tree out. however I'm having a little difficulty getting started. I am unable t control the rocket so it keeps flying off course. I can't see any way to control it in the early progression tree, an thus can't get any science.

there is no reaction wheels or vectorable engine or rcs thrusters for many levels. I'm pretty sure even early rockets could be steered, right? Maybe i'm missing something and it't not installed correctly. is there any way to control the rocket before the FlightControl node?

thanks!

Link to post
Share on other sites
4 minutes ago, dresoccer4 said:

hi - im excited to try this progression tree out. however I'm having a little difficulty getting started. I am unable t control the rocket so it keeps flying off course. I can't see any way to control it in the early progression tree, an thus can't get any science.

there is no reaction wheels or vectorable engine or rcs thrusters for many levels. I'm pretty sure even early rockets could be steered, right? Maybe i'm missing something and it't not installed correctly. is there any way to control the rocket before the FlightControl node?

thanks!

To get started you can set your uncontrollable rocket to spin. Angle the fins on the rear end so it rotates / spins in flight. This will keep it straight. Google spin stabilization for ideas.

That should get you enough science to get a plane in the air. Then visit all the nearby biomes, landing, flying over etc.

That should get you enough to get a rocket together with some RCS for control..

Onwards and upwards!

(Don't forget that each KSC building is it's own biome too!)

Link to post
Share on other sites
11 minutes ago, Cruesoe said:

To get started you can set your uncontrollable rocket to spin. Angle the fins on the rear end so it rotates / spins in flight. This will keep it straight. Google spin stabilization for ideas.

That should get you enough science to get a plane in the air. Then visit all the nearby biomes, landing, flying over etc.

That should get you enough to get a rocket together with some RCS for control..

Onwards and upwards!

(Don't forget that each KSC building is it's own biome too!)

thanks for the quick response. So am I correct in seeing that the first way to control a rocket (even a small one) is with RCS in the FlightControl node? I want to make sure I've installed everything correctly. In the past I've noticed some of the parts don't appear in the correct nodes because of installation errors. All i have is ReStock and KW Rocketry part packs

Link to post
Share on other sites
21 hours ago, dresoccer4 said:

thanks for the quick response. So am I correct in seeing that the first way to control a rocket (even a small one) is with RCS in the FlightControl node? I want to make sure I've installed everything correctly. In the past I've noticed some of the parts don't appear in the correct nodes because of installation errors. All i have is ReStock and KW Rocketry part packs

Yep. It is intended to use only RCS early in career. You don't need to be afraid of "failed" flights. As @Cruesoe suggested, use fins to make rocket spinig, that would give you enough stabilisation to reach high altitude and do some science and transmitt it before your rocket crash. Beside RCS port (that you need to throttle down in VAB), you can use some controlable fins to steer rocket in atmosphere. But, for space, you need RCS until you unlock probes with reaction wheels.

Link to post
Share on other sites

One other little thing that seems odd:

The .1875 Engine Plate (from Making History) unlocks at Tier 3 Basic Construction. However the .125 Engine Plate (from ReStock Plus) unlocks two tiers later, at Advanced Construction. Not sure if you intended for the smaller plate to be unlocked earlier, or maybe for both of them to unlock later. Not a big deal really. The current order is just a bit counterintuitive. Really is a great mod though! Thanks for your work!

Link to post
Share on other sites
On 10/15/2020 at 5:40 PM, A lazy noob said:

@theonegalen Noticed the S variants of the Rotors (EM-16S,EM-32S, EM-64S) havn't been placed properly in the new tree, Especially considering their non-s counterparts. Currently they are in Advanced Landing, Scanning Tech, and Advanced Motors, Respectively. Their part names are rotor_01s, rotor_02s, rotor_03s Respectively.

They fall under the Serenity Expansion

Gotcha, thanks. I'll look into it for the next update.

On 10/20/2020 at 7:35 AM, jfjohnny5 said:

Created a config for CryoEngines. @theonegalen Not sure how to add it directly to Github (sorry), so here's a Dropbox link: https://www.dropbox.com/s/ubxvyq1knv95kd0/CryoEngines.cfg

One other little thing that seems odd:

The .1875 Engine Plate (from Making History) unlocks at Tier 3 Basic Construction. However the .125 Engine Plate (from ReStock Plus) unlocks two tiers later, at Advanced Construction. Not sure if you intended for the smaller plate to be unlocked earlier, or maybe for both of them to unlock later. Not a big deal really. The current order is just a bit counterintuitive. Really is a great mod though! Thanks for your work!

Thanks! I'll take a look at these.

On 10/18/2020 at 2:03 PM, dresoccer4 said:

thanks for the quick response. So am I correct in seeing that the first way to control a rocket (even a small one) is with RCS in the FlightControl node? I want to make sure I've installed everything correctly. In the past I've noticed some of the parts don't appear in the correct nodes because of installation errors. All i have is ReStock and KW Rocketry part packs

I've tested it with just ReStock, but not with that specific combination. The KW Rocketry config comes from the previous owner of the mod, SpinkAkron. As long as nothing's changed with KW (and I'm pretty sure nothing has in about seven years), it should work fine.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...