Tallinu
-
Posts
153 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by Tallinu
-
-
I got several plugins twirling in my mind so forgot that.EDIT: Here goes the part.
Surprisingly simple to make this work. I don't even have Fuselage pieces unlocked, but easy workaround is to put the fairing decoupler modules up in stage 0 so they just won't get fired.
Thanks for this part design!
-
The smelter download only appears to contain the smaller, slower version - or at least, the version it contains is only about 15 tons, which doesn't quite seem like the proper mass for the "half-size" version either...
edit: Well, installing that "one" part file actually gives two, so ignore that bit. The sizes and stats are not what was listed in the first post though. And even the big one seems to be much, MUCH slower than the smallest of the smelters that comes with Extraplanetary Launchpads... While I understand that balance should at least be informed by the real world, you have to remember that converters based on the Kethane mod can't just be "left running in the background" while you do other stuff...
-
What do you guys think of this animation?More coming...
Such animate! Great impress! Very graphics! Wow!
(Very apologies doge.)
Can't wait to update that printer and workshop.
-
Hi, I still have the issue in TCA 1.2 that it overwrites my predefined thrust factor value for each engine (the build in factor). Could you somehow apply your changes ontop of that thrust factor change?
Fabian
One way it could do this is by examining the thrust limiter values when the rocket is first put on the pad, and remembering those as the "normal" thrust levels for each engine instead of always considering that to be 100%. And if the player modifies a thrust limiter while in flight, it would need a way to recognize that and update the stored value. (It might be best for the player to do such tweaks while the plugin is inactive though!)
-
I'm trying to update a KAS config
[...]
and this is my MM config:
@PART[KAS_ContainerBay1]:Final{
!scale
!mesh
@rescaleFactor = 1
@node_stack_top = 0.0, -0.35, 0.0, 0.0, 1.0, 0.0, 0
@node_stack_bottom = 0.0, -0.4, 0.0, 0.0, 1.0, 0.0, 0
@node_attach = 0.0, -0.4, 0.0, 0.0, -1.0, 0.0
MODEL
{
model = KAS/Parts/containerBay1/containerBay1
scale = 0.5,0.5,0.5
}
MODULE
{
name = KASModuleGrab
evaPartPos = (0.0, 0.10, -0.15)
evaPartDir = (0,0,-1)
customGroundPos = true
dropPartPos = (0.0, 0.0, -0.55)
dropPartRot = (-10.0, 0.0, 0.0)
attachOnPart = True
attachOnEva = False
attachOnStatic = False
attachSendMsgOnly = False
}
}It looks like you're trying to do what I just tried to do with the container storage rack, but I found that no matter what attach node I tried, it always sank halfway into whatever I tried to attach it to (part or terrain). Have you had any luck getting it to work?
-
First, it could be that KAS is doing its adding of modules to stock parts after ModuleManager does its own work, in which case even :Final wouldn't let it strip the module off after it's been added. Don't know if this is the case or not.
Second, you can't delete any of those GRAB nodes entirely - they're root level, which KSP makes read-only. There's nothing ModuleManager can do at that level. But you should be able to search for a GRAB node that HAS a certain key/value pair and change or remove the keys from that node.
@GRAB[*]:HAS[#stockPartName[smallRadialEngine]]
(assuming the # is correct syntax) to find the right part, then
{
!stockPartName
!evaPartPos
!evaPartDir
!storable
!storedSize
!attachOnPart
!attachOnEva
!attachOnStatic
!attachSendMsgOnly
}
should remove all of the keys from that part. I don't know how KAS would handle a completely empty node - hopefully it would just gracefully ignore the node and not crash anything, but you never know. If that doesn't work properly, try something like:
{
@stockPartName = asdfasdfasdf123
}
That should create a situation much like where the player has removed the stock part KAS is looking for, and my guess is that KAS might be more likely to handle it gracefully.
-
Those preview renders on the OP and the screenshots you've posted look absolutely wicked, I can't wait to see what you end up releasing.
-
Once upon a time they actually did have the same names, hence the warnings. I've since tried to get rid of all those, but there might still be a few instructions hanging around about not using both parts.
I'm going to leave them with different names though. I want them to remain separate. There are also some issues with the R&D center tech-nodes when you have multiple parts with the same name (that's why I had to change some of my part names). If you end up researching multiple parts with the same name, even if you delete the first version of the part, you can run into problems that will prevent you from being able to actually use the part.
If anyone's worried about persistent file loss though, you should check out my backup generator, it's in the bottom of my signature.
I believe that instruction is a file in the zip. The replacement folder's structure was also identical, which would cause the part.cfg file of one version to overwrite the other (as well as the model and textures). And I'm not surprised that installing more than one part with the same name would lead to problems. Computers don't tend to like that very much (unless designed specifically to work around it).
Why would anyone intentionally do that?If you intend for people to install both versions of these parts simultaneously (if they want the scansat-enabled part), I'd just like to say that's pretty much the opposite of how many people are trying to trim their part count and assets loaded to save memory and keep KSP from crashing so often... At the very least you could have the models and textures only exist in one location and have both parts reference them in that location instead of each one containing a duplicate of them (the game loads both, even if they're identical). I still think it's rather silly to install both versions of a part like this though, and I'm curious what your reasoning is on that.
Don't get me wrong though, I love what you've done with these parts - the models are great, and I'll happily use any and all means of getting extra science out of my missions (especially when they're real-world instruments that KSP lacks).
-
The SCANsat parts have different names so they will have to purchased separately at the R&D center and won't affect existing crafts.
When I first installed this part pack (this was prior to version .7) I installed the scansat version of the telescope, because I had scansat installed, and expected it to have "more features". I added your telescope, magnetometer, and RPWS to a pre-existing probe design that had all the orbital scansat parts and launched it. I quickly discovered that the telescope had only the scansat functionality. Since that was utterly redundant, I removed that version of it and put in the non-scansat version, restarted KSP, and it promptly deleted the probe I'd launched.
Luckily I regularly make backups of my persistence file, so I just restored it. I then opened up the part.cfg files for the two versions of your telescope and discovered that for some bizarre reason you gave them different part names despite instructing us to install only one or the other, not both. So I had to edit my persistence file and replace "dmSCAN" with "dm" on the telescope part name for that probe.
Are you under the impression that using the version of the part.cfg file that has the scansat module listed would cause problems if scansat wasn't installed? In my experience, unknown modules are simply ignored and cause no issues (unless the part requires the missing module in order to function properly). So the only reason I can see to provide two versions of the part.cfg files is for people who have scansat installed but don't want its features to appear on your telescope and anomaly scanner.
And there's nothing wrong with providing that choice; however, the two versions of the parts should not be given different names. Doing so prevents you from swapping between the versions without losing craft in flight and becoming unable to load up saved craft that used the "other version" of those parts. For example, if I had your dmSCAN telescope installed, but decided to remove the scansat mod (perhaps I wasn't really using it and wanted to trim down KSP's memory footprint), I couldn't switch to the non-scansat telescope without either losing any craft using it or editing persistence and/or part.cfg files to make the names match up.
Another way to offer that choice, without requiring two different part.cfg files, is to provide a module manager .cfg file to insert the appropriate scansat module into the part.cfg for the telescope and anomaly scanner. If the user wants the scansat features on those devices, they simply copy in that .cfg file as well as the parts - and they could easily add or remove it at will if they change their minds. Since the part names don't change in this situation either, no craft will be lost/inaccessible.
This is all you would need:
@PART[dmAnomScanner]
{
MODULE
{
name = SCANsat
sensorType = 32
fov = 1
min_alt = 0
max_alt = 2000
best_alt = 0
power = 0.1
scanName = BTDT scan
}
}
@PART[dmscope]
{
MODULE
{
name = SCANsat
sensorType = 24
fov = 4
min_alt = 5000
max_alt = 500000
best_alt = 250000
power = 1.5
scanName = multispectral scan
}
} -
To think that a crewed capsule would NOT have the same computing resources as a probe, if not better resources, seems silly to me... Why force someone to attach a probe body on top of every crew capsule just to get access to that feature?
-
The B9 Aerospace pack has swiveling VTOL engines. I think they only have two positions, but they should do the trick if you need engines that change their direction of thrust instead of just building with different engines pointing different directions.
-
I like how you used the structural plates to create fairings for the second and third stage engine clusters.
-
Ingenious!
I notice that one drawback of this is that the navball is inverted. You could probably solve that by adding a small remote guidance unit, right-side-up, to the 1 meter stuff on top and using 'control from here' on that, then switch to IVA view. Not sure if it would reset the control location when going IVA...
-
This folder structure change will be a good thing. People shouldn't quibble about how horrible it is to have to learn where to put things, especially since it's really a very simple and straightforward change. Once mods are updated, it will be much, much easier for players to install or remove specific mods in their entirety.
In .19 you had to put in some cases three or more different folders in different places, and if you wanted to remove the mod, you'd have to know exactly which folders were added by that mod and remove them one by one, leaving other folders alone.
Now you'll be able to drop a single folder into GameData, and if you want to remove it, you just delete that one folder. No hunting around for where all the components of the mod went, because they're all bundled together in one place.
"Another thing that would be useful" is for people to stop assuming that they can just update the game and have all their mods continue to work as they did before, and complaining when instead it breaks their saves and they can't build ships properly and they've lost everything because they didn't even bother to make a backup. Show some common sense, please. Updates can break things. Make backups. Install new versions to a separate folder. If things don't work right, have patience while the mod authors update them.
-
Catullus, All good here from inventory standpoint.
Tallinu, your mod to the KWR service propulsion unit has a typo... 0.1 instead of 1.0. Otherwise no issues found. I was plunging into the cfg's for all components when I saw your post. I guess you have faster fingers than I when it comes to typing/cutting/pasting.
Wups, you're right. The scale was originally set to 0.1 in most of the engines. I must've missed the fact that the SPS didn't have scale set and just pasted in the same thing I pasted for the other engines. Thanks for catching that. I'll update the download in a minute.
Done. Same URL for the download:
https://dl.dropboxusercontent.com/u/203721/KW-Unofficial-.20-Fix.zip
-
https://dl.dropboxusercontent.com/u/203721/KW-Unofficial-.20-Fix.zip
Instructions included. Hope this helps.
-
I'm currently testing some changes I've made to the KW Rocketry part files to correct this issue. So far it's looking good. I'll post it soon unless the author beats me to it, heh.
-
Semni, the problem with the probe part is very simple and easy to fix (I just solved the 'anchoring' and blanked-out orbital information window for myself).
You have in the part.cft two MechJeb modules: MechJebCore (good!) and MechJebAR202 (Not good!) Remove the second one. Your part doesn't have the AR202 features, and the AR202 module apparently breaks things when applied to such a part.
Also, on the nano-probe, you've left out the electrical consumption rate. I'm not sure if you meant to leave MechJeb off of that one, but it's not there either.
Regarding your post earlier on this page, the existing fuel tanks seem well balanced to me - the stock 1.25m tanks of the same length have the same amount of fuel, so I don't see a reason to change that.
And one more thing: On the parts where you have panels, the panels only cover the wide sides, not the narrow sides... This is sad because those narrow sides would be perfect for mounting RCS thrusters and caseless solar panels and the like, but placing them there makes them appear to be floating, disconnected. Just a thought.
Blue Goblin, that 2-1 adapter and the open bays look awesome! I have now added those two to my collection.
-
I love the look of that "TriStrutMiniTank" part you posted the screenshot of. But is it just the angle, or are the tanks 'floating' inside it, only connected by their fuel lines?
Glad to hear you're including a second version of the hub connector part. I need to try this latest version out!
-
MODULE
{
name = ModuleFuelTanks
volume = 400
RESOURCE
{
name = LiquidOxygen
amount = 3600
maxAmount = 3600
}Assuming the TANK configuration above, MaxAmount = 3600 will create a tank that takes up (3600 / .995) = 3618.09 of the available volume
I'm confused. You seem to be saying that you can put a fuel volume of 3600 units into a tank that is set to only store 400.
-
Inside your KSP folder, you'll find them in PluginData\subassemblyLoader\subassemblies - go in there and delete the stuff you don't want from the lifters folder or wherever it may have ended up.
-
This looks awesome. I hope there will be versions that can be side-mounted like the current rover wheels - I can't quite tell if the ones in the picture you posted are a single unit or just left and right track placed close together.
Also, I'm assuming these are electrically powered like the rover wheels, right? Is the sound playing during the video supposed to be an engine noise? That wouldn't make much sense...
-
Synthesis:
It's not quite that simple. MechJeb2 is a part module, whereas the original used a variant of the command pod part type.
To turn one of the original parts into a MechJeb 2 part, you'd need to add the MJ2 part module to it at least, and possibly change the part type to a normal command pod (I haven't actually experimented with this myself, though).
-
It does now, heh. I discovered after playing with it some more that top and bottom HAD to be the last two lines in order for it to work right. And then the forums went down before I could edit my post.
I made a copy of the part with a different name and description, so I could use both, and made this odd looking upper stage with it:
The modified one is in the center, with four of the original version at the other intersections. This wouldn't be possible with only one version of the part.
Here's the full launcher, kind of a slapdash design:
I used the THSS decouplers and mounting panels for the SRBs. There's no way to see which side of the decoupler detaches though, and I got it wrong the first time, leaving them attached to the ship. One option would be to make them work like the stack separator type of decoupler, where both nodes disconnect... Or like the stock radial decouplers that split into two parts, one bit staying on the ship and the other stuck to the detached section.
Oh and here's the full part.cfg I used if anyone's interested (just copy the folder, rename it to TriStrutSplitterRot and replace the contents of part.cfg with this):
I got several plugins twirling in my mind so forgot that.
[1.2] Procedural Fairings 3.20 (November 8)
in KSP1 Mod Releases
Posted
Yeah, three "stages" per separation, with it set up that way. It makes for really awesome looking designs though. And I'll certainly switch to fuselage pieces as soon as I get enough science to unlock them!
I think I had auto-struts on, but I'm not sure if they're actually working. I have KJR installed, if that makes a difference. I kept having a problem with the second design you showed where it wouldn't stay attached as soon as I went to launch the rocket - the connected floating nodes would apparently just instantly detach from each other, leaving all my stages below that still listed on the left but empty of modules and most of the craft sitting useless on the pad below what remained of it.