allista
-
Posts
2,208 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by allista
-
As far as I know (and I don't know that far), while you're not switching between ships, vessels that are out of physics range get packed. This means any modules on parts (TCA included) become inactive, they don't get updated by Unity and all functionality is paused. If, however, you're trying to switch ships, out-of-range vessels go on rails. Then it depends: in atmosphere they just get destroyed. On Mun they should retain their orbits and should eventually smash into the ground... - - - Updated - - - Wow! Looks really cool The 'pairing' is a typical example of self-organisation of a system with local constraints: each craft just tries to be out of the way of a weighted center of all the others, where weights are calculated from proximity and relative velocity. On the other hand, each craft tries to fly directly to the leader. These opposing actions combined give the 'formation' effect.
-
I would say that I'm at moderate level of building planes for FAR (never played planes without it), but right now (and in days to come) I'm mostly "testing" this - - - Updated - - - Test it in v13 -- should make difference The problem was as follows: leader craft follows path and in the process automatically switches targets (wp1, wp2...); in the meantime the camera is focused on one of the followers which should be targeting the leader. But when the leader switched from wp1 to wp2, so did the active vessel (follower).
-
Here's the next version. Fixed automatic targeting problem. Improved collision prevention at high relative velocity; added PID to soften oscillations. Added text edit for altitude setpoint. Added Manual Translation subsystem to HSC; autopilots may now use manual engines to control horizontal speed. Needs to be tested. Tuned Follow Target program so that followers don't fall behind. Needs to be tested at low gravity.
-
X and Z give you +/-10m, but anyway, you're right) Will be done.
-
Here's the next version. Tried to fix auto-landing from high altitude problem. Added Collision Prevention System. Still WIP, but mainly works and needs testing. Please, pay attention to auto-landing in the general, as some raycasting code was changed.
-
Same thing: any autopilot program (follow, goto, path) constantly controls speed using HSC system (which I've described above); you turn on the aft engine, total thrust vector shifts and HSC tries to compensate. Because it does not "want" to move as fast as possible, it "wants" to move at the "right" speed. - - - Updated - - - Glad to hear!
-
Buffer zone is 50m (it is set by a property MinDistance (or something like it, don't remember and cannot look right now) in PN node of TCA.glob). And it does not affect the distance that followers try to keep with the leader. I'll try to do some specific tuning for the Follow program, but currently the leader is just a (moving) waypoint, so all the rules for waypoints apply. E.g. distance of ~<500m is considered already small enough to reduce relative velocity to ~20m/s (the figures are not thresholds, just the reference). - - - Updated - - - And what is the problem with that second craft? I'm sorry, I haven't caught it from the post. Edit: I think I see. You mean the tilted landing? It's because Horizontal Speed Control system uses total thrust vector to control horizontal speed, not throttle limits. So your aft engine shifts total thrust back, and the craft, to stay still while landing, has to pitch accordingly.
-
Here's the next fixed version: 'Can't add waypoint' fixed NRE when pressing Stop while Landing -- fixed, but needs testing Added target course prediction and near-target buffer zone to Follow Target program.
-
Here's the fixed version.Many thanks, smjjames!!!
-
Thanks for thorough investigation! I'll dive into it right away... UPD: I was wrong about what is the first exception in that case. It is not about resources, it is this: FieldAccessException: Cannot set a constant field at System.Reflection.MonoField.SetValue (System.Object obj, System.Object val, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 at System.Reflection.FieldInfo.SetValue (System.Object obj, System.Object value) [0x00000] in <filename unknown>:0 at ProtoPartSnapshot.Load (.Vessel vesselRef, Boolean loadAsRootPart) [0x00000] in <filename unknown>:0 at ProtoVessel.LoadObjects () [0x00000] in <filename unknown>:0 at Vessel.Load () [0x00000] in <filename unknown>:0 at Vessel.MakeActive () [0x00000] in <filename unknown>:0 at FlightGlobals.setActiveVessel (.Vessel v, Boolean force) [0x00000] in <filename unknown>:0 at FlightGlobals.SetActiveVessel (.Vessel v) [0x00000] in <filename unknown>:0 at FlightDriver.Start () [0x00000] in <filename unknown>:0 The Part itself is failed to load from ProtoPrtSnapshot. Because, apparently, it tries to set some constant field through reflection. But how could it be connected to any part module, and thus to TCA, I have no idea... O_o UPD: Nailed it! In the end, it was so bloody simple, but TOTALLY counterintuitive. As is always with Sqad's programming techniques It turns out that in a class derived from the PartModule you cannot use public const fileds. At all! One of the basic language features is unavailable because of a bad design of one of the most important classes in the whole KSP API. But it only manifests itself if the part with such module is the root part. Oh, well... Luckily, the workaround is much shorter than my explanations here
-
It does indeed need MM, which is stated in the OP) Anyway, with MM, but without TCA does the problem exist?
-
I've encountered this bug, but have no idea what causes it. The error (the first exception; others are just the echo) occurs, when the ModuleCommand of the probe core (the only part visible) tries to load and requests the resource it needs (Electric Charge, I presume). Doing this it passes a null ref. I don't even know if it's linked with TCA... Can you reproduce it without TCA installed?
-
Thanks) Yep, forgot to mention it. It is simply the 'old' Go To Target, but without end phase where target is canceled and the Stop program is engaged.
-
Sorry for the confusion. I've corrected these items. Follow Squad was a missformulation. What I meant was a situation when a bunch of vessels controlled by TCA with "Follow Target" enabled move after the user-controlled leader. I thought this could be a handy mode to transport much cargo from base to base... (EDIT: I also think that they may collide with each other, which will be fun ) Light and heavy are, of course, arbitrary; I've loosely chose the thresholds <=30t and >=100t. There are two important things about ship masses: 1) Vertical TWR, which in VTOL mode defines the perceptive inertia of vertical control; 2) Maximum angular acceleration (i.e. rotational "TWR"). So not the mass itself is important, but considering existing engines, it's simpler to talk about "light" (and agile) craft and "heavy" (and sluggish) one. UPD: BTW, you may use comments right in the spreadsheet; open context menu on any cell and choose "insert comment".
-
Here's the next BETA version. It features In-Editor Profile Manager as well as several fixes for VesselConfig/EnginesProfiles bugs and the new "Follow Target" autopilot program. Also, it is the last beta with new functionality, as I'm out of the ideas and the summer is over (meaning the hard work begins in my institute). I'm still reluctant to release it as stable due to the great amount of new features and scarce testing. So, as usual, I'm asking you for help: I've created a google spreadsheet with the tests that came to mind. You are free to add other tests, comment and mark existing tests as done (with some screenshots, maybe). I'm hoping that all tests will be done until the next weekend, so I could release all this at last
-
Have you set all your slow engines to Balance Thrust mode?
-
What exactly does not work in your case?
-
Apparently not *BTW, I've returned at last. Still fighting the 9 hour time difference >_<
-
The rain forced us into the shelter for some days, it seems. So I'm curious: has anyone any comments about new functionality?
-
Sorry. My fault. Here's the version that should work. At least I very much hope so. Unfortunately, I can't test it here. *and yes, they finally made a satellite dish with a 30Kb/s channel, so I'm still here https://www.dropbox.com/s/pbzazeoghju904e/ThrottleControlledAvionics-v2.3.0.8.zip?dl=0
-
And now the weather is finally clear and we're off to the chopper. Though the last day didn't went in vain: we traveled ~100km off road to another hot spring valley and gathered some samples. Wish me luck. I hope to be back alive in about ten days (again depending on the weather) - - - Updated - - - As a little entertainment, proofpics:
-
I doubt it: too small, too cold. It should have differentiated long ago... - - - Updated - - - Well, here's the fix for this. It should allow TCA to load properly without NREs, but I can't test if TCA availability in pods and cores in Editor's part catalogue is accurate in career mode. UPD: https://www.dropbox.com/s/pbzazeoghju904e/ThrottleControlledAvionics-v2.3.0.8.zip?dl=0
-
Thanks! Though bears are a much greater concern here. Literally >_< - - - Updated - - - Yep, I see the problem. And it's very strange that I don't have it as well. I'll try to post a quick fix as I still have some internet while we're waiting for a clear weather for the helicopter =]
-
Thanks for the report. I'll try to see what's wrong someday. Meanwhile, try it in sandbox mode, it should work there.
-
By the gods! Not another major update! This one would be on Unity5... I can't imagine all the things that would break >_<
