Garek
-
Posts
257 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Garek
-
-
6 hours ago, Daishi said:
The core is coming in the next update! Ideally we'll get these solar panels, the radiators, the probe cores, and the science parts finished and pushed as one set. Easier to work on multiple parts at once, visual design ends up being a little more consistent when you have a few things in front of you at one time.
Awesome!
6 hours ago, Daishi said:I've been busy with IRL stuff so i'm not really working as fast as i'd like, but that seems like a pretty common excuse for me nowadays.
Don't worry, this is "just" a hobby for all of us
6 hours ago, Daishi said:Branching into a new diameter is a huge can of worms though, but we are missing a few adaptor profiles so i'll have a think about how i'd approach it.
Yeah, I expected that to be a bit more complicated, thank you for considering it for the future!
-
So... this is all awesome. But may I ask what happened to the ProbeCore you showed earlier? Still WIP?
What would also be awesome would be larger diameter cores (there are some 3.75m capsules in Near Future Spacecraft for example, also think avionics/RCS/Power package for larger boosters) and adapter fairings for the remaining size transitions, but I understand that would be a lot of modelling work away, even if you want to do that
-
So I'm trying to extend the PartVariant Sytem to IVAs via EXTRA_INFO and my own PartModule.
So far I managed to grab that EXTRA_INFO when changing variants in the editor and persisting it to flight. I also manged to get rid of the regular IVA when spawning in flight by doing:
part.internalModel.gameObject.DestroyGameObject(); part.internalModel = null;
What I'm still stuck on is
-
how to set the new IVA?
- part.internalModelName seems to be ignored, regardless of when I set it
- part.AddInternalPart(<ConfigNode>)... even if that were the right option, what kind of ConfigNode would I feed it?
- how to make that IVA then appear. I tried some combinations of CreateInternalModel, SpawnIVA and internalModel.Initialize, but that didn't seem to do anything. Might be related to 1., but I don't see KSP complaining about not finding the IVA in the log.
Anyone got any ideas?
-
how to set the new IVA?
-
Something I just realised, you can actually do OOP in kerboscript:
set foo_a to list().
set foo_index to -1.
function foo_new {
parameter a.
foo_a:add(a).
set foo_index to foo_index + 1.
return foo_index.
}
function foo_geta {
parameter this.
return foo_a[this].
}
function foo_seta {
parameter this.
parameter a.
set foo_a[this] to a.
}This is a script implementing a class foo which has a single field a and access methods for it. Of course, compared to languages actually designed for OOP it looks horrible, but the semantics are there!
EDIT: fixed stuff. Still, this is off the top of my head, without actual testing.
-
but from what I can tell, CKAN is the universally accepted mod managing tool.
You are wrong there. Yes, CKAN is the most accepted mod managing tool. But not every mod author actually manages the CKAN entry for his/her mod. This leads to CKAN not installing the mod how it's supposed to be installed and messing things up. Which doesn't exactly increase it's popularity with people like Ferram who understandably would prefer other people to not mess up their work and cause unnessecary error reports.
Yes, manually managing 50-200 mods is a PITA, but it is the most reliable method of modding KSP, since there actually is no universally accepted mod manager. Also, most of the time, you just need to copy the mod directory to KSP/GameData and maybe delete the old one if you're updating, which is not that hard.
I personally have made my GameData a git repository, with a lot of branches and a bit of scripting. I don't recommend this unless you have experience with git and shell scripting, but if you do, it's pretty nice for mod management.
-
If you stack a lot of structural panels on alternating edges like /\/\/\/\/\/\/\/, they could propably act as a spring. I think I saw this in some ksp video and it worked surprisingly well. Of course, that's a lot of parts per spring, you need TweakScale to get springs with other diameters than 1 and 2 m. Also it won't stop at fully compressed because there is no self-collision, and instead compress further through itself until the connections break.
-
I also had KSP crash on me, output_log.txt said it crashed while 'compiling' the 1.25m heatshield. But after I removed DRC, it crashed on another Part, somthing from HGR, so I'm still investigating.
Oh, with HGR removed and DRC 5.2, it crashes on the .625m heatshield. Hmm. I will continue removing/adding mods until I'm reasonably sure which causes the crashes and post my findings.
EDIT: should propably have mentioned, I'm running the windows x64 build with a ton of other mods.
EDIT2: It appears to be this: http://forum.kerbalspaceprogram.com/threads/87049-x64-crashing-due-to-access-violation-error
-
Yesterday I installed KSP again (after a break because of...stuff) and started reinstalling Mods. Then 24.2 hit and broke some stuff _again_. So I went to sleep and when I got up this morning, I had e-mail updates from Kerbal Stuff that FAR had updated and DebRefund is compatible. Thank you so much just for that feature!
EDIT: "You must spread some Reputation around before giving it to SirCmpwn again."
-
STOP DISTRIBUTING OTHER MODS WITH YOUR MODS!
Add a required section! with links to required mods! so that we don`t override newer files because you didn`t update the ones that came with yours!
Module manager, Firespitter, KSPAPIExtensions.dll, scale.dll, b9/KW mm cfg`s and lets add for last out of my head RealSolarSystem.dll
If you actually would manage to install all dependencies for your mods, and their dependencies, IN THE CORRECT VERSIONS, IN THE CORRECT FOLDERS, I think you are equally capable to open the downloaded archive, and look at it's content to determine which dependencies are packed in.
Also:
- Module manager can't be overwritten by older versions because the dlls have the version in their filename. If by accident, multiple versions are present, the newest one is used.
- KSPAPIExtensions has a similar mechanism afaik
- the whole point of mm cfgs is that one mod may modify another, and there was a lot of work invested to make them as compatible as possible with each other
Keep in mind, a Mod is not a regular application. In fact, if it were, it would always bring it's dependencies with it in some form or another.
A Mod is a MODIFICATION of the game created by a community member. This always implies:
- It's a free piece of difficult work. Critisism may be necessary, but don't demand a technicality to be implemented in a certain way just for your convienience
- It may break things. KSP's API is insufficiently documented, it has bugs, and most Mods have no proper Q&A (again, because they are free).
- Stacking mods is even more likely to break things. Software even has bugs if all people working on it work within 20m of each other. With multiple mods, you have Squad providing the base and every modder building a bit on top of that - and often, on other mods.
If you don't understand what modding actually does to your game, you have equally little right to demand stuff from modders, who offer a piece of hard work for free. And the more you understand, the more reasonable suggestions you are able to make - and you are also more likely to just fix stuff yourself.
Also, about bug reports. About every author wants the output_log.txt alongside a bug report, and yet, people have to be always reminded of that. It's not like professional, sold software were there is first level support paid to walk everyone through the basics again. You are talking directly to developers here, and they can fix a bug a lot faster, if you find out as much as possible about it, and provide all the information.
I work as a software developer, it was a long day, I'm sorry if this became a bit of a rant.
- Module manager can't be overwritten by older versions because the dlls have the version in their filename. If by accident, multiple versions are present, the newest one is used.
-
To me ESA is just Germany,France and Italy being a parasite to other country's funds and talents and claiming their glory.
I wrote two rebutals of this, but they rapidly devolved into rants.
Now I will just say that I would like to understand how you got that opinion, if you would care to explain?
(As long as this doesn't get us into trouble because it would be too political)
-
I think this could use some kind of car jack to make the wheel deployment less...wobbly-springy?
-
I knew that thread, but as I read only the first few posts I thought it was meant for the RftS mission reports, and not RftS mod discussion.BTW, RftS has it's own thread and you would likely get better, quicker info back posting there.Garek: here is the spreadsheet I use to generate RftS engines. It lists all RftSized rocket engines.All the info I wanted and even more
For future reference (and new guys) it would maybe be helpful to add this link, and the one for the real engines stats, to the OP.or want more "options" than actually-produced engines provide you with (and note "produced", not just "designed") then you might want to use RftS.That's exactly my point, so I will use RftS in the future.
Interestingly, it's possible to use multiple-ignition engines as lander engines, assuming you bring a lot and they have many ignitions. Place, say, 12 engines on your lander. As you want to decrease thrust, shut them off in pairs. If you get down to two, use their multiple ignitions to toggle them on and off to balance your thrust.(Note, this is basically how a lot of reusable rockets with propulsive landing were planned to work, i.e. ROMBUS: it had 36 engines, of which 4 would be reignited a few seconds before impact to slow from terminal velocity to a gentle landing.)
Interesting concept, I might implement that with some scripting. (No, not kOS, at least not until it gets proper functions. Maybe kRPC or something like that.)
Mar's atmosphere is...not really relevant. You'll maybe lose 10-15 seconds of specific impulse, and 3-5% of your thrust.Good to know.
Thank you both for your helpful replies!
-
I'm reposting this since it apparently got buried in people arguing over MechJeb data (I'm sorry if this isn't okay):
2. Lander descent engines are designed to be "deeply" throttleable, that is down to a few to ten percent of their rated thrust. That includes the LMDE, some in-testing variants of the RL-10 designed as the cryogenic successor to the LMDE, and...that's about it. Oh, and the stuff used on, say, Viking.You can see right here the list of engines and their throttleability
[...]
Because, in RftS, I don't know what engines people plan to use for their landers, I'm much more generous about throttling. But this is RO.
So with Real Engines, the LMDE is the only engine good for landers bigger than probes, and if one wants to have a greater variety of lander engines, RftS is recommended? e.g. for bigger stuff/higher gravity, atmospheric landings, ... (is Mars atmosphere relevant for ISP?). Or would that be the point where it's recommended to do a little research and 'build' (-> create .cfg) appropriate engines myself?
By the way, is there a engine list for RftS similar to the one for RE you posted there? That would be helpful for deciding which pack to use.
-
2. Lander descent engines are designed to be "deeply" throttleable, that is down to a few to ten percent of their rated thrust. That includes the LMDE, some in-testing variants of the RL-10 designed as the cryogenic successor to the LMDE, and...that's about it. Oh, and the stuff used on, say, Viking.
You can see right here the list of engines and their throttleability
[...]
Because, in RftS, I don't know what engines people plan to use for their landers, I'm much more generous about throttling. But this is RO.
-
I dont see that path anywhere, I have looked the 2 places that come close don't have .config
files and directories starting with a dot are hidden per default on linux. Just copy "~/.config/unity3d/Squad/Kerbal Space Program" into whatever explorer-analogue you use. Or a shell. In the latter case, you will want to include the quotation marks, or it will break on the spaces.
-
Another thing which came to my mind: what about savegame compatibility?
If one starts a savegame now, with the regular patched conics, and later, when this mod is ready installs it, what would happen to crafts already in space?
I'm especially interested in
a) craft that is meant to stay in a certain orbit over an extended period of time, e.g. stations, communictation satelites. So 'closed' orbits around a primary body, clear of any orbiting moons etc.
a savegame using RSS instead of the stock System, if that makes a difference (I'm really not a astrophysicist ) -
This means there will be separate x86 and AMD64 builds for each target operating system (Microsoft Windows and 57 varieties of Unix), possibly more if we decide to do specific optimisations for Intel chips (though ICC is not cheap).
(Emphasis mine)
You actually want to do ~116 builds? I mean, automation helps, but the sheer amount of binaries would be...impressive. I use manjaro and personally would be okay with building myself from a Makefile (which would propably be the same at least for everyone using the gcc toolset).
-
- Users get emailed when mods update
This is my most wanted feature from a mod repository ever (yes, I'm a mod user only).
As for the design, it may not be impressive, but it doesn't need to be. The site primarily needs to be functional, and that seems to be the case. Just one thing: the full-picture background is nice, but it gets annoying when you want to read a mods description. You could maybe put all the text parts in boxes like the mods on the 'browse' page, that helps with reading and still allows a screenshot-based background.
- Users get emailed when mods update
-
Nowadays (since 1975) it's adapted to the international conventions and 1.000.000.000 is just a billion like to all other people.
Fun fact: in german, it's
10^3 = Tausend
10^6 = Million
10^9 = Milliarde
10^12 = Billion
10^15 = Billiarde
So actually, pre-1975's British system was more similar to the German than the current one, just missing the "Milliarde" etc. Also, it's a bit confusing to switch between German and English while speaking/reading/... about big numbers
-
Well, the basic launcher system is just a really small mass drive. I've seen at least one mod trying to implement a mass driver somewhere around here. You could dig that up and use it as a basis for a ship-based 'linear canon' (afair that's how they called the mass driver). That would be quite interesting, you could build orbital mass drivers with that. The in-flight assembly on the other hand...it propably would be a PITA to implement, the existing autopilot mods weren't that good at atmospheric flight OR docking, the last time I looked (ok, that was like .21
). And it just doesn't fit right with KSP, I have to agree to the others there. But well, I also think weapon mods don't fit right with KSP, and there is still a considerable amount of people who happily use them. So if you think it has potential, you might as well try it. Just don't expect it to be highly praised by the regular KSP community.I'm sure there's some technical Japanese reason why they launch all the pieces separately and assemble them under enemy fire...The only Gundam series I watched ("Gundam Seed" without the Destiny) of course wasn't realistic either, but they at least had the common sense to finalise assembly inside the carrier.
-
and then reenters with MechJeb is set to Prograde vector to keep the heat shield orientation.
Are you sure MechJeb is holding surface prograde? If it's holding orbital prograde, the difference between the two could be large enaugh to cause problems. Also, when using FAR (and assuming that probe is aerodynamically stable shield-first) you shouldn't need to have MechJeb holding heat shield orientation. Just make sure you come in heat-shield first, then it should hold orientation by itself once the aerodynamic forces kick in.
-
I'm running 64-Bit KSP on manjaro (Linux), using a lot of mods (including RSS/RO, most recommended Part Mods and a bunch of utility stuff). KSP reliably hangs the second time I go into the VAB, especially when reverting from flight. Since KSP in this configuration takes like 8 Minutes to load, this is a giant PITA. I suspect memory usage, because it hangs not only KSP but the whole system, and I know that having to do too much swapping because of high memory usage can do that.
relevant hardware configuration:
Manjaro 64Bit (openbox distribution)
AMD Athlon 2 x4 630 (4 cores @ 3 GHz)
12 GB RAM (2x 2GB, 2x 4GB)
Club 3D R9 270X
10GB Swap on a regular Harddrive (so slooow)
So my questions are as follows:
1) How can I find out how much memory KSP uses? According to top, KSP uses a bit above 10 GB (RES column), but also less then 50% (MEM column). Does the MEM column count swap?
2) Is memory actually the problem here, or are there other issues with KSP that could make it hang the whole System? Keep in mind, everything worked before RSS/RO and associated Mods.
3) Are there any tricks to make KSP run more reliable with my current setup? I don't want to remove mods, and I would like to avoid downgrades of visual quality (i.e. ATM). Sadly, LOD works on windows only.
4) Has anyone experience with throwing memory at KSP to make it work? I would specifically like to know if 16GB would be sufficient (changing the 2GB modules for 4GB ones) or if I would more likely need 24GB (changing the 2GB modules for 8GB ones)?
-
It's still in the works, but from the kOS side. Ask erendrake about it; I don't know the details myself.
As for kRPC, you'll have to ask them to integrate with the RemoteTech API, much like kOS is planning to. It's not something we can do from our end.
Okay, so I may take another look at kOS and wait for integration there.
About the API, it is correct that it will be documented in the manual linked in your sig at some point in the future? That would be helpful for kRPC integration, especially since it may be possible to do as a 'service', that is an optional module for kRPC which could be developed by someone else than the original kRPC dev. E.g. me, provided I manage to find time somewhere
-
So, what about autopilot scripting?
I mean the ability to execute a script with kOS or kRPC 'on the probe' so it gets around signal delay.
I vaguely remember that kOS integration was in the works for RT2, but I lost track of development. I personally would prefer kRPC, if possible.
For future reference (and new guys) it would maybe be helpful to add this link, and the one for the real engines stats, to the OP.
a savegame using RSS instead of the stock System, if that makes a difference (I'm really not a astrophysicist 
Free KSP2 Giveaway!
in Announcements
Posted
I'm excited about the new UI and the work that's being put into UX, and I'm interested how that (and the whole game) will develop with community feedback.
Also, things like warping through burns and multiple assemblies in the VAB seem to imply a lot better foundations both for the roadmap features and possibly mods.