Jump to content

[1.12.x] Near Future Technologies (September 6)


Nertea

Recommended Posts

17 hours ago, linuxgurugamer said:

CTB, if used, is a required dependency.  It also would pull in and require the Toolbar Controller..  While it would be extremely easy to add, (and I'd be happy to do a PR for you) if you are concerned about dependencies, it may not be something you would want to add support for

Hmm yeah that's why I have avoided in the past, I only take dependencies I don't run if I really, really need them and this case isn't something major like that. 

On 9/8/2021 at 7:07 AM, Araym said:

I'm here (probably again) to report about the little "bug", not only from your mod, but anyone adding some "Custom Part List" file:

each time the game is loaded, the game add a new istance of the list: I'm ending with dozen of your your mod category, after a while...

As "ModuleManager" is basically an hardcore dependency for many of them, I think that could be more "friendly user/coding etiquette" to add some MM "logical command", if they could work, alike "@"(edit) or "%" (edit-or-create) or something similar (I'm not very MM capable, aside basic modification-usage) to just updating the same category and part list, rather than use the actual "plain version" that had the issue to add multiple one, one for each time the game is loaded...

Dunno if MM can handle it, because the stock cfg file is updated/reloaded on the fly, like  saving a craft, each time VAB or SPH is exited, but if it could (it's just needed once, at game start), that should easily solve the "duplication bug".

Each time I had to hunt down wherever one of those file is placed/named, as not every modder has an unique way to name the corresponding cfg file.
(If MM is unable, at least put it in some "Extra" folder, out from the main one that goes into the "GameData" one, to let the user know that it could be used, but also it could lead to some "issues")

So I don't generally provide this. Can you point me to where I have provided this? 

On 9/4/2021 at 3:08 AM, Skytreker said:

I have a question. Why did all magnetoplasma engines remained more or less the same over the years but my favorite VASIMR VW-10K has had its ISP reduced almost 3 times :o? From almost 18 000s back in the day to 6000s now. This isn't a minute change. It sucks big time since the VASIMR was the main reason I started using the Nertea mods.  :sad:

If you're going back many years you may be thinking of the Ar/LH2- running VASIMRs which were changed to AR/Xe in order to provide a more coherent experience

Link to comment
Share on other sites

So, because I'm an impatient girl, I kinda wanted to try using NFT Construction in a new save. At a glance, the docking ports work (just, no rotation, because duh - but for many (all) of them it wouldn't even make much sense I think? Also, I only tested the square ports on the ground with hacked gravity) - would I be massively screwing myself by using it?

Obviously, warranty entirely voided if I go ahead with  it :D

Link to comment
Share on other sites

19 minutes ago, ModZero said:

So, because I'm an impatient girl, I kinda wanted to try using NFT Construction in a new save. At a glance, the docking ports work (just, no rotation, because duh - but for many (all) of them it wouldn't even make much sense I think? Also, I only tested the square ports on the ground with hacked gravity) - would I be massively screwing myself by using it?

Obviously, warranty entirely voided if I go ahead with  it :D

The Dockingports from Nerteas Mods should support rotation except the not circular ones e.g. the linear or square ones. They only snap into fixed orientations. All others should be twistable. But I haven't used/tested every circular one. You should be good, if you use it. Happy building!

 

Edit: As of Near Future contstruction I'm not sure if the circular ones already are updated to support 1.12, as the OP still says for KSP 1.11.

@Nertea

Edit 2: Checked on github. The circulare ones from NFC are not yet updated, as the last compiling happend before 1.12.  Don't know, how the behave in 1.12 when docked to a new-rotational poet. ....maybe stay a while away from using those. 

Edited by Rakete
Link to comment
Share on other sites

4 minutes ago, Rakete said:

Edit: As of Near Future contstruction I'm not sure if the circular ones already are updated to support 1.12, as the OP still says for KSP 1.11.

I'm fairly sure they wouldn't be, because yeah, it's not been updated, with a note about requiring docking port surgery. I was just wondering whether the issue is "lack of a feature" or more like "totes broken, just didn't show up in a quick test."

I also didn't want to @-mention Nertea, because I'm anxious enough asking about an incompatible version of the mod at all ;-)

Link to comment
Share on other sites

@ModZero

As I wrote in my 2nd edit above I would wait until there is a statement by the creator. At least, in a main savegame.

Otherwise just try if they still dock to the new rotational ports and tell us your experiences, hownthey behave. So yeah, a sandbox safe is a nice test rig. So feel free to tell whats the status right now if used in KSP 1.12.

(I would do a test myself, but right now, i have some days off the computer... so yeah, it's up to you)

 

Also politely asking is in most cases never wrong. :D 

Edited by Rakete
Link to comment
Share on other sites

9 minutes ago, jefferyharrell said:

I've been using the whole Near Future suite in a career save in 1.12.2 for some weeks now. No issues. I have NOT tried docking port rotation, though, so I can't testify to that.

Most of the NF Suite is already updated with the ports packaged in the different topics of the NF Mods (many of them contain ports). This should only concern the ports from NF construction. Maybe it doesn't even. Maybe the old NFC ports just don't offer rotation. Needs to have a test. If they still dock correctly, you should be good to go, if you use them on a station etc. Just test it and let us know. :cool: Good night to today from central europe :wink:

Edited by Rakete
Link to comment
Share on other sites

Regarding my previous post I tested all command pods (that aren't spaceplane cockpits) from NF Spacecraft and stock KSP to see whether their exits were correctly defined.

Spoiler

7841WDB.png

I didn't even find any problems with Nereid (I don't know why it's blocked in my previous screenshot).

The only problematic pod is Proteus. The real hatch area that can't be obstructed is shown in the screenshot below, and as you can see, it's misaligned by a lot.

TXKkFx0.png

Fun fact: Nereid is pronounced nee-rid.

Edited by Krzeszny
Link to comment
Share on other sites

@Krzeszny I'm pretty sure that it's either that engine below the hatch, or that darker small panel above the hatch, or those struts connecting the radiator panels to the capsule.

One of those three types of things needs to be moved, but without the craft file, your mod list, and your save game, I wouldn't be able to determine anything further.

What I'd suggest is to take JUST that section of the craft, put it on a launch clamp at the launchpad, with a Kerbal in the pod, and see if the Kerbal can get out.
If they can, then it's something other than what I told you (on the rest of the craft). Next step would be to take the command pod with all the parts on it and the part attached to the bottom attach node (along with all the parts attached to the surface of that part attached to the bottom node). Keep continuing like this until you figure out what part is obstructing the hatch.
On the other hand, if the Kerbal CAN'T get out, then try moving only one of the parts I mentioned at the top of this post, saving the craft (as a separate craft file, could be just the normal craft file name plus "Hatch Issue WIP" or something), and then test it. If that solves it, merge that change into the main craft file. If not, keep moving things around until the Kerbal can get out, then merge that change back into the main craft file.

TBH I really hate "hatch obstructed" issues. It would be great if the VAB/SPH could show exactly which parts are obstructing the hatch, if it detects that the hatch is obstructed. If I'm thinking about it right, it only has to check each new part ONCE when that new part is added to the ship, and once more when a part is offset. Yes, you'd have to check each part that moves, so attaching and gizmoing subassemblies might be a little bit expensive, but these checks are basically just collision checks anyways so that's likely not that expensive anyways. KSP 1 might even run those checks every frame and we don't really notice the impact that much, so doing it in the VAB/SPH shouldn't be that resource intensive unless you're moving like 100 parts at the same time.

@Nertea

Is there any reason that the actual electrical output of the NF Electrical reactors should be observed to decrease under high time warp states? I thought I balanced the power consumption and production of a mining vessel I built relatively well, and at 1x and up to perhaps 1000x it works just fine. However, at 10kX and 100kX the mining vessel runs out of power within seconds of IRL time, and I can't figure out why. I have more radiator capacity on Loop 0 than I need to handle the heat output of all the converters and drills and the reactor, yet the converters still turn off with a "Insufficient power - shutting down" message. The weird part is that at no point during any of the various time warp levels does the reactor report that it's producing less than rated power, and as soon as the converters trip offline (with that message) the batteries fill up instantly. I have a 7.5m battery on the mining vessel, which should be more than enough power buffer to prevent this from happening (and DynamicBatteryStorage should be adjusting how big that battery is as far as the game itself thinks in order to prevent this exact problem), yet I still get it shutting down.

On a related note, it would be much appreciated if it was possible to put the converters and reactors on separate radiator loops like you can do with the FFT engines. I don't mean using the heat pump part to connect loops either, I mean being able to right click on a converter and select which SystemHeat loop it dumps its heat into. This would allow me to further sub-divide the cooling systems of my vessels as even further insurance against the stock radiator heat bug (that bug is also why I refuse to use non-SystemHeat radiators on my craft, which has been enough to avoid the heat bug so far, but I want more insurance because of how annoying it is to have to reset everything after that bug has happened to a craft without just reloading to a point before that bug happened to the craft).

Edited by SciMan
Link to comment
Share on other sites

@Nertea I have uploaded this issue to github at least twice, but somehow it gets deleted... Don't know why. Maybe you want to pick it up here. I may upload it the third time, but am not sure if it will not get deleted again, (like the two times before).

 

Link to comment
Share on other sites

OK so I went back and looked at the mining vessel I had made, and it turns out I hadn't put in the 7.5m stack-in-line battery like I thought I had. Once i added that part, the problem with the mining vessel not being able to keep running in high time warp seems to have subsided. The question I had remains however, I thought DynamicBatteryStorage was meant to address that kind of issue? It seems it doesn't completely do so. I imagine the only way to fully address it would be to dynamically increase the battery's capacity depending on the time warp level, but that's probably a can of worms you don't want to open so I understand if things remain the way they are.

On a different note, I have a (minor) bug report: There are a few localization errors in Near Future Exploration's Antenna Reflector parts, the ones I'm aware of are in the RFL-100 Giant Dish Reflector and the RFL-2000 Dish Reflector Array, but there may be more. Specifically, the errors are in the text in the Action Group Editor for those parts, instead of showing the text in the localization key, it's showing the localization key itself.
For example, on the RFL-100 Giant Dish Reflector, instead of showing something like "Toggle Reflector" like it should, it's showing something like "#LOC_NFEX_ModuleDeployableReflector_Toggle = Toggle Reflector" which doesn't really break anything because I can figure out what it's saying (and even if I couldn't the context of the other (working) options next to it would let me figure out what it's supposed to do),  but I can tell that it's obviously not what it should be saying. I don't know how these localization things work, but I assume it's just more data held in a different config file somewhere so it shouldn't be that hard to fix.

Link to comment
Share on other sites

3 hours ago, SciMan said:

I don't know how these localization things work, but I assume it's just more data held in a different config file somewhere so it shouldn't be that hard to fix.

Yes, that's right. The game engine sees the localization key, loads the language file for the user's current language setting, checks it for the key, reads the value, and then inserts it into the game text. In this case there's probably something wrong with the language file.

Link to comment
Share on other sites

Hello everyone, since dowloading the new version for ksp 1.12 everything has been working fine except the engine-lfo-advanced-125-1 is missing. Does anyone know what could have caused this problem? I used this part in a very important craft, quite hard to recreate, so i hope someone can help me.

 

Link to comment
Share on other sites

I have a question about RTG fuel decay system used by this mod.

What I'm trying to do is to add Po-210 as a fuel option (via B9PS switch) to BDB SNAP-3 RTG. Basically a short-lived RTG (days instead of years) with large power output.

	@PART[bluedog_RTG_SNAP3]:NEEDS[NearFutureElectrical]
{
  @cost *= 0.5
  !MODULE[ModuleGenerator] {}
  MODULE
  {
    name = ModuleRadioisotopeGenerator
    BasePower = 0.15
    HalfLife= 8.35
    EasyMode = True
  }
  MODULE
  {
    name = ModuleB9PartSwitch
    moduleID = IsotopeSwitch
    switcherDescription = Isotope 
    switcherDescriptionPlural = Isotopes
    SUBTYPE
       {
        name = Pu-238
        title = Plutonium-238
        descriptionSummary = Traditional RTG isotope. Long half-life, but small power density. Suits best for long, lonely cruises to outer planets.
        defaultSubtypePriority = 2
       }
    SUBTYPE
       {
        name = Po-210
        title = Polonium-210
        descriptionSummary = Short-lived isotope with extraordinary power density, suitable for short-lived but extraordinary missions. Requires some extra (but quite ordinary) radiation shielding.
        defaultSubtypePriority = 1
        addedCost = 50
        addedMass = 0.001
        MODULE
            {
                IDENTIFIER
                {
                    name = ModuleRadioisotopeGenerator
                }
                DATA
                {
                    BasePower = 30
                                        HalfLife = 0.0001
                }
            }
    }
  }
}
	

The switch itself works as intended (adds and changes values), but actual decay rate does not - it's as slow as if I never changed HalfLife. Efficiency percentage goes down at the same rate. Is there a hardcoded minimum value? I've tried various values, but it doesn't seem to work.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...