Fractal_UK

Members
  • Content Count

    1,702
  • Joined

  • Last visited

Community Reputation

270 Excellent

1 Follower

About Fractal_UK

  • Rank
    Capsule Communicator

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'd like to do that as well, the problem is tankage. I'm reticent to add more fuel tanks which take up space in the part list and probably won't be high quality models because they'd probably have to be made by me. It would certainly be useful to have it as a resource both as a propellant and for ISRU purposes but that's the dilemna at present. In other news: Most of the changes for the next update have now been made and it's now just on to the testing and tweaking stage.
  2. This is entirely the rationale behind the change. I'm certainly open to suggestions about small changes to thermal rocket performance, NorthStar made a good point about a universal specific impulse cap for all propellants not being as elegant as properly accounting for the temperature of different elements a couple of pages back and I certainly will take that into account in future changes. The exact value of the cap, in whatever form it takes in the future, could be tweaked as well but I'm not considering going back to how things were before. I know it is a big change and I knew that some people wouldn't like it when I made it but ultimately I feel it is both a realism improvement and a gameplay improvement because the thermal rockets were just too good before. Other engines could be competitive with thermal rockets but only in a particular range of use cases while the thermal rockets performed generally excellently in all use cases. Having to make a tradeoff between different performance considerations is a nice thing, so despite it removing a cool toy, I think it is a change that makes the range of options available in Interstellar more interesting. Make sure you have a reactor and generator on your ship capable of powering it - it has fixed power requirements (2.5GW) that do not vary with your throttle setting (due to its variable Isp performance) and make sure you're well away from any Kerbals/crewed ships (or disable the radiation safety features and be willing to kill your nearby Kerbals).
  3. Sorry about the delay on the update all. The TechManager update that would allow me to release an updated Interstellar fell at just the wrong time for me to get anything out last week. I'll be back to work on Interstellar over the next few days so I'll keep you updated on progress.
  4. 300 doesn't make sense but 3000 does. 3000s should now be the approximate maximum with antimatter, it does no longer win outright for both thrust and Isp but should prove to be a strong choice for both thrust and flexibility.
  5. You can buy and sell most of the advanced Interstellar resources. So far, I've avoided including antimatter in that calculation. As much as I'd like to make it sellable, the cost would just be too large and the economy becomes entirely determined by how much antimatter you can produce. Before I can include the buying and selling of antimatter, I'd need to make the cost of it variable depending on your current position in the tech tree. That would allow you to sell tiny amounts at huge prices earlier in the game but later on buy and sell at somewhat more reasonable prices after the technology to produce it becomes more widespread on Kerbin. If you want to make money from resources at the moment, the most effective way is to produce Tritium or Helium-3.
  6. I've seen them, yes. I've even managed to read through some of it but I am struggling a lot for time at the moment so all of the time I have had to work on Interstellar-related things has been occupied by tech tree work. Hopefully I will get on to other things in the nearish future. Edit: Thanks for the summary, I'm aware of most of those issues and many of them are easy fixes - I should be able to release them along with a version including the tech tree fixes.
  7. If you switch back to the space centre (leaving the transmitter on), then back to the vessel, does it start to work?
  8. Fractal_UK

    [0.25/0.90] TechManager Version 1.5

    Moving on from the horrible diversion, I actually really like the subtree idea. It could be ideal for a wide variety of use cases, especially if it could be applied to the stock tree directly but maybe you can determine better than me if that's actually a plausible idea. I know I had problems in the past when the stock tree was changed between game versions.
  9. Fractal_UK

    [0.25/0.90] TechManager Version 1.5

    If you genuinely believe that (rather than are trying to avoid admitting to an error) you should go and reread the thread. I suspect you still don't understand how the versioning system works, in which case I really recommend looking at it again until you do because it may actually be of use to you if you need to strongly version dependencies. Regardless, I'm getting a little tired of being used as an example of bad community interoperability for your error, whether you accept it or not. I've tried to be civil and ignore your persistent snipes and I apologise to the rest of the community for this unnecessary diversion but I felt it was about time the record was set straight.
  10. Fractal_UK

    [0.25/0.90] TechManager Version 1.5

    The version which was broken would never have been called by a mod which followed the versioning rules layed out in the post. The very fact that it didn't work correctly proves that it was not being used properly (Edit: improper versioning, for the record, opens the mod up to problems between dlls from different game versions and hence should never be done.)
  11. Fractal_UK

    [0.25/0.90] TechManager Version 1.5

    For the record, ORS was never broken and never will be broken as a multi-mod system, it was, in fact, designed with that overriding goal in mind. Some people chose to use it incorrectly despite the documentation on the thread indicating how to do so correctly but that is beside the point of this thread. Ultimately, CTT is tangentental to the purpose of TechManager. The point is to provide the KSP's players with a system by which they can choose which tech tree they want to play with. CTT is one option for those tech trees and, assuming it continues to be supported by a sizeable group of modders, it will be a tech tree that many people choose to play with. However, there have been previous attempts to create tech trees that incorporate the parts from a wide variety of mods in the past (MedievalNerd's work springs to mind) in order to achieve different aims. Greater realism or better gameplay experience might be valid reasons for such projects and I guarantee within a very short time of the latest changes to this mod becoming available, people will be making those mods again to serve all sorts of different purposes. Some of these mods might involve sweeping changes to the tech tree compared to stock, while others might involve very small tweaks or merely extensions to the stock tree. All of these are valid and all serves the needs of different groups of players. Ultimately, I intend to remain neutral on the issue of which tech tree to actually use. From my point of view, it's better to provide people the tools to solve a problem in a way that they are happy with than to excessively favour one solution which may be suboptimal to a sizeable group of players, hence the reason for Interstellar maintaining a unique tech tree in addition to the CTT. More choice for the player is generally a good thing and that is what TechManager should aim to provide.
  12. I'm now just waiting for anonish to finish tweaking some of the changes I made to his TechManager mod before the next offical release. I don't know exactly when this will be ready but I now have the capability to release a temporary "official" fix for the existing version of Interstellar which will make the tech tree work correctly again as well as allow new save games to select the interstellar tree so I will try to release it as soon as I have some time. FrancoisH: Si vous avez une problème avec les instructions, envoyez moi une message et j'essaierais les poster en français.
  13. Fractal_UK

    [0.25/0.90] TechManager Version 1.5

    I don't think the original code is on Github, I got the sourcecode from the download and just created a new repository to host my work. In the version that I'm working with, it is possible to make changes to each tree with module manager but it would generally not be neccessary to do so. Each mode can simply distribute a tech tree with their mod and that tech tree would appear as an option in the list of selection options the user has available. A group of modders here are working on a community tree that the tech nodes for many mods should appear in, allowing the user to select this community tech tree and have a unified tree from a whole bunch of mods.
  14. Fractal_UK

    [0.25/0.90] TechManager Version 1.5

    I've just pushed some more changes which now load the tech tree without showing the selector if the tree selection file already exists, so the options look something like this: If the tech tree selection file exists -> Load tech tree Else -> Show tech tree selector -> Create a tree selection file for the savegame based on selection If, for some unknown reason, at any point the chosen tech tree is invalid, revert to the stock tree. These latest changes pretty much complete the functionality objective I was aiming for so I'll largely just be testing this now while you fiddle with it until you're happy with the final result.
  15. Fractal_UK

    [0.25/0.90] TechManager Version 1.5

    I've now added the option to select the stock tree in the menu and created a .cfg file (in the savegame folder) that stores your selection of tech tree. If, for whatever reason, it can't find tech trees it will always default to using the stock tech tree. To answer your earlier question anonish, I try to avoid directly writing to the persistent.sfs file because something just feels unsafe about manually iterating through the nodes and writing bits and bobs to them. It's a very unlikely circumstance that doing so would destroy someone's savegame but I don't want to risk being responsible for that so I prefer to use a distinct file for plugin-specifc stuff. Obviously you're free to edit my code to make it use the persistence file directly if you prefer, it's just one of those things that I, possibly irrationally, avoid at all costs. I chose KSPITechTree and the result was the creation of a new "TechManager.cfg" in the savegame folder with content techTreeID = KSPITree useStockTree = False Next thing to do is make it read the cfg file before showing the popup and it should be fit for consumption. Updated Source