NecroBones
-
Posts
4,820 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by NecroBones
-
-
Just now, AccidentalDisassembly said:
Also, I'm a liar, there is one part that uses mesh switching - the biggest Rockomax tank, just FYI.
Excellent. It looks like everything should still work with the existing part switchers, but it might be good to convert to this where possible. Yikes. I may have a lot to do.
-
Just now, AccidentalDisassembly said:
Take them out IMO.
Also - Huh?
This is from Squad/Parts/FuelTank/RockomaxTanks/Rockomax8.cfg. I don't know how mesh switching would work (because I don't think any current parts use it, so no examples), but...:
Ah, that's my problem, I was looking at the files for the deprecated variants, not the new ones. Doh! Thanks
-
1.4 updates are planned, no ETA yet.
-
Hey all, it looks like those end-caps are still causing issues. Would anyone be horribly offended if I just remove them?
I need to look through my mods and see what needs to change for 1.4. I haven't had a chance to look yet, but I'm sure there are a few things like this that might just be easier to rip out.
I don't see where the stock support for model/texture selecting is taking place in the files, as there's no mention of it in the .cfgs. Probably some naming convention in the .mu. I might just have to ignore that for now.
-
3 hours ago, NSEP said:
Can i make a Realism Overhaul patch for this? (Or at least a Real Fuels Patch) I still have to learn how to make MM patches, but i have alot of free time, and i have nothing to really do.
Anyways, no promises are made here, just an idea.
Sure, feel free to take a stab at it. You might want to check with the RO folks too though.
-
19 hours ago, Ithirahad said:
So, I have this and RealFuels, and all my RSB engines (including the Agena one that specifically says it uses RFNA as an oxidizer) are burning Kerosene and Liquid Oxygen! They also seem to all have infinite ignitions (and no ullage requirements?). Any idea what could be going on?
Last I heard, RF didn't have support for RSB, unfortunately. It seems like it would be right up their alley, though.
-
On 5/14/2017 at 8:17 PM, pap1723 said:
Hi @NecroBones!
We have been working on some modifications to the Realism Overhaul and RP-0 Tech Tree and have a conflict with the modified techs you use with RSB. I looked for a Github of your mod to help by creating a Pull Request, but I didn't find one. Could you please do me the favor of changing the first line of your 0_TechTree.cfg file to read this:
@TechTree:NEEDS[!CommunityTechTree&!SpaceYtree&!RP-0]:FOR[RSBTechTree]Just adds in the RP-0 as a limiting factor as well. Thanks!
Gladly, I have that set up for the next release.
On 4/19/2017 at 7:39 AM, HansB said:I've got those 57 errors also, but in combination with SSTU / optional patches
During the Module Manager patch phase of KSP startup, MM detects 57 errors related to the "0_All" config file. I installed it in an install of KSP with only Real Scale Boosters / stockalike and SSTU / optional patches.
A lot of: Applying node RealScaleBoostersStockalike/Patches/0_All/@PART[RSB*]:HAS[#RSBstock[*rue],#RSBengineType[lift*],#RSBengineScale[*]]:FOR[RSBStockM] to RealScaleBoosters/Parts/Engines/RSBengineF1/RSBengineF1
[LOG 13:27:52.754] [ModuleManager] Error - Cannot parse variable search when editing key mass = #$@PART[liquidEngine1-2]/mass$
[LOG 13:27:52.758] [ModuleManager] Error - Cannot parse variable search when editing key cost = #$@PART[liquidEngine1-2]/cost$
[LOG 13:27:52.763] [ModuleManager] Error - Cannot parse variable search when editing key entryCost = #$@PART[liquidEngine1-2]/entryCost$One of your other mods is probably interfering. the RSB stockalike patches use a few of the stock parts to get some baseline numbers for things like cost and mass. If those parts are removed or significantly altered, it will throw off the RSB patches. I'm not sure what SSTU does to the stock parts.
-
On 6/4/2017 at 7:42 AM, Krazy_Kerbal said:
I'm having the same issue at the launchpad, but I am also using Real Fuels and SMURF in addition to the recommended mods. Would those mods be the reason why my TWR at liftoff is not correct? Ironic, if I assume that my mods are giving it the realistic weight.
It's probably some bad mod interaction somewhere. The mod comes with realistic mass and TWR, using the stock fuels, so if you have a mod that changes the fuels, it will throw everything off. I don't remember if RO has patches for the Sea Dragon, but I think it does mess with the stock fuels. It probably needs a custom patch, but this is typically handled on the RO side.
-
On 5/8/2017 at 0:34 PM, Ithirahad said:
I'm sure it has been asked about before, but any chance of an ITS crew section analogue in all of the SpaceY sizes for shipping entire towns worth of Kerbals to Duna (or Laythe!) in one launch? Ideally they'd come in cylindrical and nose-cone variants similar to the standard command pod and lander can variants.
Some ITS or Duna Transporter stuff would definitely be cool. I'll keep it in mind.
-
On 4/27/2017 at 8:16 PM, maculator said:
So exuse the stupid question, but:
Colorswitching is only possible with fueltanks+ installed?
Sorry for the late reply. But yes, it relies on the textures provided by FTP.
-
On 6/5/2017 at 9:08 PM, emirkustirika said:
pls up to 1.3
As far as I know, nothing changed in 1.3 that would break my mods, since they're just part mods. Of course, this comes with the caveats that you have 1.3 compatible versions of the mods it interacts with, such as Module Manager, InterstellarFuelSwitch, etc.
I'm going to go through and update the version numbers, and we'll see what breaks. That always works, right?
-
Hey all, just a quick note that I'm still here. I'll try to catch up on this thread and my other mods soon. Been super busy lately, and this past week has been just crazy. But I haven't vanished completely.
On 5/11/2017 at 8:01 PM, theaveragepxtseryu said:Getting a REALLY strange bug; all the textures are flickering like crazy. Possibly overlapping textures. Is there a fix for this?
Check out the troubleshooting in the first post. Usually this is a problem with ModuleManager (missing, wrong version, not working with a new KSP version, etc), or one of the model switcher mods not being installed or configured correctly (Interstellar Fuel Switch, B9, etc).
-
2 minutes ago, Sigma88 said:
it would be explicitly defined as in you use FOR for all the patches and they are executed in order
usually I put all steps in the same "time frame" so that if someone wants to do something before or after my patch they can use BEFORE or AFTER
OK, I'll leave it for now. I still use a lot of BEFORE/AFTER in how I do things anyway, but sometimes it's very circuitous by necessity.
Posted:
1.12.1 (2017-04-09) - MFT fix.
- Corrected some MM patch issues for ModularFuelTanks. -
1 minute ago, Sigma88 said:
as long as you put them in the correct order you don't need a BEFORE
Good to know, but the old programmer in me doesn't like to trust things that aren't explicitly defined.
-
Just now, linuxgurugamer said:
Will you have an update out today? Only asking because I'm streaming this evening, and if you aren't, I'll do a local patch
Yep, I'm putting it together now. I'll get that out ASAP.
-
Just now, linuxgurugamer said:
Your nuclear engines don't have Oxidizer, which is causing the problems.
@Sigma88 suggested the following should fix it:
@PART[TPtank*|TPcone*|TPdome*]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks] { origLFO = 0 } @PART:HAS[#origLFO[0],@RESOURCE[LiquidFuel]:HAS[#maxAmount[>0]]]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks] { @origLFO += #$RESOURCE[LiquidFuel]:HAS[#maxAmount[>0]]/maxAmount$ } @PART:HAS[#origLFO[*],@RESOURCE[Oxidizer]:HAS[#maxAmount[>0]]]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks] { @origLFO += #$RESOURCE[Oxidizer]:HAS[#maxAmount[>0]]/maxAmount$ } @PART:HAS[#origLFO[>-1]]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks] { MODULE { name = ModuleFuelTanks volume = #$../origLFO$ type = Default } }Ah! Excellent. That first one needs to change to a "BEFORE" since it's creating the variable, but otherwise that looks good. I'll add it.
-
1 minute ago, linuxgurugamer said:
Ah! Good point.
-
@linuxgurugamer - Another idea I had. It's possible that Modular Fuel Tanks is doing something to the fuels or the tanks before my patch executes. I might need to just move them earlier in the sequence. Is it just MFT that you're installing? I can probably do some testing here too. Just don't have much time at the moment.
-
Just now, linuxgurugamer said:
See this:
For that to be the problem, it would have to be that another mod is removing the Oxidizer from my parts. I would need to see the KSP.log with which parts are erroring out, but the patch should only be modifying tanks that I've given Oxidizer to, and not the monoprop tanks. I could add a check for it, sure, but I don't think it'll solve this for you.
-
@linuxgurugamer, I'm wondering if MM added an error-check phase that executes on the whole sequence before executing, so it no longer likes declaring a variable and then editing it at the same level. Maybe as an experiment you can try replacing that whole patch rule with the following:
@PART[TPtank*|TPcone*|TPdome*]:BEFORE[FuelTanksPlus]:NEEDS[ModularFuelTanks] { origLFO = 0 } @PART[TPtank*|TPcone*|TPdome*]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks] { @origLFO += #$RESOURCE[LiquidFuel]/maxAmount$ @origLFO += #$RESOURCE[Oxidizer]/maxAmount$ MODULE { name = ModuleFuelTanks volume = #$../origLFO$ type = Default } }Notice that it initializes the variable to zero in a "BEFORE" rule, and then only modifies it in the "FOR" rule.
6 minutes ago, Murdabenne said:@NecroBones I've already made a rough edit for the .netkan changes that would be needed - basically add a virtual dependency in place of IFS in the main netkan (FuelTanksPlus.netkan - 1 line change), then add 2 more netkan files (something like FuelTanksPlus-FS and FuelTanksPlus-IFS) to provide the needed and/or dependencies on Firespitter Core and/or IntersteallarFuelSwitch core.
Once I have it checked and tested and it builds the .ckan files correctly, and they are verified (via a local file install), I'll send them to you, so you can check them and then push them at your discretion to CKAN's netkan data repo on GitHub.
OK cool. Thanks!
-
21 minutes ago, linuxgurugamer said:
Hmmm. I went back to the basics. totally clean install.
With FT+ as the only mod, it works
When I add Modular Fuel Tanks, it fails.
It's in your patch, which is why I posted here, but I also just posted in the MFT thread as well
Very strange. That logic should be 100% fine. I do the same calculations in RSB's Stoack-alike patches. I wonder if that would do the same thing.
It also makes me wonder if something changed in how MM does these things recently, that I'm not aware of.
-
19 hours ago, linuxgurugamer said:
Error:
[ModuleManager] Error - Cannot parse variable search when editing key origLFO = #$RESOURCE[Oxidizer]/maxAmount$
edit:
Here are the two lines. Deleting the 2nd line seems to fix the error,but somehow I don't think it is correct:
origLFO = #$RESOURCE[LiquidFuel]/maxAmount$ @origLFO += #$RESOURCE[Oxidizer]/maxAmount$12 hours ago, linuxgurugamer said:Just to follow up, it seems to be something with the Oxidizer, I tried just having the resource for the Oxidizer, but it still had errors on that line
I don't know why it would be failing there. The variable is added, and then edited. This logic works pretty much everywhere else. Unfortunately the log isn't much use, since it's pulling cached copies of everything. I would need to see a log generated after deleting MM's ConfigCache file. In fact, stale cache data might be the problem (I've seen things like that before).
Do you have anything modifying Oxidizer? Like removing it as a resource? Otherwise, I can't imagine why it would fail on that.
11 hours ago, Murdabenne said:Hmm. In that case the CKAN info needs to have the alternative dependencies changed. I recall seeing this a couple years ago, and I remember attempting a complex hack in the netkan file to allow a multiple choice mod requirement ("must have/choose 1 from this list" type of thing.) It wasn't on this one - I don't remember which one, or even if I ever got it to work. Maybe it was never resolved.
Anyway thanks @Nightside - now that I know this is viable with just FS, that makes it a CKAN issue not a FTP issue. I'll take this over to the CKAN thread.11 hours ago, linuxgurugamer said:Take a look at the KWRocketry netkans, they do just that
The funny thing is that when this was all first getting added to CKAN, they preferred to keep it simple, and list only one prerequisite out of the set. FTP does indeed work with Firespitter and/or IFS, so the netkan can probably be improved. I don't have the time at the moment to dig into that, though. Mostly the CKAN folks handle all of the metadata, but I sometimes helped it along by adding my own.
-
On 3/4/2017 at 7:54 AM, ParasciHHO said:
It's quite an amazing mod for me but I find that the volume of tanks is too small, even smaller than the 5m tank of KW rocketry. It se ems that the MFT file is compatible with stock game instead of Real Fuels, so is there any existing patch for RF or will it be updated to be compatible with RF?
There's a RealFuels-like component in Realism Overhaul, but not for Real Fuels itself. For the realism mods, I let them handle it on their side. They simply never added support for RSB.
9 hours ago, MaxL_1023 said:Any chance of making a "Roc" engine? It could be 5m in compact configuration (basically an upscaled Emu) and be an F-1 analog for the 10m base - the F1 was 5.5m or so originally.
"Roc" is a legendary, giant bird supposed to be a huge-cheeks ostrich-type, going with the ironic naming tradition.
Always possible. Heh
-
20 hours ago, Laguna said:
I have a favor to ask, could you add (or modify) a decoupler (just one size) that is truly hollow (i.e. no colliders) on the inside to match the visual appearnce, much like the Mk1 Structural Fuselage? I have use for such a thing as an interstage (with appropriate scale changes), and with the mesh-switching capability I could make all sorts of matching interstages.
As you may have guessed, I found out the hard way that the FTP decouplers are not actually hollow.
Updated.
1.12 (2017-04-07) - Tweaks & Fixes.
- Corrected a typo that was preventing the B9PartSwitch patches from applying correctly on the radial tanks.
- Slightly increased the performance of the 2m/3m stack decouplers, and increased their propellant maximums.
- Changed ModularFuelTanks config to use consolidated wildcard patch.
- Removed "cryogenic" tank type assignments from the MFT configs.
- Stack decouplers in sizes 1.25m, 2.5m, and 3.75m collider updates, now actually hollow.
[1.4.1] Color Coded Canisters 2.0.1 (2018-03-14)
in KSP1 Mod Releases
Posted · Edited by NecroBones
Thanks! Yeah, I've been away for quite a while. I definitely want to get my mods fixed up for 1.4 though. Some preliminary testing has the new stock mesh switcher working on one of my FTP tanks, but it breaks the flag decals. Of course. The good news is that I can use the mesh switching configs to turn things off altogether, such as the end caps, but sadly I may also have to just switch off the flag decals for now too. Unless someone has already worked out a solution to that. I've been a bit out of the loop.
EDIT: Interesting, the flags don't break completely... they fail to load at first, and then if you change the flag in the VAB, it updates on the model. But then fail to load again when you start a new flight. So I guess the mesh switcher takes precedence over the flag decal module.