Fractal_UK
-
Posts
1,702 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Fractal_UK
-
-
The BASIC_NTR_PROPELLANT nodes control only thermal engines (either standard thermal nozzles or upgraded thermal turbojets in propellant-using mode). There are separate config files for plasma and ATTILA thrusters, and the Vista kind of does its own thing.
Here's the rationale for capping the Isp of thermal rockets: the Isp being proportional to the square root of the operating temperature is based on the physics governing thermal rockets at fission-reactor temperatures. 3000 seconds corresponds to the temperature where the heat is enough to ionize the propellant or destroy a non-magnetic nozzle, meaning the low-temperature equation is no longer realistic above that point.
Adding the limit makes the combination of antimatter reactor/generator/plasma thruster more interesting, and it makes the combination of multi-gigawatt reactor and thermal rocket more useful for high-thrust cargo-to-orbit applications.
We do lose some of the things we were used to doing with unrestricted thermal rockets. Some of those were unrealistic enough that any direct replacement should come from a softer-science mod and not Interstellar. Some can be adequately covered using other Interstellar engines. For some, there are approaches based on sound theory that the community could model within the spirit of Interstellar.
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.
Could someone do me the favor of explaining like I'm a small idiotic child how to get the DT Vista engine to work? My density has surpassed my expectations.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).
-
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.
-
So.. I just realized that all thermal jet/rock nozzles are now worthless with antimatter. 300isp max now? So, <1/2 what it was for 1.25m, a little over 1/4th what it was for the 2.5m, and only 1/6th for the 3.75m. Uhm... ok. There goes all of my fun/best craft.
~Steve
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.
-
Worked perfectly, thank ya kindly!
~Steve
EDIT:
One more dumb question, if I may - Is KSPI set so that we can sell back all resources that we mine/farm, to include antimatter? Just curious before I set up any large infrastructure to test it out. aka... are there buy back prices set for all resources?
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.
-
Fractal, good to see you posting again.
Did you notice my list of fixes/changes/suggestions a little while back? They're in this post, and the one immediately after it...
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.
-
Sorry, I may not have been clear before. As you can see by my screenshot I have a receiver pointed directly at a transmitter. Both have been activated, and those girders you see have been separated, so the receiver and transmitter are two separate vessels. The receiver however still does not open itself though, so I don't know what's going on.
If you switch back to the space centre (leaving the transmitter on), then back to the vessel, does it start to work?
-
Again, its sub-optimal some of the time in some circumstances, not all. It is the best available option in some as well. At least, I'm trying to see if that 's possible. There are certainly still issues to work out. But its not hard at all to imagine small sub-trees that only add a couple techs that branch off of stock (or even CTT), but where the developers don't want to or can't get CTT updated to include those techs. And they definitely wouldn't want to include an all encompassing tree that includes CTT / stock / a bunch of mod's parts they have no control over. Some ability, one way or another, for developers to provide sub-trees could be very useful. In-RD tree switching would avoid the 'you got your tech on my tech' problems as well as allowing everybody to worry about their own techs without having to worry about everyone else's. This is not isolationist. Isolationist would be refusing to consider the CTT, not considering it but choosing to go another way if its a bad fit or unresponsive.
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.
-
We already had this discussion and you were proven incorrect
It broke into oblivion with the same DLL. We covered this. We were ignored. Now, if you would like the last word please feel free to take it, otherwise PM me or answer that question about atmo definitions over on the ORS thread. I'm genuinely curious if the issue I noted is still the case.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.
-
For the record, it broke horribly with duplicate keys. So when we had to fix it for 0.24.2 in your absence, we patched it. Then upon your return you up-versioned the fork, ignored the fix the community had made in your absence, and rebroke it. And broke interfaces to SCANSat and the resource overlay along the way (i.e. people who were actually trying to extend it's functionality), and pretty much ignored any attempt at communication.
Last I checked, ORS atmo definitions (which were never broke) were to require a player to select which definition set to use. Has that changed and will ORS now allow a player to have two different atmospheric definitions operate simultaneously then? Would be good to know, since that last tweak pretty much rendered ORS useless for anyone playing with two mods that wanted to define atmospheres. Less important for me personally as I learned my lesson and forked, but might be important for other people to know who might want to consider using the original fork.
(EDIT) And feel free to PM me, or (since that has not worked in the past), feel free to address this in the ORS thread.
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.)
-
The context of those statements was in using tree-switching as a way to have multiple trees simultaneously. And it's sub-optimal. If a mod played nicely with CTT... they would either use CTT, suggest a new node for CTT, or be a perfect puzzle piece of goodness with no overlaps or confusion. I am not confident in that second bit
I will bet a cookie that within two weeks of launch, we have a tree conflict which in turn is going to a mess in our mod threads. But that's for modders to sort out among themselves (or through pressure of our user base) - there's no bit of curly braces that will make people play well together.
Not saying it's a bad thing to switch trees on the fly - it's an excellent feature, and vastly better than forcing a single choice (which is horribly bad). But it's not an optimal solution (And I don't mean that in a negative way, just that as you said yourself, given the choice between a shared tree and this, the shared tree is better). Still, much better than what we have currently and it's a perfectly valid fallback (similar to how our fallback for resources works today, or how ORS used to work before it was broken as a multi-mod system).
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.
-
Yes, I did ask as well. I prefer now to wait for an official release... There's so much little patches in the 10 last pages and it's quite confusing. A lot are just workaround the issues and not real fixes for everything so I'm a bit lost as I don't master the structure of files, neither I do program in C# or understand everything people do around here.
And sorry if I sounded harsh in my answer. I'm french and my english is far from being perfect.
Anyway, this is a great mod I already installed in the past and I hope it will be updated soon !
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.
-
I am delighted to see this. Thank you *so* much. I've scanned the last eight pages of activity, and have just a question and an understanding check:
1) Is this up on GitHub anywhere? I can find FractalUK's fork, but not the original.
2) Is my understanding of existing discussions correct that we'll be moving towards a ModuleManager accessible approach, and it won't require a tree.cfg in the user's save directory?
The second is something I'd desire greatly, because it means that mods can supply updated tech-trees with each version, allowing tech-tree developers to not have to get everything right on their very first go.
For those folks using the CKAN pre-releases, this can now be installed with `ckan install TechManager`. Our cloud of bots should pick up new releases from KerbalStuff automatically.
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.
-
Fractal_UK, notice how your combobox is flush with the bottom and to the left? I've been working on that, using GUILayout.getRect to reserve some space and changing the interface to combobox. It looks a bit nicer this way, imo, but the extra code is bit heavy for the result.
As for the stock option, I was just planning on having TM try this: look for trees in GameDatabase, if there are some, show a selector to choose one, if nothing there check the save dir for tree.cfg, if thats not there, do nothing. I'll obviously look at your new code and go from there.
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.
-
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 = FalseNext thing to do is make it read the cfg file before showing the popup and it should be fit for consumption.
-
@Fractal_UK
I'll go ahead and address the next elephant in the room since it was not clear form your post. Is it your intent to:
(a) participate in the community tree so users can use USI mods, NFT, and KSPI simultaneously (and given the efforts other folks have spent making this happen, it appears to be where the users want to go)
(
keep KSPI as it's own tech tree without interop with the Community Tech Tree© Do both (participate in the community tech tree and also have a KSPI-only tree)?
It would be good to address this now as it likely affects how Nertea is laying things out.
(Edit) I don't see why the community tech tree would have MM configs? The entire point is that a set of common nodes and their relationships is defined, and the mod authors drop their stuff in there as part of our regular configs - i.e. I don't see it as a special case, more just a largish tree that multiple mods share.
My concern, and hopefully it turns out I am incorrect, is that we will miss the interop boat again.
c) Seems like the logical choice. I'm assuming, for the time being, that Interstellar would be distributed with its own tech nodes and nothing else and that the community tech tree would be distributed seperately as almost a distinct mod. I'm not, in principle, opposed to distributing a community tech tree with Interstellar though it would depend on what the final result looked like.
-
I've posted my latest work on the other thread. It still needs to actually save the user selection to a tech tree selection file but it's otherwise pretty much there.
-
Here is the current state of the source code for this: https://github.com/FractalUK/TechManager/tree/master/TechManager
-
I'm working on some modifications to the TechManager so that it's possible to simply select a tech tree from a selection of tree.cfg files installed in the player's GameData folder.
You define tech trees as follows, using the "id=" part to determine the unique name that you want your tech tree to have, the user can then select between all of these possible trees for a given savegame.
TECHNOLOGY_TREE_DEFINITION
{
id = KSPITree
NODE
{
name = newnode_7144
techID = interstellarTechFusionPower
pos = -404.5,1175,-18
icon = NUCLEARPROPULSION
cost = 3000
title = Basic Nuclear Fusion
description = This technology represents the first steps into fusion power using large reactors compressing a plasma with large magnets or initiatiating the reaction with tiny quantities of Antimatter.
anyParent = False
hideIfEmpty = False
parents = node6_nuclearPropulsion,node7_metaMaterials
PARTS
{
name = FNFissionFusionCatReactor
name = FusionReactor250
name = FusionReactor375
name = KSPIMagneticNozzle1
name = KSPIMagneticNozzle2
name = KSPIMagneticNozzle3
}
}
NODE
{
name = newnode_71440
techID = interstellarTechFusionPower2
pos = -321,1063.667,-17
icon = NUCLEARPROPULSION
cost = 3000
title = Advanced Fusion Power
description = The development of Inertial Confinement fusion technology allows the miniaturisation of fusion power as well as the production of massive new engines that really unlock rapid transit throughout the solar system.
anyParent = False
hideIfEmpty = False
parents = newnode_7144
PARTS
{
name = FusionReactor0625
name = FusionReactor125
name = vista
}
}
.....
}You can see the results of this here when I make two tech trees - KSPITree and KSPITree2.
I'm still working on the code and it isn't finished yet but the idea is to save the results of this choice into the savegame folder so that the user can have different tech tree choices for different save games.
The result is that individual modders can distribute a set of tech nodes required to play their own mods or larger projects aiming to unite tech nodes can distribute packages allowing players to play with the tech nodes from multiple mods at the same time.
-
I have a possible solution for the woes of how you can determine which tree you want to use. This is just the beginning of a possible solution but I have made some changes to the TechManager source code that make it load nodes from a .cfg file in game data instead of in the savegame directory.
You wrap the nodes inside a TECHNOLOGY_TREE_DEFINITION{} node which has an id = to determine which tree it belongs to.
On my current changes, the mod will load only the first tech tree definition but it's pretty trivial to make it able to select between different options. Example node structure:
TECHNOLOGY_TREE_DEFINITION
{
id = KSPITree
VERSION
{
id = 2
}
NODE
{
name = newnode_7144
techID = interstellarTechFusionPower
pos = -404.5,1175,-18
icon = NUCLEARPROPULSION
cost = 3000
title = Basic Nuclear Fusion
description = This technology represents the first steps into fusion power using large reactors compressing a plasma with large magnets or initiatiating the reaction with tiny quantities of Antimatter.
anyParent = False
hideIfEmpty = False
parents = node6_nuclearPropulsion,node7_metaMaterials
PARTS
{
name = FNFissionFusionCatReactor
name = FusionReactor250
name = FusionReactor375
name = KSPIMagneticNozzle1
name = KSPIMagneticNozzle2
name = KSPIMagneticNozzle3
}
}
NODE
{
name = newnode_71440
techID = interstellarTechFusionPower2
pos = -321,1063.667,-17
icon = NUCLEARPROPULSION
cost = 3000
title = Advanced Fusion Power
description = The development of Inertial Confinement fusion technology allows the miniaturisation of fusion power as well as the production of massive new engines that really unlock rapid transit throughout the solar system.
anyParent = False
hideIfEmpty = False
parents = newnode_7144
PARTS
{
name = FusionReactor0625
name = FusionReactor125
name = vista
}
}
.....
}https://github.com/FractalUK/TechManager
(anonish, your license is included in the source code)
Edit: Drop down box tech tree selection could be restored pretty easily by showing a selection box for the above nodes instead of FirstOrDefault()-ing
-
There's also a new mod that replaces treeloader and works with tree.cfg files, it's called TechManager and it fixes this problem entirely, including adding the new nodes and everything.
Evidently someone has had more success than me then! On the plus side, now I can get to work on creating a fixed release rather than working on the fix itself. I have a pretty busy week going on this week and worse next week so will try to squeeze some hours in on it when I can and hopefully get a fully operational release out again to tide you all over until I can get back to work on proper new features.
-
Just thought I'd report a nuisance/bug: When researching techs in the R&D, I get the following error message in the log:
TypeLoadException: Could not load type 'SpriteRoot' from assembly 'Assembly-CSharp-firstpass, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.
at TreeEdit.TreeLoader.Update () [0x00000] in <filename unknown>:0
When I click research, I also have to leave the R&D and come back to see the tree properly updated.
It's a TreeLoader issue, I can't fix TreeLoader myself because of the license restrictions but I am working on using ATC as an alternative - at the moment it doesn't support adding new tech nodes but since that is a more open project, I'm trying to add that capability to it.
For now, you can just delete TreeLoader and everything should work fine in the stock tech tree. You can also download the module manager cfgs in the previous page or two that changes the part upgrades to be compatible with the stock tree.
Hopefully it won't be long until we have a proper solution but unfortunately 0.25 killing TreeLoader is a proving to be something of a maintenance nightmare.
-
Fractal, what's the config you're using to create that new node? I tried copying over your code into my build, but I still get nothing to show up, so I figure it must be an issue with my config.
Edit: Here's the config I'm using... just trying to dump in a single empty node.
@TECH_TREE[stock] {
NEW_NODE {
gameObjectName = random_techyness
icon = START
scienceCost = 0
anyParentUnlocks = False
hideIfNoparts = False
posX = -1000
posY = 1000
title = Random Techyness
description = Some random techy stuff
PARENT_NODE {
name = node0_start
}
}
}Sorry about the delay, I haven't had much time to look at this in the last couple of days. The Tech Node is still a bit fiddly and sometime doesn't seem to appear until I switch scene a few times. I am creating the node with:
NEW_NODE
{
name = node_837498234
gameObjectName = go_node_837498234
title = Test
description = The technology we wanted to start with.
icon = START
scienceCost = 0
anyParentUnlocks = False
hideIfNoparts = False
posX = -1901.18
posY = 596.566
}I am using an entire tree rather than a module manager config but that shouldn't make any difference.
-
The two mods were trying to do separate things. We will reconverge at some point. I plan to have lite be an mm config of kspi eventually the same way I was planning to offer support of different universes through kspil mm configs.
The biggest problem we have right now is this annoying TreeLoader issue, hard to do much of anything until we can restore enhanced tech tree functionality.
-
I've made some progress and manage to get some kind of tech node to appear but it's overlaid by a weird copy that makes selecting it awkward. I also can't seem to get it to draw the lines.
I'd appreciate any assistance!
It broke into oblivion with the same DLL. We covered this. We were ignored. Now, if you would like the last word please feel free to take it, otherwise PM me or answer that question about atmo definitions over on the ORS thread. I'm genuinely curious if the issue I noted is still the case.
keep KSPI as it's own tech tree without interop with the Community Tech Tree
[0.25]KSP Interstellar (Magnetic Nozzles, ISRU Revamp) Version 0.13
in KSP1 Mod Releases
Posted
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.