allista
-
Posts
2,208 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by allista
-
I doubt TCA or MJ (or together) could be limited by any modern (raed < 10 years old) CPU or RAM amount. Unity is fast, my code is pretty lightweight and optimized, MJ's, I'm sure, also is. What could cause serious lag is something that spamming exceptions into the log. In that case everything will stutter frequently on I/O-wait, while the logfile is flushed. Ships that don't load are also indicative of some serious problems within KSP installation. So I would check the Unity logs (output_log.txt or Player.log, depending on OS) and GameData for something hideous.
-
More or less: you arm it, you aim it and slowly approach. There're two differences though: There's no pivoting. As soon as the grapple is attached it stays that way until you decouple. As far as I understand, it's the pivoting that caused the sliding. To compensate the lack of pivoting, I have added a new feature: when the grapple is close to the surface and relatively level with it it starts to pull the ship gently towards it, like weak magnet. This helps not to bounce back and to orient the ship closer to the normal of the surface.
-
Try TCA for landing
- 1,554 replies
-
- 1
-
-
- ship construction
- launchpad
- (and 1 more)
-
Thanks for the reports. I'll check them.
-
Introducing Developer Builds! From now on I will publish developer builds in my Dropbox. The builds are compiled with DEBUG flag and are marked by automatic build number (the last number in version string). I cannot promise any particular release rates, but these builds will be coming much more often than normal releases. They will also contain all the latest features. For instance, current build features the ability to load subassembly directly into a hangar and the new asteroid-attachment mechanics. Obviously, these should not be considered stable and should not be used for your main game! But if you want to help the project, you are very welcome to play with them, test them, break them and tell me all about it! Seriously, folks, I need you! Even if I had the time to test everything, I know the system too well and subconsciously evade most of the bugs In particular: @Haifi, could you, please, test the new grapple nodes? I made them backward-compatible with the old ones, so any AsteroidHatch or StructuralGrapple that were in-flight or already attached to an asteroid will work just fine. For your convenience I made temporary part-menu button "Force Decouple" that will decouple even a Fixed hatch, so that you could reattach it if it has slided too far. @etmoonshade, you can test the subassembly loading in Editor. It works just like the vessel loading: through the hangar's UI window, "Select Subassembly" button.
- 1,633 replies
-
- 2
-
-
- part count
- storage
- (and 1 more)
-
Just to clarify: you are playing a career game, right? If so, have you purchased TCA subsystem and modules in R&D? If you have, it's a serious bug, and I need to see the output_log.txt file. If not, it's still a bug, because the status page in the manual should indicate that, instead of saying that all is right. One other thing: do you have the GameData/000_AT_Utils folder? It's part of TCA, so if you don't, reinstall the mod from SpaceDock (you can find the link in the OP, or a few pages back).
-
I was too quick to promise this. Turns out part title does not belong to a part, but rather to its partInfo object, which every instance of a particular part shares. So if I rename, say, a "Jumbo" on one vessel into "Huge Xenon Tank", all the Jumbos in game will be named thus. The thing I could do is to add an info field to part menu with the name; but I don't feel that makes any sense, since when you open the part menu you know exactly what it contains without looking at the name.
-
OK, I'll try to figure out what happens here myself and report back.
-
Indeed. Then check if the SpeedPump is present where it should and works in-flight as expected. If not, we'll move to figuring out how to make the mods compatible.
-
This should work. To have full coverage you would also want to check for ModuleSwitchableTank: @PART[*]:HAS[@MODULE[ModuleTankManager|ModuleSwitchableTank],!MODULE[GPOSpeedPump]]:FOR[GPOSpeedFuelPump]:FINAL { MODULE { name = GPOSpeedPump } } @gamerscircle, could you please check this? You're already using the SpeedPump so it'll be easier for you to evaluate if it works correctly with CC-patched tanks.
-
They would. And that is also partly by design (the hatch is a part of the structure, reaping it away or blowing it would damage the insides...); but mostly because I cannot actually make a hole in an asteroid so that stored ships could be launched out of it. The whole asteroid-hangar thing is pretty restricted (and as you've shown bugged ), but asteroids, being as the are just solid parts, don't provide much to work with. Still, as the work on interoperability with USI's ART progresses we may come up with a more robust solution for usable storage space... Or "Surprisingly, it worked." as would, no doubt, be written in a scientific paper
- 1,633 replies
-
- 2
-
-
- part count
- storage
- (and 1 more)
-
Imagine two hatches attached to the far sides of an asteroid. One of it has space 5x5x5 meters. But the asteroid is, say, 50m in diameter. Should the other hatch get access to that space? Obviously not. And yes, that is a trivial case. But how would you approach handling a non-trivial one? How big should be the space to allow access from another hatch? His close it should be? At what angle to the first? And what would happen should a hatch be destroyed? I'm not touching technical matters like how to implement persistent shared space. Just the principles.
-
Thanks, @Benoit Hage! @astropithicus, this is definitely a problem with installation. Aside from ModuleManager TCA requires AT_Utils library which is bundled, but somehow some people lose it (haven't you, by chance, installed TCA through CKAN?). Anyway, I would first recommend to reinstall from SpaceDock, which is the main TCA repository. Be sure to have ModuleManager and 000_AT_Utils in your GameData. If that won't help, please, report back to TCA forum.
-
Updates: yes, I see your point; but then allowing selection of modules only in editor also breaks that logic. I'm not making TCA a physical part, nor lock it to any particular control part of a ship (distributed computer systems rock ). So what, does this mean OTA updates AND in-flight module selection? And I was so hoping to add something to the gameplay Oh well... Edit: on the other hand, I could always say that OTA updates of ship computers are too dangerous and forbid them by policy BTW, a separate difficult problem is the UI for module selection. Because modules have their dependencies the whole lot of them are actually a directed graph. But I have only rows/columns of buttons to handle them Yea, I know about these mods I used "balloons" as a joke generalized term, sorry
-
Yet another question: Should a ship with some modules not installed because they were still locked in the Tech Tree at construction time... receive an OTA update as soon as these modules are unlocked? stay as it is, because modules are more than just pieces of software and require additional electronic components? This is purely gameplay choice, no technical limitations involved.
-
Introducing Developer Builds! From now on I will publish developer builds in my Dropbox. The builds are compiled with DEBUG flag and are marked by automatic build number (the last number in version string). I cannot promise any particular release rates, but these builds will be coming much more often than normal releases. They will also contain all the latest features. For instance, current build contains many bugfixes and the new interface. Obviously, these should not be considered stable and should not be used for your main game! But if you want to help the project, you are very welcome to play with them, test them, break them and tell me all about it! Seriously, folks, I need you! Even if I had the time to test everything, I know the system too well and subconsciously evade most of the bugs
-
I'm afraid you got me wrong: the question is not how to group in-flight controls (I've already done that, as you can see in the video), the question is how to group TCA Modules to add/remove them to a particular ship at construction time. This is a paradigm shift of a sort: currently all the ships have all TCA Modules you have opened in the Tech Tree. I want to change that, so that you could omit not only some controls, but some functionality. In the prospect, this could even influence the cost of the ship. Don't know about the balloons. Technically, there's nothing preventing from using TCA with them; but to what end? TCA vs MechJeb: the question was asked countless times. As I see it, the mods are too different to compete. For instance, MJ has an excellent maneuver planner that I will not even try to reimplement. What for, if I can always use MJ to plot the course and TCA to execute maneuvers? Docking autopilot, DeltaV calculator, rover autopilot... MJ has so many features that are so complex and work so well that it will be the plane stupid to remake them instead of using. Where TCA ends? I'm not sure; there's no business plan nor technical project. There are some ideas that pop up into my mind, and many more ideas that you give me here on the forum. There are two baselines though: First thing that I try to achieve with TCA in general is to allow the user to focus on creating meaningful ship designs that will "just work" instead of forcing them to carefully place each part only to discover that the ship is not balanced enough and trying, and retrying... I mean, every modern airplane, or even a simple drone have enough programming built in to make its handling easy. Why KSP spacecrafts should differ? As my math teacher once told me: "You need to solve simple things (like quadratic inequalities) instantly and automatically, otherwise you will never be able to get to any interesting stuff." So I want TCA to solve low-level control problems, so that users (me included) could spend their imagination and intellect on more interesting and challenging things. Second, I'm interested in programming complex behaviours and use TCA (its autopilots) as a playground. I play KSP (oh well, let's be honest, I don't play anymore, only test things) and encounter a task that is hard and complex (like landing) but that could obviously be automated because I myself already learned how to do it. So I go and "teach" the code to do it for me. The big difference between my "exercises" and MJ is that MJ uses "first calculate, then execute" approach, while I employ constant self-correction which brings these autopilots closer to AI (but not quite, mind you!). I apologise for the excess verbosity, but I hope I have answered your question.
-
¿ Question ? Another important part of the upcoming interface remake is the ability to decide which TCA modules are installed on a particular ship. The problem here is that modules are many, so if I make a button for each, they will probably fill the screen. Obviously, some segregation is required. The simplest will be to use TCA's tech-tree parts, but most of them also represent a single module. So I ask you to look at the list of tech-tree parts and tell me, which of these would you want to toggle with a single button? Edit: reposted this so it is not buried in the conversation.
-
It does that. But first, there's a (not so big) limit to how much torque you can compensate that way, and second, as I said before, it is simply against the core of TCA functionality -- the engine balancing by throttle limiting.
-
Ahhh, I see! Unfortunately, what you want is not possible: there's no control over gimbals, they act autonomously on each of the engines and neither user nor plugin can force them to turn a nozzle to any particular direction. They only react to pitch-roll-yaw input. The same goes for control surfaces.
-
@aluc24, by the way, have you seen the video on the subject?
-
Currently not, but the idea is great, so I will make it happen!
-
TCA stands for Throttle Controlled Avionics, so it's only natural that it handles engines' throttle to create (or, in your case, to counter) torque. Gimbals are used to some extent, which is calculated from a number of factors; there's no user control over it, nor should it be. As for solution, no magic here -- the only way to achieve full throttle is to create a balanced design. For that TCA have builtin aids in Editor. If you cannot balance the craft, you should allow for some downthrotling by providing larger total thrust. Also, in such case it is important to correctly set the roles of the engines. Again, for that TCA has builtin helper (the Autoconfigure Active Profile button); but you shouldn't rely solely on it. About maneuvering: I never encountered such problems. Latest versions of TCA use pre-balancing to evaluate actual maximum thrust available for the maneuver, so the calculation TCA makes should be pretty accurate. So, either you're using an old version of TCA, or you have found a bug; in which case I would ask you to share the .craft file of the ship that has problems with maneuver time estimation, along with the list of mods required for that ship. It is such a shame that Unity (at least with the old GUI framework) does not provide the grid layout! Thing would look much nicer with it.
-
Behold! The first variant of the new modular interface. Comments and suggestions are very welcome!
-
To a point. The cost, resources and stored science will be recovered; if kerbals were onboard, they will be inside the carrier ship, so they also will be recovered. Mods like Stage Recovery should work. But if you're using something like KCT, which keeps track of individual parts, it won't recognize the parts inside the Hangar. And I'm not sure about contacts. Most likely, if you have a contract to recover specific vessel, you need to do it literally, so you have to launch it from the Hangar after landing.
