zer0Kerbal

got a little sidetracked attempting to recompile an old mod. still got a little work done on OT. after get some sleep will ask a couple of questions then work on OT and push the changes. KIS - think that should be made into an optional patch (default = off).

Dusting off the old compiler to try to fix an old mod that I really like. It has been over a decade since I touched programming. Asking for help. Have the following installed (and linked up) : VSCode (with c/c++/c#; coderunner installed) : Unity 1.3.1f ( @JPLRepo says here that " Unity 2017.1.3p1 " but can't find that specific build/release) : current version of parttools, although I don't think that is needed to compile a .dll : dotnet v4.7 --- project is https://github.com/zer0Kerbal/KSP-SimpleLogistics not compiling - error messages targeting .Net v3.5 (if I understand that is the correct version for KSP) - and spent hours trying to install it, finally dusted off some old Win install CD's and installed from there. scratching head. Do I have to uninstall the current version (which is the current version) and reinstall 3.5? can both be installed at once? (I believe so) - am at a loss

thank you. works great. exactly what I've spent the last two hours working on. Now I just need to figure out how to do this for myself. (the recompile) certainly feel way old - trying to get things to line up to recompile in vscode. *sigh*

KSP 1.7.2 with MH and BG - log is spammed with tens of thousands (if not more) of the following: [EXC xxx] MissingMethodException: Method not found: 'UnityEngine.Texture2D.LoadImage'. SimpleLogistics.Core.OnGUI () This is without and with @Usgiyi's 1.4.5 recompiled .dll Love this mod - hope it continues to live!

toolbar, toolbar controller, and now unBlur.

three dependencies now. +unBlur.

but, yeah.

doesn't MJ have similar in its maneuver planner?

afterburner - or different naval (and cavalry) approach - the old diesel subs (and all diesels) - when they needed extra oomph (WWII and so) the engineers would cut the diesel with whiskey (thin it out), and on land they would add napalm or even dissolved explosives. gave them 10-30 extra hp, but cut their MTBF in half, and sometimes just melted them. Also remember, these are multimode engines, so when the LF runs out - it has MP to run on, and or to cool them down. agree. Tugs have torque. they are meant to be able to move really big things albeit slowly. they aren't speedboats, and certainly not atmospheric. Think of them as being low Thrust, but high TWR and ISP - in vacuum. I am unable to at this moment to come up with a better way to explain. The extended engineonArm allows for more leverage with the engines good gimbal. The biggest disadvantage to the OT is the lack of fuel capacity in my opinion, hence why they are yardbirds.

thought you would say 2001, Dave: I can not do that.

KML seems to have done 1/2 the work - and it is outside KSP - maybe that would be a starting point so don't even have to start KSP at all?

I did create two optional nodes on the engineonArm - one above, one below the attachment node - was thinking about radiators - but would need a smaller, curved radiator to fix flush. on the other hand, the model does have things that looks like radiators on the actual engines - plus on another note the model shows fuel tanks, so was thinking of putting 50 units of switchable space there (LF/Mono or if KSPi installed - some LH2).

storage area? maybe turn off the MM_KIS.cfg - and the bays will show back up. tweakable in what way? now's the time to suggest things - while we are still neck deep in code and patches. You want moar nodes? moar power? moar engines!!! (although in RL tugs often are all engine - with massive torque and sheer, raw, overwhelming horsepower)

thank you. will try. two feature requests: 'static' or 'default' mod that stays put between saves. add option to include "-mmdump" to command line.

agree. will not include B9 and AYA et al. no - the 1% is for bugs and suggested changes etc.

so there might finally be a use for KIS:funpack:TACOs?

thank you for the great conversation. I'm still a novice beginner at MM patch writing, and as much as I'd love to read all 260+ pages of this thread to compile a updated wiki, I don't have the time nor the attention span to do so. (I have rockets to spectacularly blow up. ) no need to apologize. ModuleManager patch writing is often confusing. let me clarify: My best practices. Hard to explain why I like having that seemingly extraneous bit of code. I like it because MM discards the codeblock's originating line (the @MODULE[ModuleThat]... but will keep the @name = ModuleThat. Call it personal preference, that I suspect has value. I do agree on that. My personal best practices though is slightly different. yes and no. first I always place the :NEEDS before the :FOR (oops) I believe that this doesn't defeat itself, rather it removes ambiguity and therefor removes chances to confuse ModuleManager or make a mistake. Yes, you can have a :NEEDS without a :FOR and a :FOR without a :NEEDS - This is allowed and is lacking in preciseness - or rather lacking in specificity. My best practices [WIP] says Specificity is desired; which in this case means always having a :FOR on all patches; so even though the NEEDS is present, the FOR is also since one is a limiting factor and the other is a timing factor. We always want to control the timing, but don't always need a limiting factor. Another way of saying this is :NEEDS[x] only says that [x] must be present in order to process the patch or codeblock; while :FOR[x] says when to process the patch or codeblock. I really should define codeblock vs. patch. A patch is the entire patch (obviously) starting with @PART or @xxx and contains codeblocks. Codeblocks in this instance is defined as the originating code line and the {} belonging to it that resides withing a patch. On a side note, am working on adding a little bit of debug code to my personal patches - so within every code block there are two cut-and-paste (boilerplate) code snippets. I will define dBug in a file named myModConfigs.cfg This will only show up when turned on and when the command line switch "-mm-dump" is present. Its a work in progress - but will show who/what/when patches have modified a part. By doing it this way, a chronological order can be established as well for use in forensical bug swatting. I was just told about the & operator in a recent request to help with a patch - I now use it with codeblocks instead of most :HAS[!] or :NEEDS[!] & for Add only - which makes it very handy and very practical. makes me wonder what else is missing in the docs?

and I thought I had read the thread. my bad.

they need tacos!

some experimentation might be good concerning drag.

HAS/NEEDS are limiting factors, not timing factors. in order to address best practices, there should always be a timing factor, and if FINAL is essentially worthless because every Jeb, Bill, Harry, Frank, Bob, Rob, Job, Val is using it.. so just saying that if one is say putting on a TweakScale patch, that would be a :FOR[TweakScale] time - and yes, reserved for Mod Authors as well. Without a :FOR - there can be no :LAST,FIRST,AFTER if I understand correctly. So I for one will always put a :FOR because that is my best practices. In fact I am going back and effecting this change retroactively on all my patches. Concerning the @name =ModuleCommand after @MODULE[ModuleCommand] does do something, it acts as an anchor - plus best practices says that always having it is less confusing than sometimes having it. Yes making sure that every line starts with a @#%& et al is important to me for best practices - since there is no ambiguity and exiguity to Module Manager in what you want to it to do. Probably not making sense, need some sleep I do. do have a query: so if one were to write a patch with the following in it: &MODULE[animateKerbal] { lefthand = raised } would MM process anything after the & (create only) if there was already a MODULE[animateKerbal] present? I am thinking not - but thought would ask.

take my KerbalCredits! also - Precise Editor allows for similar. Still - stock best, and PrecisePAWS like @severedsolo shows, am all for that.

I give permission to @Geonovast to use the node patches I have provided, and changing the license to match the one he uses. and yes - NodeDazzler is a pretty cool name. think I will work on SmartParts next. (KIS/KAS/TACSD) SmartParts done. on git and DM.

thank you. it is working now. full patch (specifically for OrbitalTug) *faceplant* thank you. missing left brace (faceplant) missing@ (faceplant) the @PART (according to this thread) is syntactically correct reference to all parts, and I believe was the preferred method to @PART[*]; however I agree that in light of recent revelations we need to start following a set of 'best practices' and specificity is one of them. so @PART[*] win vs. @PART. :Final is overused. everything gets a :FINAL so :FINAL really means not much. Best practices in my humble layman opinion should always see a :FOR clause on all patches - even it is just :FOR[_Me] which if I understand correctly will be processed very near last. agree on the !CONTROLPOINT the extra % (add or edit) &(Add only) are there to handle any possible duplication. since this can only &(Add only) - it cannot create additional copies - if I am making myself clear. agree it would look strange on a plane cockpit - and quite confident some brain will figure it out. part of the expanded plan for this is to handle those situations we have all been in where we slap a probe core onto something and launch it - only to discover it is backwards, upside-down, or even sideways.

my plan for this week is after @linuxgurugamer pushes the next release is to start merging my patches into the part.cfg's. Want to wait until then - then will use -'-mm-dump' to capture the nicely formated parts and upload those. (stripped of unnecessary things). KAS and so on.