Jump to content

DStaal

Members
 View Profile  See their activity

  • Posts

    4,001

  • Joined

  • Last visited

 Content Type 

Everything posted by DStaal

  1. DStaal
    @Trann - Do you see the issue with a newly designed and launched craft? (Not just newly launched - one you've put the telescope on after you installed the mod.)
  2. DStaal
    Wild Blue Industries - Angel-125's group of mods: MOLE, Pathfinder, DSEV. I think DSEV is the primary place for the new fuel switch.
  3. DStaal
    Note that the Brumby is a 1.875m part, which is not a stock size. (Stock is 1.25m and 2.5m.) It's a very *common* mod part size, used by a lot of other mods, but it's not quite the stock size. And if you do prune out parts I'd recommend keeping the Mk1 docking port and the Flight Control Package as well - the three parts together (along with the Mk1-85 heat shield) form a balanced unit for RCS and have full landing parachutes as well as docking.
  4. DStaal
    If that's all you want, have you looked at this mod: I believe it's working, and while it isn't quite as nice as the Brumby, MOLE is more than just a parts mod so trying to pare it down enough for just that part is going to be a lot of work.
  5. DStaal
    *imagines a huge Kerbal bicycle roaming Minmus...*
  6. DStaal
    Better than your GameData would actually be your log file - It should have exactly where the patch is and what's triggering it.
  7. DStaal
    Hmm. I wonder, on slow-rotation bodies it might be better to do one orbit on a 90º inclination, and then lower the inclination to something like 80º. (Or whatever will just touch the area in the polar scan.) That way you wouldn't be dependent on the body rotating under you as much.
  8. DStaal
    But it doesn't change patched modules. I don't know where you're thinking it does. All it does - from reading it just now - is add modules and resources to the parts. Technically, the order it's applied in doesn't matter at all - as long as the part exists in the KSP database, MM can make the additions the patch requests. And even if it did your change is wrong. You remove the conditional (the NEEDS), and put in a non-sensical ordering block ([KSO|USILifeSupport]). If the order mattered, you'd want it to conditionally apply when USI-LS is installed, and after whatever patches where being applied. Let's say that was in USI-LS - then you'd want something like :AFTER[USILifeSupport]:NEEDS[USILifeSupport]. Which would imply it was after KSO, since 'U' is after 'K' in the alphabet. As far as I can tell, you're wrong on every single level here. I honestly don't know what you think is going on in that patch. Now, from reading right now there does appear to be one typo in the patch which is probably throwing errors: There's an extra 'MODULE {' (with a newline in between) in the first part, which is never closed so that's probably throwing issues. The resource addons for the station power module probably don't work as well. But there are no 'edit' lines in the entire patch - just 'add' lines.
  9. DStaal
    Right. None of that impacts NEEDS, as NEEDS doesn't affect the order the patch is applied in. (Well, the last three are what *triggers* a NEEDS patch to be applied.) Moving the patch from FOR[KSO] to AFTER[KSO|USILifeSupport] does two things: No longer defines KSO as a mod in this patch. (It may still be defined someplace else.) Shifts when the mod in applied to later. (After KSO or USILifeSupport.) Which will probably be *much* later. Now, if the patch needs to be changed from FOR[KSO] to AFTER[KSO], I can see that. Not that I think it's necessary looking at the patches, but I could see it being something that could happen, if there were patches being applied to the parts during their creation that would impact this patch. But the patch should still be conditional on USILifeSupport, which your adjustment removes. And really, AFTER[KSO|USILifeSupport] is kinda dumb - KSO is always before USILifeSupport, so either you want it after one or the other.
  10. DStaal
    I watch that thread. I haven't seen *anything* like that. The latest does throw errors if you have multiple of BEFORE/FOR/AFTER, but NEEDS is a different thing altogether. And removing it would remove fully three-quarters of the usefulness of MM.
  11. DStaal
    Why? That completely changes how the patch applies, from being conditional on USI-LS to always applying, and applying later than it did before. The current syntax should be ok, from your statement here.
  12. DStaal
    That's likely out of the scope of this mod - there are some precision engineering mods to help place parts preciously (which is what I think you're asking for), but none that's pure numbers that I know of.
  13. DStaal
    Turns out I was mis-remembering things a bit - top speed for a Bussard Ramjet is 0.12c. (The speed of the exhaust velocity.)
  14. DStaal
    That's not the problem. The problem is the breaking means it's only useful to something like 0.6c, which isn't all that fast. Past that you aren't going to be gathering enough propellant to offset the amount of energy you have to spend to collect the propellant. You can spend the mass on propellant and go faster, for less total mass/cost in nearly all cases. I think there could be a niche for exploration ships who went on long trips where they couldn't be sure they could refuel, and would just buzz past star systems. But in general it's an interesting idea that's not really useful in the end.
  15. DStaal
    Me, it was more that I got to college and realized the email address they gave me would only last for 4 years. So I went looking for a better option. When Gmail came out later, I'd already been using this address for half a decade or so, and didn't see enough of advantage to change it. But either way, I think we can discount that it's only happening to certain domains. Or if it is, it's at least widespread enough that it's likely affecting a lot of people.
  16. DStaal
    Mine goes to netaddress.com. (I think that's where their receive domain is. My address is @usa.net. Predates Gmail by a bit. )
  17. DStaal
    Well, as far as I can tell I haven't gotten any for a couple of weeks at least - despite some of the mods I follow updating (sometimes multiple times) in that time.
  18. DStaal
    My understanding is that the latest evaluation is that it's feasible - but not particularly *useful*. Basically, because of the drag and breaking effect, there's only a very narrow range of speeds where it would actually be able to power itself, and these are fairly slow compared to other theorized methods of interstellar travel. So, it's actually better in nearly all cases to use some other propulsion method. (Or just carry your fuel.)
  19. DStaal
    Construction ports are already a recolor of the default ports...
  20. DStaal
    Anyone else not getting email notifications when mods are updated?
  21. DStaal
    There are several that *add* experiments that take time to collect: SEP, Station Science, MOLE/Pathfinder come to mind off the top of my head. None of these make the normal science take time to collect however.
  22. DStaal
    Quick note: I see that the version file in the most recent version lists this release as for KSP 1.2.2.
  23. DStaal
    It'd be best to read up on EL for this - the Workshop here is where the work is done, but not where the ship is assembled. For that you need a launchpad of some sort - either a K&K Launchpad, one from some other mod, or a survey station (no part from KPBS seems to have that functionality) and some survey stakes planted via KIS. So you want one or more workshops filled with decent engineers (the more workshops/engineers the faster the build) and then someplace where the build will actually happen. The OSE Workshop should in theory be able to make any size item I believe - if you have a large enough KIS container. Though beware that very large items are hard to handle via KIS.
  24. DStaal
    Per my discussion with TranceaddicT - Try this instead, I believe this will work, and do what you likely actually intend: @PART[jx2LDA]:NEEDS[Kerbalism]:AFTER[JX2Antenna]
  25. DStaal
    You are off. Yes, FOR is part of the ordering pass - but that's *because* it creates the mod in question. So you get patches BEFORE the mod, FOR the mod, and then AFTER the mod. Both of your statements will (attempt) to create the part MyPart all the time. (And will likely throw an error if SomeMod is not installed.) If you want to apply some patch only if SomeMod is installed, you would use ':NEEDS[SomeMod]'. Getting FOR and NEEDS mixed up is the *most* common error I've seen in MM patches, and the one most likely to cause unrelated or weird issues. (As it causes issues in *other* mods which are using everything correctly, but only in the presence of your mod and not the mod you're trying to conditionally depend on.)
×
×
  • Create New...