Apaseall

Members
  • Content count

    198
  • Joined

  • Last visited

Community Reputation

34 Excellent

About Apaseall

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Enable
  1. Apaseall

    [1.4.2] Interstellar Fuel Switch (IFS) 2.13.3

    I would be thinking of this approach; A . Work out which tanks you want to have what contents management. Use that to instruct you on how to write the first piece ie @PART[filter]:HAS[morefilter] I would be thinking of using :FINAL to determine when the patch runs. As to the internals of the patch I would be thinking along the lines of !MODULE[SomeContentsManagerYouWantToRemove] Then add IFS which I am guessing is MODULE[InterstellarMeshSwitch] and MODULE[InterstellarFuelSwitch]. You would have to feed in a value for RESOURCE[LiterVolume]. You could then delete fuels etc that you do not want to see from MODULE[InterstellarMeshSwitch] and MODULE[InterstellarFuelSwitch]. All of which sounds like a pita, but once you have worked out which fuels you want, you merely have to get the filter to target the right parts and job done. That is to saw that you only have to do the fuel picking once, but can then apply that to as many parts as you like. B. If you went with :BEFORE[B9] would that mean B9 would behave like IFS in that B9 will not add its contents manager to a part if the part already has IFS ? Am I barking up the wrong tree with this? Have I made some assumptions that are plain wrong? edit You would need to pick up the contents from the part so you can work out the right litrevolume. A little math, litrevolume = (amount of lf / a value ) + (amount of O / a value ) + (amount of mono / a value ) etc. Oh and watch out for zeros. Unless there is an easy way to pick up the max amount. You see what I mean?
  2. I wonder what happens if we take a craft file from 1.3.1 and put it into 1.4.2. Would it error? would be default or black?
  3. So with the changes to 1.4.2 do we need this mod anymore? Or if we do, will it work in 1.4.2 ?
  4. @blackrack If you are about take a look at scatter maybe you can see if this is something that needs attention or not: In: https://www.dropbox.com/s/e9wxe4vvhd0x5rh/saves for Scatterer 0.0329-1-output_log.txt?dl=0 and/or In: https://www.dropbox.com/s/fg8dpk8dgjpgeix/saves for Scatterer 0.0329-1-KSPDev-LOG.180416T133339.ERROR.txt?dl=0 For completeness here are the other files: https://www.dropbox.com/s/u2blr16sj5ouke1/saves for Scatterer 0.0329-1-KSPDev-LOG.180416T133339.INFO.rar?dl=0 and: https://www.dropbox.com/s/k5yjqnrhv525oqo/saves for Scatterer 0.0329-1-KSPDev-LOG.180416T133339.WARNING.rar?dl=0 I have so many logs because I use: KSPDev: LogConsole I write a few patches for myself and thought this might help, as I am fed up of wading through the pile of repeated=useless entries in the ksp outputlog. edit. Oh and whilst I am asking stuff, I notice that quite often when I launch from the runway, everything is as though looking through a grey haze. This is not what I was experiencing in 1.3.1 so I noticed the difference. Also it does not happen all the time. It is sort of nice, but very heavy, a think if it was a little thinner it would have me less inclined to want to scrub the screen to clear the mist edit. I am not sure if this is related but: is showing this: I got up to 3.3K hits in roughly 50s of kerbal flight time with a maximum of about 3.8 ThrowsPerSecond. All these are for the same flight. The logs are from early in the flight. Hope these help.
  5. Apaseall

    ExceptionDetector 1.1 [KSP ANY VERSION]

    Can anyone confirm if this mod works in 1.4.2 or even 1.4.x ?
  6. I am not certain about when the parts are loaded. With the :AFTER[] I am more concerned with the modules of the parts, the internals. I would rather explicitly command a patch to run at a certain point rather than rely on implicit ordering. I guess it might be one of those areas where the same thing can happen if you do or don't write a bit of code. Sometimes working out if you really need to write one thing or the other thing when both get you to the same point can be rather bothersome. I took the plunge and said to myself, 'hey if in doubt, tell it, rather than let it work it out for itself'. As you say probably no harm done, a little more work for the processor. But that work takes place once, before the game really gets going, by which point the results are in the cache right?
  7. That looks about right. Personally I write stuff like :NEEDS[KerbalEngineer&KSO]:AFTER[KSO] I do that because I am stating that I need both mods and then do this think to it after one of them. However bear in mind that mods are processed in alphabetical order. This has relevance when you name your mm patch. For example I name mine something like 'modname_doesthisthing' i.e. DSEV_TweakScale. I put all my MMs in one folder, my_MM. What does that mean? well it means that I have to explicitly tell the patch I write, inside the patch itself, exactly when to run. For example my patch might get loaded before any of the mod it works on are loaded. So I put all mod names in my :NEEDS[]. As for when it runs, that is what the :AFTER[] is for. Or at least that is how is tell my patches when to run, unless I am using a variable, but that is not within the scope of this reply. Since KSO comes after KerbalEngineer alphabetically, running after KSO should do the trick, whereas if you had written :AFTER[KerbalEngineer] things may not work as expected. Hope this helps and if anyone spots something that I am doing or advising to do as being incorrect, I am more than happy to learn.
  8. Apaseall

    [1.3] Procedural Wings

    Sorry got to say that my mileage varies from what you are describing. I have built quite a few space planes. I am new to using this mod though. Mine take off about 200 m/s. I tend to use little wing area, so need the speed for the lift. I also go very fast horizontally. But this is beside the point. Building a space plane [SSTO] like how I have without this mod, causes the wings to rip off. This is because of the massive weight of B9 HX parts. I use KJR, tried rigid attachment, autostruts, extra struts, reinforced struts etc. Not all at the same time, one after the other etc. Then all etc. Normally I don't need to mess with that sort of stuff. Now fiddling with CoL CoT CoM, boy have I done lots of that. lol. I just wanted an answer to my question, not help with designing the plane. Thanks for the offered suggestions. I know you meant to help. I only wanted to know, well the stuff I asked about. For the moment I have ditched wings altogether. Not a plane anymore but vtol. This is not meant to be rude to you, despite how it may be worded. But what you mention does not answer the question I asked.
  9. If your patch is written badly, it will not be applied and a cache file will not be generated. Each time modulemanager works correctly, ie no errors in patches, it creates a file called ModuleManager.ConfigCache in your GameData folder. Try making a copy and deleting the file. Then run KSP and if you have errors in patches, no new ModuleManager.ConfigCache will be made. KSP is a little odd that one error in one mod can cause other errors in other mods. Sometimes it is tricky to find the first error. My theory is, squash all the bugs lol. I have not bothered to download and read the files you kindly linked. I am just commenting on what is written here. I am also assuming that it is you that is writing the patch that has the above mentioned errors.
  10. I would suggest rewriting in your patch file something similar to :NEEDS[KerbalEngineer]:AFTER[KSO] or :NEEDS[KSO]:AFTER[KerbalEngineer]. Drop the :FINAL and the :FOR[] :FOR is normally used by mod authors. Consider not using it, ever. Unless you really need to reference say [z_KOS] with and :AFTER[] in a completely different .cfg file. That is to say that if in the other .cfg you absolutely need to ensure that z_KOS has run first.
  11. Apaseall

    [1.3] Procedural Wings

    Hello all, I have a question. The base of the procedural wing can have the thickness changed. Does this change the sheer stress experienced by the wing trying to provide lift to a heavy plane i.e. does the surface area in contact with the plane help? Additionally is that 'sticky' part of the wing limited to the part the wing is initially attached to, or do other parts that the wing is in contact with play a part too? I see in the notes something a .cfg file being generated. Is it possible to examine this file? If so where is it located? Or is this merely a reference to the planename.cfg file which is found in the saves directory? I am experiencing wings being ripped from the body of the craft when attempting lift off .i.e. craft is on the runway, speed roughly 0.8? mach, comes to end of runway, nose pulled up slightly to perform a gently climb. I am using the B9 SH wing. Is there another wing that I might use that has better 'stick to the plane' properties? This is my first time trying to use procedural wings, I thought it might be a good idea considering I am trying out the B9 HX parts for the first time. Thanks.
  12. To answer my own question, read back a few posts, this appears to be the solution: The original question goes something like this; How to write a patch to add additional name value pairs to name5. In this case I am adding support for MOD8 which did not exist or was not supported when originatingMOD was written/updated. I do not want to bother the originatingMOD author, hence writing my own patch. The problem is that in the originatingMOD the node BLAH[Foo] is only created if its own :NEEDS are satisfied. Again MOD8 is not tested in originatingMOD, so BLAH[Foo] is not created for MOD8. Thus depending on which other mods were present, when my patch runs there may or may not be BLAH[Foo]. My solution is to check if BLAH[Foo] exists, create it if it does not and then add the additional name value pairs to name5. The observant will note that this is not a PART. No dll for originatingMOD exists. :FOR is not used in the originatingMOD. BLAH only exists in terms of BLAH[something1], BLAH[something2] etc. BLAH is not a sub node, other than being a .cfg file named BLAHs in the folder originatingMOD. For the curious, here is the ModuleManager.ConfigCache entry: This appears to be of the same format and structure of the preexisting unmodified entries for other BLAH[something1], BLAH[something2] etc. Feel free to tell me if I am making an incorrect assumption, going about this in an inappropriate way or anything else.
  13. Apaseall

    [1.3.1] Kerbal Star Systems [v0.7.3] 11 Dec 2017

    YAY. Still playing 1.3.1 so not a big problem with waiting. Besides maybe 1.4.x will have settled down by the time this is up.
  14. I am guessing that the altitude you mention is a limit for air breathing engines that you are using? Otherwise I would say go higher, as the heating of parts like wings is from air resistance, which you probably already know. Other wise I would suggest looking at other mods that add plane parts. I think the stock plane parts are limited to 2000K. I know some mods have parts that are much higher, as they are meant for space plane builds. You might want to take a look at heat mods. I am not sure which but I think one has plane parts, like tail rudder that are radiators themselves. Not only do they have higher temperature ratings but they actually suck heat from other parts nearby. Hopefully that might bring down your hot spots enough. Then there is plane design, sometimes it is possible to move wings etc back a little which reduces the temperature they experience by kind of being 'in the wash' rather than front line exposed. This does mean sometimes really changing you plane build as moving CoL and CoM by merely sliding the wings etc backwards will hugely alter the performance/handling. @Boris-Barboris I am very happy to read that this works with 1.4.2. I was worried that this would not get updated, as I fly things that are shall we say very tricky to fly without this mod, specifically stuff that tends to pitch up and down at certain air speeds. I am still waiting on some other mods to be updated before I can fly in 1.4.2. But I am happily playing 1.3.1 until they are.