-
Posts
5,039 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by sarbian
-
@BurningSky93 Someone submitted a patch that improve that. It upgraded the landing part too. I'll merge it at one point, but it's not on the top of my list for now. @Secret Squirrel It's easy to be dependant on MJ. It's good to try without it It just merged 2 new patch into dev : The first one is to close the windows that are not researched yet. No cheating ^^ The second one is a patch by Numerobis and me. It improve the way MJ see engine that do not thrust parallel to the ship axis. p I added a toggle to change how the Delta-V display this. A good example would be the stock "Super-Heavy Lander". Its engine are tilted, so part of their thrust don't help pushing the ship forward. Without (as usual) With Putting an engine in front will lower dV with this patch. I don't know if it's useful or not.
-
@TehGimp666 This looks nice and congrat on making it work. But in your long post you forgot the Licence and Source link (cf rules)
-
Modular Fuel System Continued v3.3 (OBSOLETE)
sarbian replied to NathanKell's topic in KSP1 Mod Releases
This is now integrated in the last dev version on MJ2. -
It may be related to FAR. MJ thinks that a control surface make a ship turn at a specific angular speed. When you use FAR that speed change and MJ is confused.
-
@Bromoc Look at MechJebModuleInfoItems.cs : AllStageStats() No need to downgrade your env, just set the target version in your project. @mjones1052 install the last dev version or read this post : http://forum.kerbalspaceprogram.com/threads/12384-PART-0-22-Anatid-Robotics-MuMech-MechJeb-Autopilot-v2-1?p=726754#post726754 2.1 has a bug when you use ModuleManager
-
There is no code in MJ to move part in the staging list. When an engine goes down to the last stage it is when it start and the game move it. I just tried your first file 3 time. The first time it broke under its own weight on the launch pad, the 2 other times there was a structural failure. With the second version I had to add strut for it to not cut itself in two after take off, and even then it ended with the same message than the first one : "Structural failure on linkage between Rockomax Jumbo-64 Fuel Tank and Bigger Badder Bi-Coupler." After that MJ think that the upper engine are the only one left and start them, making things worse. But the problem is the structural failure.
-
Just pushed a small fix to the dev version. The docking and ASAS force roll are now aligned, and the rocket *should* not turn just after takeoff (hard to reproduce but I think I found it) I did more test with RCS docking. It seems I need to work more on it... Activating "Conserve RCS fuel" (custom window editor in Thrust category) may help on some ship.
-
[1.2.0] Precise Node 1.2.4 - Precisely edit your maneuver nodes
sarbian replied to blizzy78's topic in KSP1 Mod Releases
Just asking out of courtesy ^^ -
[1.2.0] Precise Node 1.2.4 - Precisely edit your maneuver nodes
sarbian replied to blizzy78's topic in KSP1 Mod Releases
@regex may I borrow the increments button idea for MJ2 ? -
You can now override specific lines in a ConfigNode (what the game's code calls the format inside a .cfg file), on a line-by-line basis, and you don't have to specify lines that you don't want to change. The new format looks like this: Single Part and editing format @PART[SomePart] // change Some PART { @mass = 0.625 // change SomePart's mass to 0.625 @description = SomePart: now uses Xenon! @MODULE[ModuleEngines] // change SomePart's ModuleEngines MODULE { @maxThrust = 2.25 // change maxThrust to 225 @PROPELLANT[LiquidFuel] // change its LiquidFuel propellant { @name = XenonGas // use XenonGas instead @ratio = 1.0 // change the ratio } !PROPELLANT[Oxidizer] {} // remove the Oxidizer propellant completely. } RESOURCE // add a new resource to this part { name = ElectricCharge amount = 100 maxAmount = 100 } } Let's break this down. If you make a .cfg file with an entry that looks like this: PART { name = myPart ...(stuff) } you're defining a new part. Then, if another .cfg file somewhere does this: @PART[myPart] { ...(stuff) } That says "at the PART named myPart, add the following additional stuff..." There's two ways you can do this: 1. @PART[myPart] {...} is for plugin developers, who need to add new modules and resources to stock parts. 2. @PART[myPart]:Final {...} is for "tweakers", who want to release a set of reconfigurations of other peoples' parts that changes gameplay, or personal patch. The change with :Final are applied after all others are done. inside the curly brackets, you have several options: @foo = <new value> changes foo to <new value>. !foo = DELETE deletes foo completely. foo = <value> creates a new variable called 'foo'; if there was already a variable called 'foo', now there's two of them. if there are two or more variables called foo, you can refer to them like this: @foo,0 = <...> finds the first one (this is the same as @foo = <...>) @foo,1 = <...> finds the second one, @foo,2 = <...> finds the third, and so on. The same thing works for !foo,0 etc. @NODE[foo] {...} modifies the node which has type 'NODE' and name = foo. 'NODE' is a MODULE {} or a RESOURCE {} or a PROP {} or something like that. !NODE[foo] {} deletes node foo completely. NODE { name = foo ...(stuff) } creates a new node of type NODE. If there was already a node of type 'NODE', now there's two of them. for nodes, instead of using a numeric index to identify between multiple nodes, you search by its <tag = ...> line. So if you do @NODE[foo,bar] {...} that will find and modify the first node that was defined like this: NODE { name = foo tag = bar } Right now 'tag' isn't being used by anything, but in the future if you need to add multiple nodes, adding a 'tag' field isn't a bad idea. It'd look something like this: PART { name = EngineSABRE module = Part ... MODULE { name = ModuleEngines tag = Atmosphere ... } MODULE { name = ModuleEngines tag = Vacuum } } and then someone could access the second node by going: @PART[EngineSABRE] { @MODULE[ModuleEngines,Vacuum] { ... } } Multiple Parts You can also apply a change to multiple part. Use a wildcard search for all "name" inside brackets : All PART whose name start with "B9_" @PART[B9_*] { ...(stuff) } Search for specific module All PART who have a ModuleEngines @PART[*]:HAS[@MODULE[ModuleEngines]] { ...(stuff) } will search for part that looks like : PART { MODULE { name = ModuleEngines } } Or the absence of a module All PART who have NO ModuleCommand @PART[*]:HAS[!MODULE[ModuleCommand]] { ...(stuff) } Search for properties All PART whith "category = Utility" @PART[*]:HAS[#category[Utility]] { ...(stuff) } will search for part that looks like : PART { category = Utility } Or the absence of a properties All PART whithout TechRequired @PART[*]:HAS[~TechRequired[]] { ...(stuff) } Search for module with a specific configuration All PART who have a ModuleEngines using XenonGas as a propelant (space for clarity) @PART[*]:HAS[ @MODULE[ModuleEngines]:HAS[ @PROPELLANT[XenonGas] ] ] { ...(stuff) } Combine search All PART who have a ModuleEngines and have a SolidFuel ressource (space added for clarity) @PART[*]:HAS[ @MODULE[ModuleEngines] , @RESOURCE[SolidFuel] ] { ...(stuff) } It works at lower level too : All PART who have a ModuleEngines using XenonGas and ElectricCharge as a propelant (space added for clarity) @PART[*]:HAS[ @MODULE[ModuleEngines]:HAS[ @PROPELLANT[XenonGas] , @PROPELLANT[ElectricCharge] ] ] { ...(stuff) } Use wildcard search at lower level All PART without ElectricCharge as a ressource but with any other. @PART[*]:HAS[!RESOURCE[ElectricCharge],@RESOURCE[*]] { ...(stuff) } Some usefull exemples Add a tech level to all PART who don't have any @PART[*]:HAS[~TechRequired[]]:Final { TechRequired=advScienceTech } Add the Mechjeb module to all command pods who don't have it @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final { MODULE { name = MechJebCore } } All the exemple use PART but it works on other nodes too : @EXPERIMENT_DEFINITION[*]:HAS[#id[gravityScan]] { @baseValue = 5 @scienceCap = 10 } You can also search the old threads for use case : http://forum.kerbalspaceprogram.com/threads/31342-0-20-ModuleManager-1-3-for-all-your-stock-modding-needs http://forum.kerbalspaceprogram.com/showthread.php/41616-Extension-for-ModuleManager-with-wildcard-and-conditional-v0-2-24-july-2013 Change for v2.x New features: MATH! @PART[*]:FOR[Realism] { @mass *= 0.25 @maxTemp -= 500 @scale += 2 } PROPER INDEXING! @PART[*]:HAS[MODULE[MultiModeEngine]]:FOR[Pony] { @MODULE[ModuleEngineFX],1 { @PROPELLANT[Oxidizer] { @name = LiquidOxygen } } } PER-MOD PARSE PASSES! @PART[fuelTank]:BEFORE[RealFuels] { @RESOURCE[LiquidFuel] { @amount *= 5 @maxAmount *= 5 } } @PART[fuelTank]:AFTER[RealFuels] { !RESOURCE[LiquidFuel] {} !RESOURCE[Oxidizer] {} } DEPENDENCY CHECKING! @PART[fuelTank]:AFTER[RealFuels]:NEEDS[RealSolarSystem,!RealKerbalSystem] { @scale *= 4; } If it detects a loaded DLL, it assumes it's a mod and creates a :BEFORE, :FOR and :AFTER pass for it. If you use underscores to specify your mod's version in the filename, ModuleManager will regrettably think that these are part of the filename, because I can't tell the difference between "MyMod_1_3_6" and "Mod_1337s_Cool_Stuff". On the other hand, if you use periods to specify your mod's version, then "MyMod.1.3.6" will correctly be identified as "MyMod". This means that there will always be the following passes: :FIRST :BEFORE[Assembly-CSharp] :FOR[Assembly-CSharp] :AFTER[Assembly-CSharp] :BEFORE[ModuleManager] :FOR[ModuleManager] :AFTER[ModuleManager] :FINAL Specifying ':FIRST' is optional; I just named the 'main' pass so that the log file is clearer. If your mod includes a DLL put all your MM patch nodes in the :FOR[yourMod] pass. If your mod does not include a DLL, then pick a name for your mod THAT DOES NOT CONFLICT WITH ANY OTHER MOD'S DLL, and then put all your MM patch nodes in the :FOR[yourMod] pass. If you do this, other mods can use :BEFORE[yourMod] and :AFTER[yourMod] to politely modify things furthr at the correct sequence. The following parameters are currently implemented: :BEFORE[ModName] - execute this patch BEFORE ModName executes its patches. :FOR[ModName] - I am ModName, and these are my patches. :AFTER[ModName] - execute this patch AFTER ModName executes its patches. :NEEDS[ModName1] - execute this patch only if ModName1 is installed. :NEEDS[!ModName2] - do not execute this patch if ModName2 is installed. You can combine NEEDS nodes like this: :NEEDS[ModName1, !ModName2] You can match subnodes in one of seven ways: @NODE[name] // will wildcard match name (so you can do ModuleEnginesFX or ModuleEngines*), and apply itself to the first NODE it finds. @NODE[name],index // will wildcard match name, and apply itself to the indexth NODE it finds. @NODE[name],* // will wildcard match name, and apply itself to ALL matching NODEs. @NODE[name]:HAS[criteria] // will wildcard match name and apply itself to all matching NODEs which also meet the :HAS criteria @NODE:HAS[criteria] // will apply itself to all matching NODEs which also meet the :HAS criteria @NODE,index // will apply itself to the indexth NODE it finds @NODE,* // will apply itself to ALL NODEs These apply to @, ! and % nodes. $ nodes are necessarily single-application, and thus will always apply to the first node they find.
-
No logs => No support What is ModuleManager ModuleManager ( by Sarbian and Blowfish ) is mod that let you write patch file that edit other part at load time. With is you can edit squad (and other mod) part without overwriting their file. ialdabaoth gave me his blessing to maintain Module Manager while he is away. Licence & Source Module manager source is under a "CC share-alike license" under the term specified by ialdabaoth here. He is the original creator of Module Manager. The source code for this version is available here : https://github.com/sarbian/ModuleManager What's New The DLL name contain the version number, and even with 2 version present only the newest will run. This makes install of addons using it easier since you don't have to check date on the file when overwriting it. There is also some code to warn you if an old version of MM or my MMSarbianExt is present and to ask you to delete them. Version 2.0.x Read the list of change by ialdabaoth at the end of the 2nd post Version 2.1.x Many changes by Swamp_ig. Documentation update is in progress. This version parse your save game just before the main menu. It can take some (lot) of time if you have a bunch of olds saves. I'll try to find a way to limit that. Version 2.2.0 Build for KSP 0.24 - Beware that the Save Game Fixer of previous version was disabled since 0.24 include fix that make it less usefull. Version 2.3.1 A lot of under the hood code change. There is a ingame DB reload/dump menu you can open with ALT-F11 while in the spaceport screen (be aware that it mess up R&D unlock, as the stock reload does) I strongly advise to delete any 2.2.x version laying around as 2.2.1 and 2.2.2 don't deactivate themselves properly when a newer version is around (but they don't break anything either) Version 2.3.3 Module Manager is now integrated with the loading screen. You'll see the info message a bit later in the loading process. Fix the /= and -= operator (the argument where inverted) Version 2.3.4 Fix the long loading time Version 2.3.5 Fix perf related problem when using a lot of regex. It's the one bundled with B9. Version 2.5.0 KSP 0.25 Compatibility and changes I'll document later. Version 2.5.1 Version bump to fix a mistake in my build script. Version 2.5.2 Add a cache of the patched config so it's loaded faster after the first load. The cache is deleted if any .cfg changes in your Gamedata (excluding those under PluginData). Version 2.5.3 Fix a big with the variables implementation. Version 2.5.4 Rebuild for 0.90 Version 2.5.5 Bug fix for value with dot or dash in their name Version 2.5.6 Fix my stupidity. Version 2.5.7 Bug fix for value with '&' in their name Version 2.5.8 Improve feline handling and feeding Version 2.5.9 Disable VSync while in the loading screen. Version 2.5.10 Some debug code to catch a bug. If you get "Exception while checking needs" lines in your log please report them Version 2.5.13 New compare test and # operator to copy-paste nodes Version 2.6.1 Rebuilt for 1.0 and VSync trick removed since it is now stock Version 2.6.2 Allow for modded Techtree to be used. Version 2.6.3 Allows the patching of Physics values with a PHYSICSGLOBALS node Version 2.6.5 - Clear the partDatabase.cfg if the module manager cache is expired - Add some some useful log for all modders (search for "[ModuleManager] ModuleManager env info" - "-nyan-nyan" option detection for the true believers Version 2.6.6 - Add a Quick Reload for ALT F11 menu (skip PartDatabase.cfg generation) - Ignore the cache (and force a PartDatabase.cfg generation) on KSP version change Version 2.6.7 - log now displays the SHA256 of all loaded dll and the KSP exe - at the end of the patching MM will notify mods that needs it. cf this post for the details Version 2.6.8 - Fix a bug with nested :NEEDS when the top node also used a :NEEDS Version 2.6.9-2.6.12 - Bug fixes and AssemblyReloader support. Thanks to the submiters for their patch Version 2.6.13 - Built for 1.0.5. No change. Some 1.0.5 specific changes will come soonish Version 2.6.14/15/16 @key,* = xxx applies to all presents key value @key[1] += 1 will apply the math to the 2nd component in a comma separated vector. "key = 0,1,0,1" will be " key = 0,2,0,1" @key[*] += 1 will add 1 to all elements of the vector. "key = 1,2,3,4" will be changed to "key = 2,3,4,5" @key,*[1, ] += 1 will do it on all the key Version 2.6.17 Add a warning for users on build 1024 @nightingale proof Log added/deleted/changed cfg files. Search for "[ModuleManager] Changes :" in the log Version 2.6.18 Fix a bug with the cache and the loading of the PHYSICGLOBAL node. Version 2.6.19 Add new features for looping and editing value outside the current node Version 2.6.22 1.1 build. And some other stuff I forgot Version 2.6.23 @blowfish patch to add & operator: insert only if it doesn't already exist Fix for the insert NODE at position keeping the index in the node name that blowfish found fix for nested constraint not looking past the first result Version 2.6.24 1.1.2 build Version 2.6.25 Fix Exception for variable searching a value that does not exist Version 2.7 1.2 ready - High fidelity cat and text rendering Version 2.7.1 1.2 ready Allow value name that include multiple comma, as long as none has a number as its first char Display the number of exception and the file that generated those exception Better feeback on what MM is working on lower garbage a bit Version 2.7.2 Fix the @value,* = xxx Version 2.7.4 Fix operations on multiple values Version 2.7.5 Reloads Kerbal traits config after the patching Version 2.7.6 Fix PartUpgrade System patching by @Shadowmage Version 2.8.0 KSP 1.3. Big thanks to @blowfish for his 1.3 patch and endless support in the thread Version 2.8.1 Improve some exception catching and logging add -ncats command line option (to be combined with -nyan-nyan) Version 3.0.0 Huge rewrite and code cleanup by @blowfish Patch loading (without cache) is faster. About 10-30% depending on the number and composition of mods involved. Code changes made here will make it much easier to add new features in the future. Many tests have been added which can be run after ModuleManager is compiled. This will help ensure that future changes don't break existing functionality. Version 3.0.1 Fix NEEDS checking for inner nodes/values Add a -mm-dump cmd line option and redo the export Version 3.0.2 Allow 0 or many spaces before operator Fix :NEEDS patch order Version 3.0.3 Fix non-US Linux decimal separator Version 3.0.4 Allow operator-like character in value name Version 3.0.5 Fixed the Cats for KSP 1.4. Clearly a matter of uppermost urgency. Version 3.0.6 Rebuild for 1.4.1 and some minor fixes Version 3.0.7 NEEDS now allows subdirs (NEEDS[SquadExpansion/MakingHistory]) Allow parentheses in value name Allow spaces in value names Bug fixes Version 3.1.0 more Internal code improvement by @blowfish more detailed log about what works™ but should be written differently. Version 3.1.1 more Internal code improvement by @blowfish Version 3.1.3 Add a workaround for the 1.6.0 PartDatabase / Editor bug Version 4.0.0 @blowfish worked his magic once more and now MM does the patching while the game loads the models and textures. Version 4.0.1 Fix tech tree and modded physics Version 4.0.2 Allow assemblies to add to mod list (Fix for Kerbalism compatibility) Add -mm-dont-copy-logs command line flag if you do not want to copy MM log back into the game log Fix for KSP runs in debug mode. Version 4.0.3 Logging: Fix context not showing up for exceptions in logs Remove datestamps from log messages (only put time), instead write date at top of logs Have timestamps on logs reflect when the log message was created rather than when it was written to the log Fix files with a space before the extension breaking the cache Fix tabs and newlines (\t and \n) getting stripped out of values Version 4.1.0 KSP 1.8 Version 4.1.2 Add an Exception interceptor to catch ReflectionTypeLoadException and properly blame broken DLLs Version 4.1.3 Cleanup the Exception interceptor code and remove the double exception logging and improve the badly worded warning Version 4.1.4 Fix a bug with LAST[modx] when modx is not present some code cleanups Version 4.2.0 Part loader now relies on physics values (for e.g. minimum rigidbody mass), so we want to set modded physics earlier Version 4.2.1 Fix a bug introduced in the previous version Version 4.2.2 Support wildcards in nodetype matching so you can do @*,* {} Support # in value names since loc names start with # Tell Localizer to reload the language after MM finishes Version 4.2.3 Fix the dll hashing when the dll is already opened. by @linuxgurugamer Fix for MM loading the wrong physics file when when when using the faulty PDLauncher workaround Version not listed here ? Check the Jenkins Server. If it is there then you can use it without fears of triggering the end of the world. by @siimav Downloads : For KSP 1.8.0 - 1.12.x ModuleManager-4.2.3.zip ModuleManager.4.2.3.dll For KSP 1.4.0 - 1.7.x ModuleManager-4.0.3.zip ModuleManager.4.0.3.dll Last version for KSP 1.3.x ModuleManager-4.0.2.zip ModuleManager.4.0.2.dll ModuleManager-3.0.4.zip ModuleManager.3.0.4.dll Last version for KSP 1.2.x ModuleManager.2.7.6.dll ModuleManager-2.7.6.zip SHA256 : 0bc14c3e0dbd8191dfb9aff5b8408c377e0bc74d508ed10fe4b4371ab569f95c Doc and patch file format in the second post. A Documentation Wiki is in progress Post on how to use variable in MM Community examples and useful patch Changes : - merged with my wildcard extension - add a "~" operator to check for missing properties - let you use wildcard search in other part than the name of the part - let you patch other things than PART (this was working with MM but not with MMExt) - handle badly formated cfg file better - include Majiir workaround for KSPAddon bug - a bit more verbose and all log line start with [ModuleManager] to make search easier - you can have multiple MM dll installed in the root of gamedata, only the newest will run - a special tag allow to exclude MM from processing a folder - % operator for value and node that edit if the value/node is present and add it its not - $ operator that duplicate it (It does not work for a root node, ie a PART) - @NODENAME,2 {} let you select the third node of that name. Be careful when you delete or add node as the index will change. Todo : - re-apply patch when you reload the database from the debug menu. It's quite a useful feature, but won't change much for mod use. No promise for this. I had something working but it failed at the second reload. KSP code makes this quite hard. I may took the easy way out and just add a button. How to install You just have to put the dll in your KSP/GameData folder. Then you can put you patch .cfg file anywhere. I would create a folder for your personal patch, but it's up to you. As mentioned earlier you can have multiple version of it. But you can clean up too
- 7,671 replies
-
- 124
-
@jimos The RdV AP is to meet a ship in orbit. It will always always crash you if you use it on a moon You should use the "Hohmann transfer to target" in the Maneuver Planner followed by "Fine tune closest approach to target" @willow What will appends a some point is that I'll add a pad to move the landing point by X meters in some direction. And for your suggestion I don't think the current code allow for that easily.