Jump to content

Yemo

Members
  • Posts

    1,486
  • Joined

  • Last visited

Everything posted by Yemo

  1. Stock progression contracts can not be modded (no idea why squad did that), only deactivated using contract configurator. Which was the original reason for developing the contract progression of which InitialContracts is a spin-off.
  2. It was mentioned in PP before, but nothing came of it. Not sure whether it is a pp or a tweakscale issue, as the gap/clipping is based on the difference between the original part size and the tweakscaled size. The washers rotate in IR, but I would have to create new configs anyway, without the IR module. Though I do not know how the model looks when scaled up to 5m or so...
  3. Wait, now we are confusing each other. That is the one I work with: 1EC = 1kJ 1EC/s = 1kW = 1kJ/s edit: EC capitalized.
  4. If they wear a 80kg suit while weighing 11kg themselves (TAC life support assumption), the suit must have some exoskeleton (though with that kind of head to body proportion, their own skeleton must be pretty sturdy as well). Anyway, that could be used as an explanation for massive carrying capacity as well.
  5. I m doing some preliminary testing of KSPI extended and SETI and found a major issue. The tweakscaled KSPI extended parts suffer from the same ProceduralParts incompatibility as many stock parts (eg basic jet). I tested with the Small Molten Salt Reactor tweakscaled to 1.25m below a procedural liquid tank. After saving and reloading the craft, the tweakscaled reactor leaves a major gap. It is as if the reactor model was positioned using the non-tweakscaled size and only after that positioning, the model is shrunk to the tweakscaled size. If you do it the other way around, attaching an upscaled reactor to a procedural part, it clips inside the procedural part instead of leaving a gap. Since SETI uses only procedural parts for tanks and structural elements, this is a major compatibility problem. When faced with this problem before (basic jet engine), I came up with a stop gap workaround, but did not have the models to implement it: Since tweakscale does not like procedural parts, there needs to be something like a washer between the tweakscaled part and the procedural part. So it would go like this: procedural part - washer with the right diameter, not tweakscaled - tweakscaled part, eg reactor So it would essentially require washers for every concievable diameter. And it would best be a model which is very flat and has an unobstrusive color (eg grey). edit: One of the models of the Infernal Robotics Washer could fit as a stop gap washer. They are blackish and thin and distributed under GNU GPL, so I could just make a bunch of rescaled versions for the structural tab...
  6. YEA! Great idea. I m doing the same thing for VAB ordering in my main mod, but as I do not use CKAN myself, this escaped me.
  7. About Kerbal Mass: Great, thank you for picking this up! If you can, please make the KerbalMass setting tweakable per MM statements! That way, Better Buoyancy could tweak that setting by itself. And players could write their private MM config, not only for KIS, but for other setting dependent mods as well, like RemoteTech (when they support MM statements on configs). When suggesting this in the KerbalMass thread, nightingale wrote that it would just require the monobehaviours to be run at the start screen (or so), instead of instantly. About container carrying: Since a stock kerbal weighs 93 kg or so (!), I expect them to have some kind of high density endoskeleton (mini wolverines or so). And they can lithobreak head on without any injuries. So I would consider a 1000L backpack to be "in-line" with their "character"...
  8. @Faster: Those issues sound really annoying, hopefully we'll find the cause. SETI changes the maxDiameter of the SRB to 0.5 at the start, through the SETI\0ProceduralParts\SETI-PartMod-PP-SRB.cfg config. But that should not affect the real fuels SRB. About your MM statement, maybe try using :FINAL instead of :Final, though I m not sure about that. In which config file does RealFuels actually alter the procedural parts? @Chonner: I bet all of us modders started with small private MM statements ;-).
  9. Thank you very much! Karamazovnew seems to be very quiet for the last 2 weeks or so, I hope he comes back to ksp forums. Until then I will include your fix in the HRB config and publish it over at Lord Aurelius HRB thread, if people want to use it before 0.8.6 (which might take some time with the ec rebalance). I was considering a progression approach (there was one somewhere else, I vaguely remember 60, 120 and 211 or so W/m² definitions for 3 different tech level), but that would srew with the existing games even more. With the current plan and the resizes, I can reduce the ec production of a solar part to 25% of the value before and offset that with an energy consumption reduction for remote tech antennas by the same factor. This would at least keep all the solar com sats balanced, since probe consumption is rather marginal anyway. I will try the firespitter fuel switch, put it will most likely have to wait until after 0.8.6. That sounds very strange, and I do not know what could be the cause.
  10. Thank you very much, I will try that out! If the first version works, the MM statement might not even need a reconfiguration, when BackgroundProcessing gets it's own folder!
  11. Thank you for that info, though the problem with BackgroundProcessing is, that the .dll name contains a version number, thus it changes every update (until KSP-AVC is used instead).
  12. Hey, that is a great plugin! Very useful for the energy production part of the gameplay! I m working on an energy consuming part, for which I want to set 2 consumption levels. One normal energy consumption level, if people have your plugin installed. And one mini energy consumption level, if people do not have your plugin installed. To check for the installation of you plugin per MM statements, your plugin has to be inside of a sub folder of GameData (as far as I know). So eg GameData/BackgroundProcessing/BackgroundProcessing.dll. So it would be great if you could change the structure of you download file, to have BackgroundProcessing.dll inside a folder called BackgroundProcessing. Thank you very much!
  13. I doubt that this is possible without air breathers (which screw up the dV numbers)...
  14. SETI only uses procedural parts for tanks and I m not sure, but seem to remember that FSfuelSwitch is incompatible with procedural parts (since they already have TankTypeOption). Unfortunately I do not know of a way to allow changing of the procedural TankTypeOption in flight, that would be very helpful. About Cryostat, I thought about that problem of different storages and power requirements as well, though I did not come up with anything yet. The general problem might have some overlap with the fuel transfer energy costs proposed/implemented by Papa_Joe for ShipManifest. Essentially every resource would require energy for transfer and some resources require energy for storage as well... Maybe some unified approach to that general problem could be developed. Unfortunately I m currently I currently have more than enough on my plate, with all the ec rebalances, half-done mode integration and bug fixes.
  15. Ah, good to know. But I think I will rebalance it before 1.0 anyway. SETI provides something like a controlled environment, so it could work like a lab experiment testing how everything would work together with a standardized 1EC/s = 1kW = 1kJ/s. And it would not require everyone to shift at the same time to avoid issues, since I could control all parts with mm statements. And when it works out, those changes could then filter back into the original mods, if there is sufficient community commitment for a broad acceptance. For that purpose I will rebalance many of the formulae of US per mm statements, based on the ec definition difference factor of 30.3 compared to the 1ec/s = 1kW and gameplay needs. Thank you!
  16. I like the idea of the pump module, though that might result in problems with mods which do not integrate the pump module. I can see how it works very well in a controlled environment, like SETI, but for the "wild" it would really need wide support. Maybe it would be easier to specify transfer costs for the different resources in a ShipManifest config which can be changed via module manager. Though that would probably result in a lot of work for you, to set up and maintain, not sure if that is worth it. The main issue at the moment seems to be gases like hydrogen and oxygen, which do not conform to the 1unit = 1liter convention. With the upcoming stock ksp update to 1.0 and the changes to the resource system, as well as the planned update for the CommunityResourcePack by RoverDude, anything more than a stop gap solution might not be worth the effort at the moment. Thank you for the feedback! Over a week ago I wrote a pm to karamozovnew, the author of Real Fuel Stock Tank Prices, about SETI integration (since I do not have the time to rebalance it myself, but I will support him where I can, if he wants to do it). So far, I did not get a reply, so I m not sure if he wants to do that. I can try to fix the PP SRB as a stop gap, but I have very limited experience with real fuels and with the EC rebalance, there is a lot of other stuff on my plate. I tried to avoid the EC rebalance since I started with SETI, but now with all the additions, I really need at least some kind of framework. So essentially the pain of adjusting to the stock ec mess has grown so much, that it now seems to be larger than the massive pain of rebalancing EC... And using reality as a very loose framework at least frees me from the work of coming up with something else. So realism in that regard is not my aim, I just use it as a reference, when it makes my life easier. And I ignore it, if it results in gameplay issues and/or major work without gameplay improvements...
  17. While working on 0.8.6 and the SETI Greenhouse, I once again bumped into the ec definition mess. So I finally decided to balance/standardize that to the most commonly used 1ec/s = 1kW = 1kJ/s. The planned EC rebalance will have massive ramifications for all vessels. I m trying to keep the issues as small as possible, but with the wide variety of definitions used at the moment (1ec = 33J to 1ec = 30kJ or something), that will hardly be possible. Preliminary findings: 1. Alkaline Fuel Cells Especially the alkaline fuel cell from universal storage (1ec = 33J) and it's stop gap derivative will have to be broken. It seems to be 30 times more efficient than it should be, if the formula was set up correctly with the 1ec = 33J definition in mind. If anyone knows a good realistic formula for the alkaline fuel cell, please tell me (energy output per gram of hydrogen and oxygen input, I will then reconvert that to the volume units used for hydrogen and oxygen). 2. Solar Panels Solar panels are way too efficient for their size, by a factor of 10.6 or more, but are also much too heavy for their size... To distort them not too much, I plan to use a 2-way approach: a) Increase their model size by a factor of about 1.65 or 2.3. Lower their energy output by a factor of 4 or 2, so that they would either produce only 25% or 50% or their current output. c) Adjust the mass, somehow. Any input is very welcome! d) Not sure what to do about the flat solar panel. Choosing whether to go with the 25% or 50% output (and the corresponding model size increase) is a tough choice. I think it may depend on whether I can/have to change the values for the RemoteTech antennas and dishes. So if anyone has input on that, please tell me! 3. Batteries Batteries are much too weak at the moment in terms of volume and mass. a) Rebalance their volume and mass. Adjust their ec capacity. As a comparison, the rebalanced Z-100 battery (using Ven's Stock Part Revamp models) is planned to have: a) 2L volume instead of 16L (50% scale), still 5kg mass 2500 ec capacity, instead of 100 ec 4. Probe Cores Seem to be reather okish with the new ec standardization, a probe core would need about 20W to work 5. Reaction Wheels I do not know enough to rebalance those 6. RemoteTech Antennas and Dishes That is a tough one, which will lead to problems with the fuel cell and solar panel rebalance on existing sats... I do not know what definition of ec was used, when the energy consumption of their antennas and dishes was determined. If anyone knows how many Watt are used for eg 2500km space omni antennas, please tell me! And for dishes with the remote tech cones as well!
  18. The stock contracts are deactivated by the initial contracts mod (launch, 5km - 56km contracts, reach space, orbit), at least if you start a new game (not sure what stays if you mod an existing save). So with the mod installed, there are only 3 contracts: 18km, space and orbit. As I said, you might need to ajust the payouts/advances if you play with larger kerbin sizes. Or you just compensate by giving you more money after completion, with the debug menu.
  19. The stock starting altitude contracts can only be completed by manned vessels, not by probes. This mini-mod might help you out: InitialContracts It replaces the buggy stock contracts with basic ContractConfigurator contracts, which can be completed by probes and manned vessels. Though I do not know whether they need adjustments for different sizes of kerbin.
  20. Hey, I m not very aware of the realism mods, sorry for missing this when I first introduced the initial contracts. My SETI-BalanceMod (link in signature) starts unmanned, so I faced the issue that altitude contracts could only be completed by manned vessels, until making configs for the Contract Configurator mod by nightingale. I released replacements for the buggy stock starting contracts, based on the ones I use for the SETI-BalanceMod, for use with other TechTree mods: Initial Contracts InitialContracts replaces the buggy/annoying stock starting contracts with 3 similar ones, which can be completed by manned and unmanned craft. Thus the mods contracts are especially useful for TechTrees which start unmanned and may be redistributed with them. They are based on the SETI-Contracts but more balanced for stock. InitialContracts Link The mod Contract Configurator by nightingale is required to use the configs. These Contract Configurator configs by nightingale and Yemo are based upon the general contracts of the SETI-BalanceMod. License: You may do what you want (change, expand, mix, redistribute as part of a larger package etc.), as long as you provide the source (eg. SETI-BalanceMod with link) and credit for previous authors (eg. nightingale and Yemo) within the file(s) and at the reference locations (forum thread and download site). Hence you can just redistribute this file along with eg a tech tree mod under any (even a very restrictive) license as long as you give credit in the form mentioned above.
  21. Thank you very much, Freethinker and RoverDude, I will work with the 1ec/s = 1kW = 1kJ/s and try to adjust other components around that (which will probably be a long and painful process).
  22. While working on mod integration for the SETI-BalanceMod I once again hit the ec definition bump. There are a lot of mods with different ec assumptions, so I asked in the CommunityResourcePack-Thread about an effort to standardize it, any input from you guys is very welcome!
  23. While working on mod integration for the SETI-BalanceMod I once again hit the ec definition bump. There are a lot of mods with different ec assumptions, so I asked in the CommunityResourcePack-Thread about an effort to standardize it, any input from you guys is very welcome!
  24. While working on mod integration for the SETI-BalanceMod I once again hit the ec definition bump. Too many mods with different ec assumptions, so I asked in the CommunityResourcePack-Thread about an effort to standardize it, any input from you guys is very welcome!
×
×
  • Create New...