allista
-
Posts
2,208 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by allista
-
I've played a bit with this lander and found some bugs and landing algorithm flaws; in the end I was able to achieve the proper emergency landing (normal landing was working all along). I've also added a status message that warns the user if TCA "thinks" that there's not enough fuel to land; it appears after the initial trajectory calculation and pauses the landing sequence until dismissed by clicking on it. And in "advanced" pane there's now an option to autosave the game before landing attempt is made (it is on by default). I'll post the update for testing in a bit... Done. Look below the video. TCA-3.2.0.1 with another set of fixes to Orbital Landing @drhay53, I've also changed status messages for on-planet landing autopilot to be more verbose; this may help us to catch the bug you've found. Before that some messages were displayed across multiple internal states, so the "Checking landing site..." was pointing to several places in the code.
-
I've managed to get it work: removed KAX and Mk2 expansion to free memory and installed full MKS. But I can't reproduce what you describe; the lander either lands normally, or uses emergency landing when there really is not enough fuel left. And in the latter case it brakes in time. Don't know what to think. But it's late already, so I think it's best to let it rest for now...
-
Alas, can't load it either. Installed SpaceY lifters and MKS Light. Will try full MKS and Y-expansion. By since i'm on 32bit system, my part capacity is very low: Could not allocate memory: System out of memory! Trying to allocate: 1134080B with 16 alignment. MemoryLabel: TempJobAlloc
-
@drhay53, cool, thanks for the testing! I have a 3-month old dog now, which is somewhat comparable in this case So the USI somehow prevents correct determination of remaining fuel. Stock lander with only monopropellant thrust there's no such issues: I've tested it specifically, for fill tank and normal landing and for almost empty tank and emergency landing: the last-minute suicidal burn works fine on Mun, Kerbin and Duna. Could you post the craft file of your lander? Is something except MKS required?
-
@drhay53, could you, please, test the landing with your crafts and scenarios using this fixed version? I'm afraid the decision tree of the algorithm is still very overfitted and in many cases may fail; do try to brake it! Anyone else who wish to join in testing, by all means, please do! TCA-3.2.0.1 with fixes to Landing (both orbital and normal), Attitude and Bearing controls. Oh, another thing: the new version is compiled against my utility library which is included and required. Also, as this library, among other things, automates plugin configuration, the Globals and User configuration files are now named as a corresponding plugin; in that case they are ThrottleControlledAvionics.glob and ThrottleControlledAvionics.user If you had some customizations made, don't forget to rename the User file; and, if you haven't done so yet, to move there all the changes from the Globals.
-
That's how it looks like now: EDIT: With the 14k orbit it looks exactly the same.
-
Oh, how I want TCA to be reliable... In TCA.glob under DEO node there's the StartPeR option that sets the initial periapsis in parts of celestial body radius. The less this value, the more sharp trajectories are searched at first. If none of them fits, the desired periapsis is increased.
-
1) No, terrain is always accaunted for. 2) That is partially the case: TCA calculates theoretically correct value; in practice, however, many factors change actual braking time constantly. I replaced this calculation with the calculation of total burn time which is almost two times bigger, and in my tests it works better with the last craft that you provided on the screenshot. The price is the early braking => more fuel required overall. 3) That is also true: I noticed that you were landing from a very low orbit (14k); presently, deorbiting trajectory is defined by periapsis. Curvature of such trajectory if, obviously, is not invariant with respect to starting orbit height. I now have replaced this with the deorbiting trajectory of constant eccentricity; thus ensuring much more constant landing curve. But when your target is far out of the orbit's plane, descend necessarily becomes more and more shallow. Only one way to avoid this: change the plane prior to descend. But then again, it is less fuel-effective. I'll made a short video to demonstrate the current state... What d'you mean by "uninstalled the mod but it's still happening"? Have you uninstalled TCA?
-
Found and fixed this. I have been incorrectly estimating angular drag factor, but in manifested itself only with the rotors, which have huge surface area (as they are actually full circles).
-
I think I'll go hang myself This is so frustrating...
-
Series of screenshots would be fine; even a single one with the craft would help me to test things. Shallow descend is strange, there are limits for the curvature of the deorbiting trajectory. Unless you've been trying to land on a pole from an equatorial orbit, TCA should pilot the ship sown more-or-less sharply. I'm confused
-
I've tried to reproduce it without success, so it should be something to do with particular craft design, other mods, etc. Could you try to reproduce it on a similar, but all-stock design? And if you succeed, share the craft?
-
Could you show the crafts, or, better yet, make a video of the event? Landing module is very complex and despite the fact that I was testing it with two very different crafts on Kerbin, Mun, Minmus and Duna, it may not account for everything. Do you have enough fuel and the problem is the timing of the burn? Do you enable TCA in midflight? O_o If so, then look at the state of "Hover", "Follow Terrain" and especially "AutoThrottle" switches.
-
Thanks, will investigate it now
-
No, you're right, this has to be TCA. BTW, you craft file requires something other than the KAX. With it installed I still got the "vessel has some invalid or missing parts" message.
-
May it be that the KAX itself is the culprit as it was not updated to 1.1.3 yet? Of Firespitter for that matter.
-
I'm sorry to hear it Could you share the .craft file or a screenshot? I have changed many things, bearing PID parameters and their runtime tuning among others. I've tested it on several crafts of different mass and torque and all looked well, but apparently I've miscalculated something. Meanwhile, you may look at BRC node in TCA.glob file and try to change something there...
-
Looking at Squad's part configs I start to wonder: what is less painful -- to use stock modules and live in fear of them changing one day and face the need to rewrite tones of the config "code" for which there's no IDE, autocompletion, error checking and all; or to invent a bicycle each time I need some near-stock functionality and fear the same thing, except that for a Module I do have all the benefits of IDE. Keep in mind that neither part configs nor KSP API have any kind of reference manual, so for both, in order to understand which option does what, I have to decompile KSP assemblies, decode internal strings and clean things up for the code to become more-or-less readable. Writing configs is a "content creation" as opposed to Module programming which is... programming. Generally, good programming leads to fast and easy content creation which thus becomes preferable (that's exactly what Unity had done). But in Squad's case they, apparently, had no intention of making KSP truly plugin friendly. All the plugins and part mods without exception resulted, to some extent, from KSP reverse-engineering. In my case I'm talking about Asteroid Hangars -- a part of this mod that was reaaaaally hard to make and of which I privately was proud; not in the small part because my Animator(s) and Generator(s) modules were at the time superior to the stock ones in many aspects. But now the API has changed and they no longer work properly/at all; and I see new, much more sophisticated stock modules. But these new modules are even harder to use (in terms of configuration) and they still have all the drawbacks (which were the prime reason to start my bicycle-making). So I really don't know what it is best to do. Dropping auxiliary parts was one thing, but to drop half the functionality because Squad exercises extreme programming (they don't even bother with class inheritance, copying the same code from one module to another)... well, I doubt I'm ready for that.
-
I will repeat here what I wrote on YT: TCA 3.2 is compiled against KSP-1.1.3 and is incompatible with 1.1.2. You need to use TCA-3.1-KSP-1.1.2.
-
It would seem that space agencies don't play KSP Yes, VTOL Control is there (see the ChangeLog in the post). Docking support... it would be a fine challenge, but it is not directly connected with thrust control, so for now I'll pass. Besides, there's another mod that desperately needs my attention
-
TCA v3.2.0 for KSP 1.1.3 (2016.06.28) ChangeLog:
-
Thanks. Yep, I haven't updated to 1.1.3 yet, sorry. I hope to do it today.
-
It's settled then! I hope I will be able release the beta for 1.1.3 before my vacation in July.
- 1,633 replies
-
- 5
-
-
- part count
- storage
- (and 1 more)
-
Ahhh! I'm an idiot. I was assuming that they won't be releasing KSP-1.1 on their site anytime soon, because "it is still in testing" as they wrote then; so I only checked the Steam version, which is still 1.1.0 for linux. Thanks for pointing me to this: I'll grab it from Squad directly
-
Everybody posting 1.1.3 updates... I still don't have KSP-1.1.2 for linux. Is it really so hard to recompile the same code for yet another OS? It's Unity we're talking about, not some platform specific C code. I'll try to setup things under wine to be able to test TCA for 1.1.3, but that may or may not be possible. EDIT: Sorry, it turned out I was wrong.
