Bizz Keryear
-
Posts
333 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Bizz Keryear
-
-
->Short notice I am still on 0.6 and since I have read all the posts along the way this post has taken quite a while....<-
It seems I posted it only short before the release of 0.6.This is mostly fixed in 0.6. I've been working on this mod since 0.18, which is why it started out in that structure.
I hadn't realized by the time I released the mod that the official structure had changed, and afterward it seemed like there were a lot more important things to take care of.- One word between friends: This Mod is great by the documentary sucks. Half of the functions aren't documented right now. Or not completely.
I think it sucks (for people like me which instead of memorizing things, constantly looking into the manual) to get informations of some of the features only from the documentary videos.
both https://github.com/Nivekk/KOS/blob/master/README.md and http://kos.wikia.com/wiki/KerboScript are incomplete. IMHO is having a redundant documentary counterproductive. Better keep in one place only, but complete instead. - And my five cents to the steering. It wobbles like hell. Most likely (IMHO) its caused by handling the floats wrong. Even if the if in the program is an exact value is given, the interface should add an tolerance (or so)
Lets assume a ship in space. Its currently stable (not rotating) and needs to turn somewhere. Lets also assume it has not enough torque (to make decent turns). First it has to know how much energy it needs to change the rotating speed since it has to slow down before reaching the desired destination to prevent it from overshooting too much.
While generally you want to apply less steering force as closer as you are to the desired destination, it can make sense to apply more force to overcome influences from the outside.
Wha! I have a picture in mind but its so hard to explain especially since English is a foreign language to me.
Overshooting could be prevented if the amount of motion energy is known.
E.g: [highlight]---motion energy---> + ---external force* x time---> <---available force (aka. torque) x time ---[/highlight]
desired outcome: it should come to stand still at time it reaches the destination.
When you wanting to move towards a desired destination its reasonable to accelerate only the half of the distance towards it. (for simplifying purposes I left out external forces)
When spinning uncontrollable (which means that the craft is spinning with more energy that it can afford before "flipping over" [passing the point which is the furthest away form the destination) has a problem in the traditional handling since (like the sas e.g.) it will accelerate the craft again towards the destination once it "flips over". Like in the highlighted example above a overshooting prevention could slow it down instead.
Its a complicated matter and I myself am only just to grasp it. (And put my ideas into words) - Funny thing: I've just read the wiki article about volumes for the 1st time. I've always wondered why the volume one is only 10Kib big when you have an infinite big Archive. Since I have switched to archive in the prelaunch phase I haven't figured out that its not meant as accessible as soon you are further away.
My suggestion are: 1. only fully accessible (and that includes that you are kicked out as soon you not matching those conditions) in close range to KSP in landed or prelaunch phase. That also means executing files.
If you are off the ground then the comm range kicks in which kicks you out of the archive volume as soon as you leave the range (currently one of my crafts is executing files from archive and its in a about 200km orbit and has no antennas)
Also a low baud rate (copying files will take time) which gets even lower as closer you get to the max antenna range (noise).
Also add an exception for a file named "nextVessel.txt" folder in archive. This is for the reason that you don't always have the time to prepare the vessel manually. The file "nextVessel.txt" should automatically executed the next time a new vessel will be at start. (for copying files in prelaunch and set things up). Like any other file in the archive the execution should be interrupted as soon as the vessel launches. which actually shouldn't affect any files which this program has launched from volumes on the actual vessel. - And at last but not at least a question: Was there a possibility to control the KSP timewarp with the script or have I only dreamed it? (could swear I have heard it in one of the videos but can't find it anymore anywhere) And if it is, whats the command?
Would be nice to have that linked somewhere central. I am actual too lazy (right now) to do it (set up the highlight) in Notepad++.... So you can use [...] the kOS IDE someone has created (that does syntax highlighting based on kerboscript), ...
Like said above I don't see the reason as long as you can stay in archive....Meaning ones out in space not ones on the launchpad. Once you're far enough away from home, the command "switch to archive" fails.
Well somehow it has to be possible. The changed positions of not active crafts are also be saved / calculated in background. I actually know that other mods, like the life support ones, also doing their stuff in the background. I don't think that its possible to actually execute control commands outside the physical range. But that could be realized with a auto vessel change. (If a vessel has to execute things like burns, rcs translations and stuff you switch [temporally perhaps] to the vessel in case. See "Kerbal Alarm Clock". It could also, like KAC, remember any navigation nodes) Perhaps it may a good idea to have a part-less button in KSP (like KAC, Chatterer, or Steam Gauges) to turn that feature on and off.Relaying is something I've thought of. I'd like to be able to COPY TO target, but not sure yet how doable that is, since I have to save persistence data from the part and parts don't operate outside of physics range.
You could it make generally a part-less plugin which only checks for the part on a vessel and creates virtual instances for them... or so. Which also would make it possible to "remember" the com distance of a vehicle since it doesn't change once it is inactive.
I don't really like RT, because usually you are the computer on board of the probe / vessel so why should there a delay in the execution of the commands...Like I already said in the Remote Tech thread, kOS fits so nicely with Remote Tech that it almost makes me cry. Having to choose at the moment actually makes me cry
But I have to admit it would actually make sense with this...at least in some ways**.... so while kOS is the computer on the vessel which executes the commands directly, your inputs are the remote commands from the control center.
---------------------------------------------
*= like when the center of thrust is off or something alike.
**= doesn't takes Astronauts in account...
This is all only my opinion. I wouldn't bother (or give a f**k) if i won't see any potential or think of it as good in first place.
I tend to piss off people sometimes with the way I phrase things, I usually don't mean it that intense. I hope to be helpful. So please no hard feelings, ok?
-
First thing 1st. I think it is a bit strange for a plugin created after 0.20 to use the old legacy directories.
Instead of <KSP directrory>/plugins it should be in <KSP directrory>/GameData/KOS/plugins
2nd: And somehow this plugin act strange at my side.
I have written this Program:
until altitude > 10000 {
print altitude at (0,1).
print VERTICALSPEED at (40,1).
if VERTICALSPEED > 210 {
set pow to pow -0.02.
}.
if VERTICALSPEED < 199 {
set pow to pow +0.02.
}.
}.
What this code does is printing the speed and the altitude. And nothing else.
However if I remove the second if statement it works just fine. (Except that it may reduce the throttle a bit too much).
I dunno why.
edit: never mind just found out why.
-
I really think that thing is cool, and I will probably add it in as soon as KSP goes 64bit (I am a bit close to out of ram right now)
-
A tiny problem I noticed just now: the fairings work great when I first place them, but when I return from the launch pad to the VAB or I load a ship with procedural fairings, I get this:
Good that you said this. I have almost same problem. Except it doesn't happened with all fairings and oddly all (/most?) of them swapped placed. I used the small bases with 4 nodes to try different shapes, and left 1 segment open. after reloading the open space was turned 45° anti clockwise. Two fairing plates were "resetted", and one was in the same place as another (not resetted one, maybe its one that hasn't moved while all the other have)..
Oh, and the inline fairings can be a little difficult to place sometimes. Especially with the smaller ones because the connection nodes are so close together. They keep 'trying' to connect using one of the side nodes instead of the center one:
I also think that is trouble, but I dunno if you can do really something about that because its a KSP editor problem, maybe if the outer attachment points appear only after placing the part....
-
I just figured out and sometimes it is good looking, that the base determinate how thick the wall is (in the case that you use different sizes of plates.)
I also would suggest to drop the actual size (height) and to make the (normal) base plate more like in the nova punch mod, (well reattaching the parts is not that hard, and for rockets in the air ... well all flights end sooner or later)
edit: one thing I forgot: this mod should get rid of excess attachment nodes for Inline truncated fairings. e.g. if you use the thin bases you have for each fairing 8 nodes where you only use 4, the other 4 are now free to attach something else which leads to oddly floating rocket parts. So the .dll should delete the corresponding node on the other base as long as there is a fairing installed
-
I am not really happy with the fairing shape, so I use basically still the nova ones.
1. Suggestion: Add a description what the parameters in the fairing cfg does.
2. Suggestion: Add a manual, since the keys are piling up it would be great to have them all in one place.
3. Suggestion: edit: a fairing with less excess space especially at the top, without changing the existing form too much sorry missed the R key
-
No matter what, this pack need at least a quick 0.21 fix.
Its way too cool to play without.
btw. I really love the strut decoupler, which has one flaw you can't see (on the texture) to which side it will decouple. it becomes a problem while rotating it. I fixed it that way that I edited the file so it will separate always both sides.
And I also made me a smaller version (just copied it and used the resize parameter) to get one which is compatible with the stock parts.
-
Please, please, PLEASE, pretty please upgrade this mod to 0.21 (its totally broken).
I can't life without it anymore.
So if you don't want to have my blood on your hands....
-
What this mod clearly needs are (beside from a update to 0.21 even if its in name only) example crafts.
I have no clue how to put those things together. And when to use what part.
And especially I have no clue how to bring all this (without a mod) to a place where I need it. e.g. Mün.
You should also consider a future compatibility when the drag is changed. it is rather unpleasant to have a (folded) launchpad with parts sticking out that much.
I really would love to use this mod, but got no clue how.
-
I really love it, but it keeps overshooting and the physics are kicking in too hard.
Lost several times my engine or other parts.
You should, instead of "is current time >= alarm time", calculate in how many (RL) seconds, with the current warp, the alarm will be reached.
And also slow down the warp to 5x before pause or kill the warp. (this prevents to kick in the physics too hard)
P.S.: I am using 2.1.0.0
kOS Scriptable Autopilot System 0.9
in KSP1 Mod Releases
Posted
And just assume Voyager that way:
What i am meaning is it makes sense to steer remote toys like that. Toys that are in close range. But it doesn't even make sense to control low orbit spacecrafts that way, cause at some point yo lose connectivity for a short while. And landing on a celestial body would be impossible due the latency. Instead they get commands like in 10km height start the decelerating burn and if you are strait up keep you down speed nice and slow until you touch down.
It is really actually so that (IMHO) that what the computers in a real spacecraft do, does in KSP the player ... or Mechjeb ... or to have a little more fun kOS ...