-
Posts
214 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by RadarManFromTheMoon
-
[quote name='Sigma88']afaik there should be no difference between PART or any other module. which values did you put in [a|b|c] ?[/QUOTE] [CODE] @PART[*]HAS[@MODULE[ProceduralPart]]:FOR[ProceduralParts] { @MODULE[ProceduralShapeCylinder|ProceduralShapeCone] { %END_CAPS { CAPS { name=default } } } }[/CODE] ProceduralShapeCylinder and ProceduralShapeCone are the names of the modules I try to add the default caps to. Using a wildcard seems to work, but only with the first matching module. [edit] When I use @MODULE[*]:HAS[#name[ProceduralShape*]] instead of @MODULE[ProceduralShape*] (which are, according to the documentation, equivalent) it works fine. [edit] Also working: @MODULE[ProceduralShape*],* Still no luck with: @MODULE[ProceduralShapeCylinder|ProceduralShapeCone],*
-
I know it is possible to patch multiple parts by doing @Part[parta|partb|partc] {} Is there a way to do the same but with modules instead? Like: @Module[a|b|c] {} I tried and using "|" does not seem to work :/ I have a lot of PartModules on the same part that all derive from the same base class, so patching them all at once would make my life soo much easier. :D
-
[B]Changelog[/B] [LIST] [*]Fixed drag cube calculation when root part [*]altered procedural liquid fuel tank tech restrictions slightly to account for the new mk0 fuselage [*]added bulkhead profiles to parts that needed them (thanks Kerbas-ad-Astra) [*]fixed Solid Fuel Rocket when used with ModularEngineConfig (RealFuels) (thanks CorvusCorax) [*]removed an annoying debug message I accidentally left in the code (stdCost:) (thanks ckwng) [/LIST] [quote name='Luis_N_8']I had the same problem but now after i fixed it there are way to much heating effects in the atmosphere and it's showing red flames even at 2000 m/s at 60 km and at launch where never red flames were. I'm using RO/RSS/RP-0 Thx[/QUOTE] ProceduralParts has nothing to do with reentry heating effects [quote name='BlackMoons']Bell on my SRB's ends up in strange places. Rough way I have been reproducing the bug: Taking large SRB section/etc off my craft, adding 2.5 to 3.75m cone and 3.75m cylinder procedural tanks to my ship (cylinder seems fine, cone seems the problem..), then reattaching SRB's, saving and reloading craft.[/QUOTE] Known problem. I will see what I can do about it. [quote name='kronicus']Uhm, may I ask what's causing this booger? :c [URL]https://imgur.com/UOiFpHF[/URL][/QUOTE] An outdated KSPAPIExtension.dll. At least one of your mods is outdated/incompatible or not installed correctly.
-
lqdHydrogen implies you are using some kind of resource mod. (RealFuels?) If you do so, PP does not touch the parts mass at all and the bug is most probably in beforementioned resource mod. Might be the same problem as nablabla reported previously. Any other mods installed? Yes, look for the TankContentSwitcher module. There is a parameter named unitsPerT/unitsPerkL. If you are using RealFuels or ModularFuelSystem though, I don't know. But you should find help in the RO/RF threads.
-
Good news. There is a RealFuels hotfix which fixes the ProceduralSRB crash to desktop issue. Please install, and it should work fine. Alright. I'm about to change a lot in the shape modules at the moment. So waiting a bit might be a good idea anyway. The thing with the tech nodes is that I want to make the players pay for updates. Currently updates costs nothing and get unlocked as soon as a node is researched. But stock parts cost an entry purchase so I think it might be a good idea to add dummy parts which, when purchased, lets you build your procedural parts bigger. The problem is: The way the tech tree works makes it possible to purchase a more advanced update before researching the more basic ones. And thats exploity. btw: you are right. If one can build a small and a big tank, one should be able to design a medium one. But doing so will still cost money and research capacity. So, I think its not totally unreasonable. Bigger tanks also make the rocket less wobbly. I think it makes sense to pay for extra robustness. I know many people don't like the stock tech tree but I don't find it that bad. Its just not easy to harmonize PP with it. Good thing you offer an alternative with your rebalancing mod. Its always good to have the choice. I'll put the USI LS on the todo list. Yeah, sorry, I actually have fixed that already. But wanted to wait until RF gets the ProceduralSRB issue fixed before releasing (in case that requires changes on my side). Now that there is a fix, I will release a hotfix tomorrow. On the wrong mass issue: I will see if I can do something about that but without reproduction steps, it might take time.
-
The stock balancing actually works quite well (maybe because, with PP, I mostly deal with fuel tanks and those are not that unreasonably (un)balanced.) I made an extra part module for stock balancing, so everyone who does not like it that way can simply remove the module from the parts and it will scale the old, linear way. Most of the time we have these types of parts: 0.625m, 1.25m, 2.5m, 3.75m. Take mass for example. The module implements a massPerkL curve for every diameter type (length and diameter in -> mass out) for diameters in between those standard diameters it just interpolates linearly between those curves. Same goes for costs. fuel capacity luckily scales linearly with mass. That way it is possible to make the parts scale exactly like their stock counterparts of the same dimensions. The big problem is really the way the tech tree works. Unlocking techRestrictions on the same node as a comparable sized part gets unlocked feels exploity/cheaty.
-
That bug should already be fixed. Please make sure you installed the most recent versions of both, ProceduralParts and ProceduralFairings. If it still persists please give me precise reproduction steps and logfiles so I can reproduce the bug and fix it. I confirm the crashes when using the ProceduralSRB and RealFuels. Might be that something changed in the RealFuels engine module. Fix is in the making. And now to something completely different. Balancing. My initial goal was to balance all ProceduralParts against stock parts (fuel capacity, mass, costs). When done right it would even be possible to delete the stock parts at all and play completely procedural. Saves some memory n stuff. Stock parts scale somewhat unlinearly, but I did some tesing and it seems to actually be possible to imitate the stock scaling to a satisfying degree (SRBs are the exception, those are more complicated). Now just add some dummyparts with proper entry costs and let them unlock tech restrictions when purchased and everything should work like stock right? I wish. The problem is, in the stock tech tree, it is most of the time not actually required to research all dependencies of a tech node (I guess for err... gameplay reasons?). So it is possible to research a little tank, and after that circumvent the medium sized tanks to directly go to the huge 3.75m tanks. And thats a major f*up because the PP tech restrictions work on a min/max basis. I spent some time thinking about possible ways to get gaps into the allowed size range but couldnt come up with a solution that I'm actually sort of sure would work and wouldn't be a huge PITA to implement. So it might be the best solution to balance the parts against stock, make them much more expensive and place tech updates later in the tech tree than their stock equivalent. That way Procedural parts would be custom made premium parts which cover the ranges in size between the standard stock parts. For people who like to delete the stock parts to replace them with procedurals, there could be an optional module manager config that adds fixed size procedural parts that mimic the stock parts. All that does not apply to RealismOverhaul, because I think they have their own balancing. What do you think? Any ideas?
-
No worries. Can happen. Still on the mk2/mk3 case? Any news? You could compare the old config file with the new. Though, I changed that because it got changed in the stock shields too. So the transparency is probably deprecated/causes problems. I'll think about it but not a priority at the moment. I will see if I can optimize that a bit, but the message driven design of PP makes it sometimes hard to cut down on revoxelizations/drag cube recalculations. Logs or it didn't happen @NathanKell: Thanks for the OP update.
-
Oh! I see whats happening there. All the tanks now have resource nodes to let them appear in the right editor categories. Looks like the parts take their resources from the parts cfg file and overwrites them with the resources from the craft file. resulting in an oxidizer node where it shouldnt be. I'll release a hotfix. As a workaround you can remove these two nodes from "1TankLiquid.cfg" and ConeLiquid.cfg. RESOURCE { name = LiquidFuel amount = xxxx maxAmount = xxxx } RESOURCE { name = Oxidizer amount = xxxx maxAmount = xxxx } make sure to NOT remove the RESOURCE nodes from the TankContentSwitcher. [edit] same applies to the conic tank
-
This is the same as version 1.1.4, but comes with a correct version file. download I totally agree. balancing needs an overhaul. Will be done successively now that KSP balancing is in a somewhat finished state. Regarding the "missing right click options" problems: please do the following: 1) See what mods you have that come with KSPAPIExtensions. 2) Strip them away from your install one at a time and see which one is causing the issue 3) Go to the mods forum thread and check if you have installed the most recent version. If you have, ask for a release which comes with the newest KSPAPIExtensions I'm not sure why it is causing so much trouble. Normally KSPAPIExtensions is designed to tolerate diverging versions.
-
Please don't. Every mod is liked with its own copy of KSPAPIExtensions and its designed to work that way. What you did might work most of the time but it can lead to problems. Regarding Procedural Parts: I will push an update (incorporating the newsest KSPIAPIExtensions) tomorrow. Please be patient.
-
You are using an old PP version (1.1.1). The bug you described was fixed with version 1.1.2. Please always make sure you have the newest PP version (1.1.3) before you report bugs. I guess you thought that to be the newest release because of the threads title. Sorry for that. Otherbarry will have to change that (or we remove the version tag from the title alltogether) Thats okay. Like I said, I havent found any incompatibilities with KSP 1.3/1.4 yet. Still testing though, and everyone is invited to help testing. SoR stands for surface of revolution. GitHub might be the better suited place to go further into the details. Would be great if you could open an issue there.
-
Thanks! I will fix that. Ah, good to know. I will ask him. edit you probably mean this one? The strange thing is: PP does not modify the parts positions after loading. It just saves its relative position in a variable. Parts normally only get moved after a shape get changed...its...weird... :/ Also if it were a Linux/Unity bug, it should occur even without PP. end edit You will have to inherit from ProceduralAbstractShape. And deal with stuff like: - Create Mk2/Mk3 meshes procedurally (of course) - that includes normals, tangents and uv mapping for (custom) textures - adaptors (MK1->MK2, MK1/Mk2->normal PP surface of revolution) - Part attachment repositioning after shape changes - balancing (correct mass/cost/resource amount scaling) - other things I just don't think about right now Best way to see how the implementation works is to dig through the code. If you have a good idea how to do it. Please do. You can always open an issue on github, discussing conceptual stuff / send pull requests / ask questions. That should only occur if you have modified the configs. Have you modified the configs? btw: Good news! Looks like PP works well with 1.0.3. There is the good old "may not be compatible" message at startup. But as far as I can see after some testing, everything seems to work fine. (without guarantee of course!) I will release a recompiled version (with some minor changes/fixes) soon.
-
Okay, I understand that that would cause some confusion. Maybe I will hack something together for myself. I want to do an assisted landing approach. Rapid changes in pitch are not particularly helpfull shortly before the flare maneuver Another thing: The target heading changes itself (gets smaller by 0.01 ~ every 3 seconds) over time. Seems to occur after a few minutes of flying.
-
Great mod, really like it so far. Just two things that bug me: How about letting the vertical assist control trim instead of steering? That way turning it off would not cause the plane to suddenly drop its nose. Also I noticed that turning off the throttle control sets the throttle back to wherever it was before activating it. Seems to mess up more than it helps. Wouldn't it be better to keep it where it is?
-
I'm also getting Exceptions-spam. (using the dll from the previous post, but it also occurs with the official release) reproduction steps: 1. sandbox-game 2. enter SPH 3. load Aeris 3A 4. Click on flight the spam starts immediately after entering flight scene KeyNotFoundException: The given key was not present in the dictionary. at System.Collections.Generic.Dictionary`2[System.String,PilotAssistant.Presets.CraftPreset].get_Item (System.String key) [0x00000] in <filename unknown>:0 at PilotAssistant.FlightModules.PilotAssistant.Initialise () [0x00000] in <filename unknown>:0 at PilotAssistant.FlightModules.PilotAssistant.Start (PilotAssistant.FlightModules.AsstVesselModule vesRef) [0x00000] in <filename unknown>:0 at PilotAssistant.FlightModules.AsstVesselModule.Start () [0x00000] in <filename unknown>:0 at PilotAssistant.PilotAssistantFlightCore.Start () [0x00000] in <filename unknown>:0 (Filename: Line: -1) NullReferenceException: Object reference not set to an instance of an object at PilotAssistant.FlightModules.SurfSAS.Update () [0x00000] in <filename unknown>:0 at PilotAssistant.FlightModules.AsstVesselModule.Update () [0x00000] in <filename unknown>:0 at PilotAssistant.PilotAssistantFlightCore.Update () [0x00000] in <filename unknown>:0 logfile I got the logfile from my dev-installation, so there is ProceduralParts installed. But that shouldn't be the problem since I get the same result on an installation without PP edit... I got it pinned down. there is the problem. The dictionary can not find "default" and therefore throws an exception. Using !PresetManager.Instance.craftPresetDict.ContainsKey("default") instead fixes the Problem.