RoverDude
-
Posts
9,072 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by RoverDude
-
-
So I would like to have a mini tech tree for my parts - how exactly does one go about adding new nodes to the tech tree? Tons of googling have not yet revealed the answer. Also, I see some mods that are part-only (like LLL) that add new nodes and icons I have not seen before in the stock tree, and would be curious to know how that is done.
Thanks!
-
Quick question: With this, can I make fully self-sustainable bases with greenhouses? That's the one thing that made me uninstall TAC.
Correct, that is exactly what this will do. But it does make it hard, so MKS is really meant to fill a niche for folks wanting self-sufficient bases but also wanting an end-game activity.
You would generally do MKS in phases
First, drop in construction equipment and move towards replacing the need for ferrying in oxygen/water/food with the need for colony supplies (think wear and tear on equipment). This is about half the mass.
Second would be to build the additional modules (about 10) to fabricate all of your supplies in-situ. Once these are done, the refineries can be ditched because there's also a module to take your recyclables (scrap metal, plastic, etc.) and turn them back into the base materials.
So consider it more of a mod that extends TAC into a colonization system (with a self sufficient closed system as a nice side effect) than just the greenhouse part.
-
The radial docking adapter is a very welcome addition for more design flexibility. The only problem is that it's hard to tell which end is which. -.-;; Also, if the inner radially-attaching end had a domed or hemispheric face where in clips into the unit it's attached to, it appear more "built in" than it does currently. The current abrupt edges peek through the geometry details of some of your models, leaving the ports looking more "bolted on" than "built in".
Will take a gander - The radial port is actually symmetric, so you can use either end, both have nodes. So each end is right. Just need to make sure there's no confusion with the docking port itself which should not be radial (will have to check, I was doing testing at one point).
On the topic of looking "built in" -- the new airlocks are another great addition that blend very well other design elements, whether radially or stack mounted.hmm.. didn't realize I had an airlock
do you mean the Workspace part? The new lateral lines on the Kerbtrails help a lot in terms of visually breaking up the 'bandiness' when 2 or 3 of them are placed in a line. Thanks!
I must admit I'm a bit sad at what looks to be final demise of the 4-point hub part, but the cageless 6-point hub fills that void suitably in peripheral extensions where the caged hub looks too busy or overbuilt.
Thanks, and yeah I gave it a good try but I now see why nobodly else makes one like this
There's an odd and inconsistent bug with the displayed size of the Supply Hubs in 0.15 -- the hubs will sometimes appear smaller than they should, with parts mounted to them appearing to float in the air where the edges of the model should be. It doesn't seem to affect gameplay, disappears when the base is re-loaded, and has appeared both in my highly modded and lightly modded MKS test installs.
This model did change - it was one of the few that was not sized correctly. Can you try it with a totally clean install of MKS?
Regarding Energy balance -- The reduction is a big help, but it still seems pretty steep for anywhere but Kerbin with it's 3-hour nights.
Interesting - because you should be able to operate on PDUs only. But you will need more than one. I'll post some details later.
-
I see you rejigged your numbers to be in-line with ExPL. Or at least that's what I gather from your cfg to change the BahaPL parts. If so, yay!
Oh - the MKS refinery is still a LOT slower than an EPL smelter, it would have been a pretty large change to too much stuff to change my generation rates at this point. But I will happily support other ore extraction parts
-
Oh - and another side note
Since I just loaded EL - please note that the EL productivity component has zero effect on MKS. This is an artefact of EL adding stuff to my modules. -
Just uploaded a pre-pre release of 0.16 to GitHub. This will be the final version before publish. Balancing is done, just going through some final testing.
-
It seems I got taken the wrong way. As I said, I am not unwilling to change it. though I admit that I'd rather not (but that's because I worry it might cause too much confusion). Also, I'd have to go through the effort of choosing a good color ramp (I think shades of rust would be good).
Now, if you were to be kind enough to supply me with a color-set...
Here's the color ramp that I currently use (which is an orange/rust color):
Resource = Ore
ColorFull = 1.0,0.415686275,0.0
ColorEmpty = 0.729411765,0.592156863,0.498039216
It's consistent with how Kethane does it's color ramp (dark/dull green = less Kethane than bright green). MKS uses a lot less metal so the very large quantities of EL don't really affect me, and there's no real benefit to MKS users to have a ton of metal since it's one of three components they need for the supply chain. Fallback is to ignore EL (and just have two things that are yellow), stomp over it (which boils down to which config gets loaded first), or use different resources (which is what I had originally until discovering EL existed, and decided it would be nicer to have a lot fewer resources in the game, not have multiple names for the same thing, and our masses were already the same).
-
I have a small request, if it isn't too much trouble.
I play with TACLS, with extensive personal customizations via ModuleManager config files. I've been integrating elements of your mod, which I greatly enjoy, into my customized crew support system.
In particular, your KolonyConverter module has been a great asset to my endeavors, due to it's very useful features (i.e., requiredResources, SurfaceOnly option, efficiency based on crew). However, in some situations, I'd like to be able to create a module with requiredResources or SurfaceOnly, but without efficiency based on crew. Thus, if this would be easy for you to implement, I would greatly appreciate an "EfficiencyBasedOnCrew" boolean as a variable of the KolonyConverter module.
Sure. Just added a new field called CalculateEfficiency as a boolean, defaults to true.
-
in the image on the first post , how do you get the modules to connect together sideways like that , i can only connect them from top or bottom.
Those are some older pics - the newer way is to use a hub at the bottom, a tube to connect sideways to another hub, and a module on top of the second hub. Better images of this later in the thread.
-
RE benefit - new range is 200m (to be changed with release and become variable). Easier to set up lots of smaller bases, avoids docking/etc. (kinda a pain) and KAS only has a 50m range for pipes. Plus a bit more Kraken proof - lots of KAS pipes tend to eventually explode my bases.
What I am testing out is REALLY long ranges - like, several kilometers (i.e. out of load/physics range) to see how that works out. Just no guarantee on those yet till I run some tests.
-
WIKI is out of date
Still works, but only between ships that include one of the jumbo-sized storage huts. -
Not sure if this has been posted yet - but is anyone aware of any samples that leverage SCANSat along with ORS to provide visual resource mapping?
-
EL Support:
- Will use the same mass for Metal and Ore
- Will keep MKS conversion rates (which are slower), feel free to change these if you would like. Basically, it would entail changing too much of the MKS conversion rates.
- Will be using MKS values for the Kethane resource mapping - Red for ore, Orange for substrate, to be consistent with how Kethane does a saturation variance not a color spectrum variance.
- Will not, at this time, be pursuing any MKS modules for making RocketParts, etc. Players are free to use MM to add these capabilities to any of the MKS models as they are released under a CC license (with attribution).
- Will provide support for the Bahamut drills
-
I assume you guys are both familiar with these cross-mod resource threads?
http://forum.kerbalspaceprogram.com/threads/74409-The-resource-meag-research-thread!
Yep, I've made it a point to keep my numbers in line with what other folks are already using. Which means I get to do a nice re-tweak when TAC updates their numbers
Granted, getting modders to cooperate is generally only slightly less difficult than herding cats. -
A third of the colors, eh? Hardly. When looked at via HSV, EL uses only a thin 60 degree arc of hue. Saturation is fixed 1 and value is... well, I don't know because I think EL spends most of it's time outside the cone. Technically, EL is using just the one color... just in a different dimension.
I'm not saying I won't change it, but I suggest exploring your options further.
How pleasant. I'll rephrase. Red, Yellow, and Orange are used by EL. Variations of saturation in that range are confusing. Yes, I think I'll explore other options.
-
Hopping on as I am looking into making sure the Modular Kolonization System (MKS) plays nicely with EL as I expect a lot of folks will want to use both mods.
A pair of related and easy questions, and one request
First - can someone please let me know the approximate conversion rate (say, per hour) of ore to metal is in EL? Also what the ratio is. MKS is like 20:1 and 1 per day which I know is a LOT lower than EL, so I want the mods in line.
Second - currently MKS uses the same resource name and coloration for Ore as EL does. The only (minor) issue is that EL uses the coloration range from red through yellow, whereas Kethane and the other MKS resources shade a single color (Green for Kethane, Blue for water, Purple for Minerals). Is there any way we could, at some future release, have EL pick a single color (red, orange, or yellow - not all three) for ore? Right now it's a bit of a challenge finding distinctive colors for the different resources with a third of the spectrum taken for a single resource.
Thanks!
-
So I did another full run test, was able to do an entire colony at 50x consumption with a recycling based supply chain and a pair of greenhouses and kerbitats with four PDU's, also pretty much zero lag. So at this juncture, I spent the morning knocking out the specific items that I want to resolve prior to launch (you can see the entire outstanding enhancement/issues list on GitHub at https://github.com/BobPalmer/MKS/issues?milestone=&page=1&state=open)
Specifically:
Evaluate and finalize Kethane consumption rates. Basically, I am looking at making sure the volume of resources that show up in the default deposits makes sense. These look good, but I want to run some numbers. Will also up-tweak water a bit as right now it's pretty scarce. ORS integration will be done post-release.
Evaluate EL compatibility I'll be installing EL and making sure my consumption numbers are in line with EL (i.e. MKS Ore->Metal conversion should be comparable to EL's Ore->Metal conversion rates). Adding EL-specific modules is going to be something done post-release.
Reset IVA vide for Go-Live Custom IVA views are on the longer range list, but for the short term I need to make sure the current pieces have placeholder IVAs (the tough one is the colony hub as this has six seats).
Add UI Element for ProxyLogistics I'll be adding visibility RE proxy range as part of the UI for these components.
Implement Courage and Stupidity as part of ProxyLogistics Right now, ProxyLogistics is hard coded for a 200m range. This will be changed to a variable range based on the Kerbals in the logistics module, as well as their relative stupidity and bravery.
Add compatibility for Bahamut EL drills This is a pretty popular request, so these configs will be included as part of release.
Update documentation I will be going through documentation, tutorials, etc. and getting them up to date with the latest info.
So at this point, the current version out there (0.15) is pretty darn stable - i.e. none of the release notes above (other than a potential conversion rate change) are breaking. So any final bug reports, etc. will be greatly appreciated.
Thanks!
-
Regarding production rates: so the only thing affecting production rates on the MKS side of things is the overall % Efficiency value? EPL's production values appear to be influencing individual MKS module's production rates (that is: MKS modules with smart Kerbals in them are producing noticeably faster than modules with stupid kerbals inside of them while running MKS alongside EPL). Is this intended?
This is normal - the range between a smart Kerbal and a stupid one is a pretty wide range. Smart ones can be up to 2.5 times as efficient as a stupid one. And REALLY stupid ones will kill your productivity - that's all reflected in the % you see on efficiency, which is 25% - 250%.
The overall affect isn't a bad thing (it adds another dimension to individual kerbal assignments within the base), I'm just still trying to wrap my head around the way the two mods are interacting with each other. I've set up another test install running MKS without EPL to try and get a better feel for things, and will see what I can document -- I think it's safe to say that MKS+EPL will be popular together.
Let me know how that goes as I have not yet played with these two mods together.
I'm also seeing efficiency rates of up to 250% for modules that are actively staffed by kerbals, though 200% seems to be the cap for unmanned modules. Is this working as intended? It's happening both with and without EPL installed, so I know it's not related to that.
Range should be up to 250%, but that would likely require manning (unless you have a LOT of Kerbals). Placement inside of a module gains more than placement inside of the base in general.
I've also been wondering is what exactly the three numbers listed after the efficiency value refer to. (ie: "Efficiency 200% [1k/10s/1m")
1 Kerbal, 10 Workspaces, 1 active module.
RE consumption, I just did a pretty major change to power balancing (a module that required 400K of power per day now requires 120K). This should address some of the power concerns.
-
Wrapping up latest update. Big changes are rebalancing for power consumption, a few new parts, emissives, and a total folder reorganization (for better asset sharing to reduce memory footprint)
-
With regards to physics, would it be possible to just disable physics on modules which are firmly on the ground? call it something like an anchor mode or what have you. I don't think reducing part count would be a solution since people will just use that as an excuse to take more parts with them.
Quick question regarding the new Proxy Logistics functionality: will this still be self sustaining across a separated colony? the way you describe it, it sounds like you would need to move parts manually to the storage units in order for other storage units to pull from them.
It should be self sustaining (i.e. if a Storage Hut for supply sees it is getting low on food, it should try to pull it from another nearby Storage Hut).
(Addendum) and there may be some weirdness RE physics, would need to play with it.
-
Also another question, with the KAS hookup, when you link two end-points there is an option to tell one of the points to "Pump here", do I need to use that?
Reason being I spent about an hour testing KAS and resource transfers etc earlier and it is VERY hard to get resources to move around using KAS, and not even TAC fuel balancer worked, only the Ship manifest mod would move them around, but with this mod it acts a little cheaty whilst landed at ksc (As i was) and allows you to instantly fill or dump tanks etc and while I did "transfer" some liquid fuel from one tank to another I just want to make things clear before I go setting up a base on the mun just to find it isn't working.
Honestly, no idea - I've been doing all of my stuff with docked parts and Proxy Logistics in testing. But the resources should behave like any other resources that allow flow.
One other question, how can I connect the mks modules with docking ports, and guarantee they will always line up in situ? Linked into that, once landed how simple is it to get the mks modules close enough for the docking ports to work? Am I going to need to make a tug of some kind? or is it simply a case of skillful flying until the ports touch?The current MKS port is REALLY aggressive (may be toned down a bit), which helps a bit with docking. Generally, I make sure everything is at the same level in the VAB first, which helps. You can also (for light gravity) dock in orbit and use a sky crane to drop the assembled unit down, or use IR docking washers to rotate stuff if your aim is a bit off (I hear it now works in 0.23.5)
-
FYI no luck on the legacy hub - making it top-attachable pretty much ruins it being able to be attached horizontally and vice versa, going to have to noodle this over a bit.
-
Catching up on the thread, and thanks folks for the great info - this is a huge help. I'm currently working on emmissives so we have working lights, but want to add some of this stuff in.
Dissapearing base: I've not seen this with my older MM, it could very well be an MM or KSP issue with that icon, but to test I am switching over to the latest MM to see how that behaves. Worst case, I'll switch everything to Landers just to make sure this does not cause people problems at launch.
4-Way Hubs: Two ideas. I'm going to first try setting the old hub up with the node order posted earlier in the thread to see if I can get it working right (I'll have to pull the old asset off of Github and rename it). If that fails, I'll make something that's a bit more radially aesthetic.
Tubes: Gotcha on the bandyness, I'll do some playing with the model. Also having separate caps is an excellent idea, and pretty trivial since I just need to clip part of an existing model.
Mechanics Questions:
Efficiency increases the conversion rate. So a module with 200% efficiency will consume and produce at double the speed. This is determined by how many modules you have that are active, how many Kerbals in the ship overall, their intelligence level, and if they are actually inside the module (so crew placement matters). RE stupidity levels - consider that (roughly) a really stupid Kerbal is as valuable as half of an average one, and a smart Kerbal is as good as two average ones. So airlock the stupid ones first
Proxy Logistics Updates:
This one I changed due to performance issues. Proxy Logistics work only between hubs now. Valid hubs are those large round supply huts. All have (at present) a 200m range, and will try to maintain a modest level of resources.
Consider the following base with two disconnected series of MKS components, where Storage A and Storage B are both the jumbo pancake-style Storage Huts (Supply). The dashes would indicate they are physically connected via tubes, etc.
[COLONYUHUB]--[sTORAGE-A]--[CONSTRUCT]
[sTORAGE-B]--[KERBITAT]--[ANTENNA]
If you transfer construction parts to Storage-A, you will instantly see Storage-B try to take a little bit of these. It will always try to maintain this level. So as you pull ConstructionParts from Storage-B into the Kerbitat, Storage-B will instantly take enough resources from Storage-A to keep that minimum level up to date. This can be observed as you do the transfer - you'll see Kerbitat go up, and Storage-B hover around the same number.
The Antenna does the same thing for PunchCards (So you don't need to launch a bunch of Colony Hubs). As the Antenna runs out of cards (I think it tries to keep around 100 or so) it pulls them from any ColonyHub within 200m.
Power Consumption:
Agree on balance, I'm reviewing the rates (part of this is why I have the PDU). As a benchmark, I think having enough to operate on PDU and batteries for a night cycle for four average modules would make the most sense, with solar panels to replenish the batteries. These are large factories, and need serious power (this plays well to the reactors in KSP-I) I'll do some tweaks in that direction. Warp wise, I usually go full-bore for warping, but will do some time tests at 50x to make sure the effect is consistent. Especially if it's the case that I am over-consuming. These balancing parts do not include drills, because those are some power humgry beasts
If there are specific modules that are draining power, let me know. It may be something weird with how TAC-LS works since I subclass off of the TAC GenericConverter. It could also be tied to having a module stuck at 'Active' but missing parts, and when the parts arrive, it tries to play catch-up, thus draining your battery. This may be related to another issue I am chasing down where it thinks there is no space for stuff when a module first kicks in. And thinking out loud, I think there's a very strong corrolation and that it's the root cause of both of these bugs.
Also - Wiki is out of date, I need to re-do the Duna one.
Part Count: I'd be curious what I can do to help reduce part count. Bear in mind a lot of it is less parts and more physics colliders, etc. so in some cases, merging parts does not help (i.e. landing gear) unless I do a really simple box collider that encompasses the landing gear and core module. That being said, I can definitely do a collider review and see what I can merge in.
Again, thanks for the feedback. I'll do another release likely Sunday with the current WIP stuff.
-
I'm interested in this mod but cautiously holding back until I'm sure it will be functional for a long time and not be killed with an update
Yep, fair enough
This thread is more for folks willing to help test it out in an alternate save while I work through the kinks. I'll be doing a new thread on the showcase forum when it hits release.
do you mean the Workspace part? 
[Ongoing Dev] [0.23.5] Modular Kolonization System v0.16 (RELEASE) [05-10-2014]
in KSP1 Mod Development
Posted
Yep, folder structure has totally changed to the pre-release format
Folks with the older version now get two part sets, since I did not want to trash saves. Folks will of course want to clear all of this out when it goes release.