Rudolf Meier

You have this situation for a lot of softwares. There are a lot of products with the information, that it needs at least Windows 8 or Widows 10 1607 to run. Normally there is no upper limit mentioned, until an incompatibility has been found. You can see the release dates from github.

Right... it is outdated, but will be updated as soon as we/someone has some time to do that. The main reson for this "pre-release" marking is, that I don't want ckan users to see an updated version every week. It's not that it is unstable or something. But simply not all new features are built in.

I have a new version now that should solve this DLC robotic problem... but it's simply stupid what I had to do... that's why for the moment it's out as pre-release or beta

I have a new version now that should solve this DLC robotic problem... but it's simply stupid what I had to do... maybe I need to split this up and bring a new version 4.0.x for all older ksps and 4.1.x for 1.7.3 and later... I will have to see what I do for the moment it's out as pre-release or beta

Almost everything, compared to "old IR". And in 3.0.2 I'm testing a new symmetry mode. What you describe may happen in symmetry in the editor. If, then it's just in this special configuration I don't know why this should be a problem... if not in symmetry. With symmetry there could be some problems (it's new). The calculations done in the background aren't that complicated I think, but it is of course much more complicated than in the classic IR, because of all those correction values used and needed.

If it interprets the input as if it came from KAL-1000... then it must expect that there will be additional inputs performing a slow down towards the intended target. But this will never come, so the last input "88 as fast as possible" is still active and will remain active until it's reached... then the system detects "ups... what now?" ... and will maybe re-interpret it as "MoveTo"... or it could also say -> "Move forever" or until limit is reached... Moving to 98 is just an example (10 braking distance) By the way... setting the acceleration to a very high number would allow to use the servo with almost raw input.

... the only problem: If I use the axis property -> KAL feeds it -> fine... user clicks on slider to jump from 0 to 88 -> then the servo moves to 98 and comes back to 88 because it doesn't know where the input came from. So I need 2 axis properties... and the modder would have to use the right one... maybe this works. My only question here is, wheter or not there is other default ui's in ksp that allow you to use the axis properties. Because if yes, then I don't have a problem with it, but players (non programmers) may get confused when there is a "position-axis" and a "directposition-axis"... but still, I don't see other options here

Yes, but enforcing the limits is currently done in the interpolator... I'd need to split this up. And we need another interface... not just "MoveTo" but... if I take your idea which I like ... something like "MoveStep" or "DirectMove" or whatever and you put in the next position which the joint will move into ignoring all speed and braking times (except for those we cannot ignore because of limits) ... maybe that's the way to do it... I think I like it ... and, how do we interpret the slider and KAL-1000 inputs? MoveTo or DirectMove? ... KAL maybe DirectMove, while the slider.. I think that's a "MoveTo" ... which will make everything much more complex for users. Because we would need 2 input axis then.

I found the problem... thanks to the data from @Sijet what I learned is this: 1) it only happens with DLC robotic parts, never with Infernal Robotics 2) This is because of the different construction of those parts. DLC parts don't move. They remain where they are and build a helper part that moves, while Infernal Robotics doesn't need this additional helper and moves directly. 3) Because those DLC parts don't move, they shouldn't be used as anchor points for additional reinforcement-joints. ... now I need to change that ... but I first have to find the best way to do it...

Sure, but the main question remains... what's the interface you want? MoveTo(targetPosition, maxTargetSpeed) ?? or MoveTo(targetPosition, maxOvershooting) ?? ... is this useful?

The system would have to be split into 2 parts. It's not generally hard to do. It only needs some new classes and interfaces... I took the old idea and left it like it was. But maybe I should change this in a future version. I would need to split up the interpolator into 2 classes and add an interface for some kind of "direct input" ... where you can say what you want. E.g. not "MoveTo and stop there" but "MoveTo and I don't care about the end-speed"... which will then of course cause an overshooting of the position... or a "MoveTo and don't be faster than speed x when reaching the position" ?? here the questions start to come in... As far as I have seen, KAL-1000 doesn't care about the speed... it only commands the positions and the joints try to get there as fast as possible... I don't know if DLC robotics handles the "overshooting" in this case... maybe... but maybe DLC robotics isn't a good comparison, because they move too fast in my opinion

did you look at the interfaces-files to see if something changed? ... I changed quite a bit from the last beta to the release... and the api files are not fully up to date

The problem here is, that this would be an external controller for the movement and this is somewhat against the idea that we have implemented. It's a bit the same situation with the KAL-1000. If I would accept the commands just like they are set, then it could be that we run into a situation in which for example the joint won't be able to stop before reaching its limits. That's one problem... the second one is, when you often do an update, the system tries not to get faster than a specific speed so that it can stop at the position you commanded. E.g. if you want to move from 0 to 12 and you command 0.2, 0.4, 0.6, 0.8... then the system will look at the acceleration possible and never go to a full speed, because it always thinks it has to stop after the next 0.2 step. If you want a smooth movement, you should command position 12 and speed e.g. 0.4 if you want this speed to be reached while moving. Then it accelerates to 0.4 as fast as possible, moves until e.g. 11.55 so that it has enough time to decelerate and then it stops at 12.

Yes, but it's not meant to be used like that. If commandedPosition is e.g. 33° and it is on position 32.85°, then it is because of a too heavy load and the system will try to go to 33° until it reaches this position. So if you now send a command to go to 34.5° because you think you can then reach 33°, that's very dangerous and puts unneeded stress on the system. You should let the system try to reach the position and not try to "correct an error with an other error" ...

there's an important thing to notice... there is a "commandedPosition" and a "Position" ... what you want to use is the "commandedPosition" (and "commandedSpeed"). those values are those that you can see in the UI of IR, while the others are the real positions (but they're much more unstable and only meant for other purposes... if you're mod is really aware of this difference)

now I know we have 2 bugs... when I load the config to add a value, all float values are gone after this action... and the used class is "KSP.IO.PluginConfiguration" ...

Yes, KJR is replacing autostruts. The only reason why you could use them together (in my opinion) might be, if you have one connection that is too weak even with KJR and want to add an additional strut to this specific joint. Then you can activate the autostrut for this joint. But I wouldn't put autostruts to all joints. One of the problems I can see with autostruts and KJR is that they don't build the joints the same way and this can cause problems (mostly after locking/unlocking robotic parts). And then it does hurt your performance. And it could be that it's getting unrealisticly strong/stiff.

I think we have 2 bugs... first, when I write to the config file after loading it, all float-values are missing (that's a standard ksp class)... no idea if this could be something I do wrong... what else than calling "load" could I do? ... anyway, I will have to investigate this one second, with those uninitialized values... why does the code then lock things it shouldn't lock up? what is it doing then... that's the other question

I don't know everything at the moment, but if you copy the config.xml file from the debug version into the release version, then the release works... somehow those values seem to be the key... but, as I said, I don't understand this at the moment. But I think I can start debugging with the debug version now. Because we should see the same problems there too with the wrong initial config values... ah, no... sorry... use the config that is written after using the debug version once... that's how it works ... at least sometimes

yes, I tried and it worked but, I have had a reproduction now... I had to install it via CKAN... when I installed the one I uploaded to github manually, then it worked... the question is why... did I forget a file? is it different? ... but from now it should be easier... now I will compare everything bit by bit... I will find it... ok... now comes the funny part... the debug version works, the release not... so I have to debug the release version... that's always a fun

there is an IMotor and IMotorGroup... it's not the same... the problem is, that they (IMotorGroup and IServoGroup) are not in the "Command" namespace but in "Interfaces" ... that's wrong, I should fix that

no, it is still supported... does the code not work from https://github.com/meirumeiru/IR-Sequencer?? inside there you should find the API that should work with the latest version... if not, then I'd have to fix that

the difference is, that it's a debug compile and from the code ... there is a class Analyzer... and this, together with all it's gui classes is removed via #if #endif, as well as about 4 calls from the main classes which are all 1 lines (something like Analyzer.OnModified) ... to re-read the vessels information and, the debug version has about 3 if's additional to the default version (to allow the modification of the settings directly in the game). but... here also #if #endif around the if but, if every option is activated, then it doesn't make a difference... or shouldn't

I didn't see this problem... on my machine it works. Currently I'm trying an more extreme way of debugging. I got the full GameData folder from a computer showing those problems and... still it works. So either I need to do more (correct steps, correct environment like space around kerbin, duna, mun... whatever) or... I don't know... maybe it's never happening in the debug environment of unity... I don't know... I've currently still no idea what the problem is but what I learned from the installation I got was, that a lot of mods are throwing a lot (really a lot) of errors and nullreferenceexceptions... in every frame! ... this doesn't make debugging easier and I'm not sure if this could contribute to the problem we see here anyway... I'm continuing to try to get into this error situation

thanks, I'll come back on this. I haven't tested it now... had to help replacing servers and it took way longer than everyone expected I think I will have a test system ready tomorrow