Jump to content

[1.3.x] SETI, Unmanned before Manned [Patreon]


Yemo

Recommended Posts

2 minutes ago, politas said:

That would indeed be simple. Doesn't work with TextureReplacer texture set mods, though.

Really, it takes a perspective gained from working with CKAN metadata for a while, so trust me when I say that there is no simple solution that will work for all cases. I don't think we can really clean up without some additional metadata about what files a mod might create, and even then, we'd need to prompt the user to make sure they want to delete the config. 

Just edited something in, but I guess I better put it here:

edit: Special cases could get a flag, that the folder does not get deleted, to allow that possibility as well, if the mod author desires it or the file/update structure is just not supportive. If the optional flag is not set, the default is true.

"folderDeletion": "false",

 

edit2: Or do it the other way around, default is false, and true is optional. Would also be better for the transition period.

Edited by Yemo
Link to comment
Share on other sites

The one mod that caused the most issue in this regard is FAR. If we delete the folder, we delete the configuration settings it creates. If we don't delete the folder, Module Manager thinks the whole mod is there. Everyone blames this on CKAN. Why does Module Manager think FAR is there if there is no DLL?

Link to comment
Share on other sites

19 minutes ago, politas said:

The one mod that caused the most issue in this regard is FAR. If we delete the folder, we delete the configuration settings it creates. If we don't delete the folder, Module Manager thinks the whole mod is there. Everyone blames this on CKAN. Why does Module Manager think FAR is there if there is no DLL?

The MM :NEEDS[xyz] checks for both top level folder names (folders directly within GameData) and plugin names. If either of those exist, the :NEEDS[xyz] statement is fulfilled. That is handy since many mods do not have plugins (mine included) to check for.

If I was involved on the ckan side, I would simply remove the folder upon uninstall. Imho ckan is a mod for mod install and uninstall. If mods wish to retain their configs beyond uninstall, that is their problem. RemoteTech went and put configs into the savegame folder. Or FAR could make its plugin so it creates a settings file in a new folder called FARsettings. Since that folder would not be generated by ckan, it would not be deleted by ckan upon uninstall. But that would be the mods problem. Or the mod can simply be removed from ckan.

Imho ckan should be a service with certain conditions for proper functioning. If a mod does not like those conditions, just exclude it from the service, so that it does not damage the service or its reputation for all the mods which do.

Edited by Yemo
Link to comment
Share on other sites

14 hours ago, Liondrome said:

When using CTT, Dmagic has Universal Storage versions of the Mystery Goo and the Science Junior. These parts appear in Survivability which is much earlier than the Miniaturization and Precision Engineering nodes that the originals show up in. Also I disagree with moving the second Sounding Rockets parachute nose cone to Survivability. By the time you reach that node you are done with Sounding Rockets and are moving onto bigger parts and the MK16 Parachute.

Forgot to reply to the parachute bit.

The current solution is certainly not first-best. The problem is, that it is simply too easy to use parts for stuff they are not supposed to be used with (RealChutes sizes are not bound by case size). That is also the reason why all radial parachutes are even later. As I consider RealChutes pretty much necessary for a balanced setup (since stock does not provide information on how much parachute area is necessary for which atmosphere and mass), that is what I have to balance the tech tree for. Thermometer and barometer can be fully transmitted anyway, so the recovery part is only about roleplay and funds.

Link to comment
Share on other sites

2 hours ago, politas said:

If we delete the folder, we delete the configuration settings it creates

There was a version of FAR that deletion of config file was desireable. CKAN was wailed to delete settings and issue was reported in FAR thread, while it should not exist if user was followed instructions and deleted whole folder before new install. Deleting configs would be less of two evils when comes to faulty installs. If there is such big concerns about deleting config files, those can be backed up in CKAN\BACKUP folder and warn user about it. Much less issues will be created that way.

There probably will be few other mods with high dependencies that might not fall in this scenario, for those there could be a special flag that need extra care and not to delete folders, but there is not many of such mods.

In case of lost configs, in 99% of mods, those settings are easy recreated, it is minor loss compared to faulty installs.

Link to comment
Share on other sites

9 minutes ago, Liondrome said:

@Yemo the only mentions of dmUSGoo and dmUSMat are in the regular balance mod, and they don't change the tech requirement at all.

Within UnmannedBeforeManned-TechTree.cfg, there is an entry for dmUSGoo and dmUSMat, at miniaturization and precisionEngineering.

Link to comment
Share on other sites

Hello! I'm stuck with one problem with RemoteTech, StockRT and yours Unmanned before Manned plugins. When I use RemoteTech with Stock RT, everything is fine. Probes have they own omnidirectional antennas. But when I add UBM plugin, this Techology Perk is dissapear and i can't use my first unmanned vessels. I tell that story in other thread - 

Maybe you both can deal with it? Please, I hope it helps to improve both plugins. Thanks.

 

UPD. I added in UnmannedBeforeManned-TechTree.cfg this

@PART[RTPassiveAntennaTech]:NEEDS[RTStock]:AFTER[RTStock]
{
	@TechRequired = survivability
}

And it works, i think.

Edited by Demian_Scales
Update post
Link to comment
Share on other sites

39 minutes ago, Yemo said:

Hey @Demian_Scales,

thank you very much for the report.

Since UbM changes the RTPassiveAntennaTech tech node, I will deactivate that MM statement when RTStock is detected. That should work, as far as I can tell!

 

Hello, on StockRT I use RTPassiveAntennaTech as a Reflectron DP-10, I think I need to add support of your mod with something like this:

@PART[RTPassiveAntennaTech]:NEEDS[RemoteTech&UnmannedBeforeManned]:AFTER[UnmannedBeforeManned]
{
	@TechRequired = start
}

 

Link to comment
Share on other sites

Hi All,

So a SETI noob here...just installed the rebalance, and I have a always on display of my memory and FPS.  How do I turn that off?

Second is the SETI tech tree still being used?  or is it all MbU...the latest github shows 1.0.5 as the current version for it.

Thanks for all the hard work.

Link to comment
Share on other sites

16 minutes ago, gunt3rgam3r said:

Hi All,

So a SETI noob here...just installed the rebalance, and I have a always on display of my memory and FPS.  How do I turn that off?

Second is the SETI tech tree still being used?  or is it all MbU...the latest github shows 1.0.5 as the current version for it.

Thanks for all the hard work.

Found it alt+f1 to turn off the overlay

Link to comment
Share on other sites

I'm having a minor issue with the probe pack, ubm, and remote tech installed. The probes that come with the seti pack don't have a signal processor, so they don't work with remote tech (they always have local control). I wanted ask if this was a known issue or if its been brought up already. Thanks!

Link to comment
Share on other sites

20 hours ago, gunt3rgam3r said:

Hi All,

So a SETI noob here...just installed the rebalance, and I have a always on display of my memory and FPS.  How do I turn that off?

Second is the SETI tech tree still being used?  or is it all MbU...the latest github shows 1.0.5 as the current version for it.

Thanks for all the hard work.

SETIctt works but is not developed at the moment, if you are new to SETI, I recommend UbM + CTT instead of SETIctt.

 

13 hours ago, Bahamut said:

I'm having a minor issue with the probe pack, ubm, and remote tech installed. The probes that come with the seti pack don't have a signal processor, so they don't work with remote tech (they always have local control). I wanted ask if this was a known issue or if its been brought up already. Thanks!

Whoops, did the antenna range, but forgot the ModuleSPU (since SETIrebalance took care of that when I tested with RT), thank you very much!

 

@Demian_Scales, @Malah

Changed the RTPassiveAntennaTech to the start node, should work now, thank you very much!

 

SETI ProbeParts v1.0.1.1 (for KSP 1.1.x)

RT Module SPU fixed for probe cores

 

Unmanned before Manned v1.0.9.6 (for KSP 1.1.x)

Mod Support

  • StockRT
  • FTL Drive Continued

 

 

Link to comment
Share on other sites

On 7/8/2016 at 1:02 AM, Yemo said:

 

@kcs123, @politasAnd yeah, the non-ckan install method is painful. And prone to forgetting non-bundled dependencies or installing the wrong folders by accident and so on. Unfortunately some modders decided to pull their mods from ckan. While ckan sometimes messes up, most install issues are due to modders changing folders/filenames while ckan does not properly delete the mod before installing a new version. So it is kind of shared blame in most instances. Had to learn that the hard way as well. CKAN should just delete the old folder before updating a mod and probably at least 90% of the install issues would be solved.

The argument is, that it does not want to delete manual changes to those files. But some mods create files in their folder on first start, so ckan thinks that there is a manual file in there and leaves the folder upon uninstalling. Which then may trigger module manager statements based on the existence of that folder, and thus you have the starting point for a spiral of issues. Imho deleting folders by ckan is the much smaller evil.

 

Yes it would be a smaller evil to get rid of the unwanted files and folders. That is exactly how I put in the CKAN issue report. However this becomes a really evil solution the deeper we look at it. I am kind of hesitant to go into it here because it is obviously not the right thread. However since @Yemo asked and because it is a CKAN vulnerability that pops up in SETI more often that other mods. I guess it worth writing about. Sorry if I made the wrong call here :blush:  

I thought that might be was worth me putting my hand up for this one and explaining a few things. Only because I happen to have started up the open issue report on this one. The one that looks at all the related issue reports and tries to collect together all the information available on the problem of CKAN leaving behind unwanted files and folders. That issue report looks rather simple and so does the underlying problem. Until we start to dig into all the referenced material. My issue report is cross referred to quite a few others.  In short it not just @politas that has taken a look at this one. Everyone has had a go at building a solution to this or another closely related problem (File overwrite stuff goes deep into some of the associated side effects :confused:). Going all the way back to the start of CKAN development in places. The real snag here is my issue report is just a discussion on policy. Yet we can't get an agreement on a way ahead. There is no argument here just a mutual understand that this is complex. That is before the actual code gets discussed. Honestly it really is a deceptive problem here.

In summary.

  1. It is mostly an edge case. It does not come up often and only few mods are affected each time it occurs. 
  2. Fixing it is hell of lot of work. Once you dig into all the permutations of mods available. The best solution is back up you game before doing a lot changes. Honestly there is better ways to doing this that writing a code in CKAN.
  3. There is already a "work around" solution that does the job! In fact it works so well that SETI users should be never see this problem. Some people might not like it but it does work. Everything done to prevent the problem becomes an over complication. The solution is quite simple listen to @kcs123. Lets face it his comments now appear in the OP of CKAN thread for a very good reasons. This is one of them. Not going to repeat the whole thing here. A lot of other people have given the advice before but this is an honest attempt to put in a prominent place. In the hope that it somehow sticks in the minds of more end users.  
  4. In some cases not using CKAN actually does not fix the problem. This might be a culture shock to the anti CKAN people. The problem can be inherent in the structure of some mods themselves. Writing even more complex metadata is not going to help here in all cases.
On 7/8/2016 at 2:35 AM, politas said:

There is also the case of mods installing files into the same folder used by other mods (eg contracts for Contract Configurator, textures for TextureReplacer), so deleting the folder would break something else. There is no simple solution.

Absolutely correct but let's elaborate further. I don't expect everyone has had a deep dive into all the variations of folder structure that CKAN has to deal with. So it might be worth going into it a bit more.  Here is the catch that everyone falls into. Every possible solution can be broken by a different style of mod folder structure. We even have popular mods that write stuff outside of the gamedata folder. There is also a possibility for changing mod behaviour outside of CKAN's operation.  It a case where mod A changes mod B. We get rid of mod A and that breaks mod B. 

On 7/17/2016 at 4:42 PM, Yemo said:

The MM :NEEDS[xyz] checks for both top level folder names (folders directly within GameData) and plugin names. If either of those exist, the :NEEDS[xyz] statement is fulfilled. That is handy since many mods do not have plugins (mine included) to check for.

If I was involved on the ckan side, I would simply remove the folder upon uninstall. Imho ckan is a mod for mod install and uninstall. If mods wish to retain their configs beyond uninstall, that is their problem. RemoteTech went and put configs into the savegame folder. Or FAR could make its plugin so it creates a settings file in a new folder called FARsettings. Since that folder would not be generated by ckan, it would not be deleted by ckan upon uninstall. But that would be the mods problem. Or the mod can simply be removed from ckan..

In terms of SETI for example (trying to stay on topic :wink:). It is looking for other mod folders. Then using a beautiful bit of MM work to change rocket parts. A little tweak here and there the whole game feels more balanced. It is amazing imho. The catch is MM does this by just looking at the presence of the other mods folder. Even if it is totally empty.

If SETI does have snags here it really is down to not doing a clean install on the part of the end user. In this case the control of metadata is tighter. It is accurate and up to date. There is lots of install advice given. Normally the answer is

Quote

"go into your game data folder and delete folder X"

Sure we could come up with an amazing bit code writing here to dodge the problem. However it never going to be as fast as reading the advice and manually cleaning up. Honestly it can be as simple as using a shortcut to look the gamedata folder. Finding the bad mod folder and deleting it. Writing a whole lot of code to do that simple task is kind of counterproductive. There is also no guarantee that a whole lot of code will cover every possible variation that can happen. The catch of course is a manual check of the gamedata folder is counter intuitive. To end users that are often unfamiliar with it. We have keep telling end users to do this because the forums grow in size. Plus humans can forget stuff.

Even I have asked this question here before on cleaning up folders. Where I am 99% sure of how to fix a conflict. Sometimes it is still wise to come here a politely ask other SETI users if this right thing to do. When you have 150+ mods running. A little bit of friendly advice helps.  

On 7/17/2016 at 6:40 PM, kcs123 said:

There was a version of FAR that deletion of config file was desireable. CKAN was wailed to delete settings and issue was reported in FAR thread, while it should not exist if user was followed instructions and deleted whole folder before new install. Deleting configs would be less of two evils when comes to faulty installs. If there is such big concerns about deleting config files, those can be backed up in CKAN\BACKUP folder and warn user about it. Much less issues will be created that way.

Even the back up idea made it's way onto the Github issue report as well. I would not list any particular mod in relation to problem. The past is the past. It just too easy to slip into the trap of saying Mod C was affected but now no longer is. Therefore the problem is fixed.

It is not fixed but is just avoided by Mod C. The original problem is still there for other mod authors to find later on. So it worth remembering historical cases and solutions like creating backup folders where necessary in the future. In short this is a good idea to do a back up. Before people start loading and unloading lots of mods. The only question that remains is should this be coded into CKAN when there are other options already available to do this.

On 7/17/2016 at 9:20 AM, kcs123 said:

In most of cases where CKAN create faulty install is because it does not wipe out entire folder on uninstall or re-install. Especialy in cases of lot dependencies for other mods etc. While it is next to impossible (considering manpower and time at disposal for CKAN staff members) to create better programm for this, @politas,it might be a good idea to write down some guidelines for moders. Similar guidelines as it was written for users how to help with troubleshooting can be done for moders, how to create CKAN friendly folder structure, so CKAN machine can handle better install procedure. I can do some of those, but I'm not aware of all cases as people who have wrote metadata for CKAN, so I'm not best person for this.

Of course, some moders will refuse to cooperate for whatever reason, but most of them will and some moders are not familiar with CKAN, how it works, so they come up with complicated folder structure. Slightly changed moder/user behaviour might improve things a lot. It should not be too much workload on moders and it is not much different how they already need to create Plugin and PluginData folder to be more friendly for MM or how to change "foreach" loops into ordinary "for" loops in code as SQUAD asked.

Well this is the right way to go about it. Which is why I was so keen to get some of @kcs123 install advice out to end users. Even going as far as asking for it to be included in the OP of a new CKAN thread. Same goes for some of @Yemopast debugging advice as well I suppose. Taking off the SETI specific information. It really is as good set of principles on how to control mod behaviour.

Apart from adding to the CKAN metadata format. Or adding multiple dependency mods for specific mod configurations. There are other options out there. Such as writing MM patches to tweak config settings. Or simply managing the local folders manually. That is sometimes a better solution.

However as far as changing mod author behaviour goes. Hell will freeze over first. When CKAN was first started. The initial proposal was to keep everything option agnostic. Basically it conforms to the environment that it is in. Nothing is specified in terms of folder structure or download site. That does create problems but it makes life easier in the long run. By not forcing particular patterns of conformity into mod author creativity.

We could ask the CKAN people to fix this. Or we could ask mod authors to all go in the same direction. However, I am kind of demanding that end users should RTFM first. 

 

 

 

 

 

 

 

 

Link to comment
Share on other sites

I'm trying to find a list or description of the differences between seti-ctt and seti-ubm so that I can choose one for my career.

I get that seti-ctt is more "comprehensive"....which is all I seem to be able to find about it. That doesn't actually help inform me about my decision though...

Link to comment
Share on other sites

2 hours ago, Errol said:

I'm trying to find a list or description of the differences between seti-ctt and seti-ubm so that I can choose one for my career.

I get that seti-ctt is more "comprehensive"....which is all I seem to be able to find about it. That doesn't actually help inform me about my decision though...

SETIctt have much more tech tree nodes and covers larger variety of mods. (part placement in tech tree from various mods). UBM adds only few nodes to stock tree and rearange part placement trough stock tree and covers less mods.

SETIctt is not properly updated for 1.1.3., although it works if you want, but you have to install it manualy and some stuff might be unbalanced due to missing mods that were not updated for KSP 1.1.3 or have change too much since last SETIctt release.

Link to comment
Share on other sites

On 25.7.2016 at 11:08 PM, nobodyhasthis2 said:

[...]

However, I am kind of demanding that end users should RTFM first. 

:wink:

2 hours ago, Errol said:

I'm trying to find a list or description of the differences between seti-ctt and seti-ubm so that I can choose one for my career.

I get that seti-ctt is more "comprehensive"....which is all I seem to be able to find about it. That doesn't actually help inform me about my decision though...

 

30 minutes ago, kcs123 said:

SETIctt have much more tech tree nodes and covers larger variety of mods. (part placement in tech tree from various mods). UBM adds only few nodes to stock tree and rearange part placement trough stock tree and covers less mods.

SETIctt is not properly updated for 1.1.3., although it works if you want, but you have to install it manualy and some stuff might be unbalanced due to missing mods that were not updated for KSP 1.1.3 or have change too much since last SETIctt release.

Actually I m not so sure about the mod support comparison anymore. UbM now has special configs for quite a few which SETIctt does not have configs for.

UbM mainly concentrates on the early tech tree. And on probes first + less ridiculous part placement (ladders, some girders and so on).

SETIctt does what UbM does, plus more challenge/realism (no reaction wheels at the start, much later fuel lines) and it aims at the whole tech tree.

At the moment (and especially if you are new to SETI) I recommend going with the Dependencies/Recommendations/Suggestions for UbM, except perhaps VenStockRevamp, which has some issues at the moment. More up to date, some improved science progression concepts and more stockalike. You can delete the (empty) SETIrebalanceReactionWheels folder from SETIrebalance, if you dont like the reaction wheel nerf/balancing.

 

 

And while talking about the recommendations and dependencies, that might need some work as well. Perhaps all the general/convenience/gameply mods to SETIrebalance recommendations and suggestions, depending on their necessity. And the tech tree recommendations and suggestions can then focus on supported part mods.

Link to comment
Share on other sites

Does the SETI Rebalance mod change the cost of Procedural Parts' heatshields at all? Just for some reason mine are costing $11k for 1.25m and a whopping $185k for the 2.5m version and I'm trying to work out what's causing this

Link to comment
Share on other sites

On 8/7/2016 at 6:49 PM, baldamundo said:

Does the SETI Rebalance mod change the cost of Procedural Parts' heatshields at all? Just for some reason mine are costing $11k for 1.25m and a whopping $185k for the 2.5m version and I'm trying to work out what's causing this

It changes tech tree research entry only. Certainly don't think it is 11k for 1.25m. That is too much.

@PART[proceduralHeatshield]:NEEDS[ProceduralParts]:AFTER[ProceduralParts]
{
	@entryCost = 1200
	@title = 0 Procedural Heat Shield
	
	@MODULE[ProceduralPart]
	{
		%textureSet=HazardStripes
	}
}

As far as the other questions in mod comparisons go.

On 7/30/2016 at 10:39 PM, Yemo said:

Actually I m not so sure about the mod support comparison anymore. UbM now has special configs for quite a few which SETIctt does not have configs for.

UbM mainly concentrates on the early tech tree. And on probes first + less ridiculous part placement (ladders, some girders and so on).

SETIctt does what UbM does, plus more challenge/realism (no reaction wheels at the start, much later fuel lines) and it aims at the whole tech tree.

Well things where stuck in limbo for a bit with SETIctt (ksp version bumps and civil war issues encouraging putting updates off). So the main version was the lighter UbM mod.

In theory. We could just copy the new UbM patches into the SETIctt mod folder. To get to full support started up again. Taking into consideration the tree node difference. Then start the slow process of nerfing /enhancing the occasional odd part. To fit into the SETIctt progression. Any thoughts on this?

EDIT on second thoughts. Now is probably an ideal point to introduce the big tree change that was proposed. Before adding parts support back in. If that is still an option.  I remember seeing a dev version some time ago that would change the layout. 

Edited by nobodyhasthis2
Link to comment
Share on other sites

  • 3 weeks later...
On 11.8.2016 at 4:58 PM, nobodyhasthis2 said:

It changes tech tree research entry only. Certainly don't think it is 11k for 1.25m. That is too much.


@PART[proceduralHeatshield]:NEEDS[ProceduralParts]:AFTER[ProceduralParts]
{
	@entryCost = 1200
	@title = 0 Procedural Heat Shield
	
	@MODULE[ProceduralPart]
	{
		%textureSet=HazardStripes
	}
}

As far as the other questions in mod comparisons go.

Well things where stuck in limbo for a bit with SETIctt (ksp version bumps and civil war issues encouraging putting updates off). So the main version was the lighter UbM mod.

In theory. We could just copy the new UbM patches into the SETIctt mod folder. To get to full support started up again. Taking into consideration the tree node difference. Then start the slow process of nerfing /enhancing the occasional odd part. To fit into the SETIctt progression. Any thoughts on this?

EDIT on second thoughts. Now is probably an ideal point to introduce the big tree change that was proposed. Before adding parts support back in. If that is still an option.  I remember seeing a dev version some time ago that would change the layout. 

Yep, though at the moment I have very little time. For SETIctt rewrite I first want to see what ksp 1.2 actually does. If it goes like 1.0 and 1.1 I m not really inclined to put work into it just for it to get crushed in again, especially with my current time constraints.

I guess there will be enough to do to keep UbM and SETIrebalance running, as well as the support mods. The main gameplay differences between SETIctt and UbM are just that the latter has reaction wheels from the start. The more science required for SETIctt is kind of more than balanced out by the fact that UbM gives you high gain science experiments (materials bay and mystery goo) much later.

15 hours ago, winproof said:

hello

can i use SETI with RSS?

You can certainly try, I did not try so far. Though especially the RemoteTech modding/ranges might be off, have not tried those as well.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

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...