[WIP] Infernal Robotics - Next

[AccidentalDisassembly]

2 hours ago, Rudolf Meier said:

new version is out...

includes compile for 1.4.1, fix for the limit bug, readded the actions, fixed group-speed-factor allowing infinite speed and joints are made stronger (x 1.75)

 

I just saw the new TweakScale will not overwrite mass/whatever values if the exponent is 0, dunno if you were aware. I figured you were probably responsible for it, but just in case

[Rudolf Meier]

2 hours ago, AccidentalDisassembly said:

I figured you were probably responsible for it, but just in case

well  ... I just mentioned the problem I had with the mass scaling... and pellinor fixed it very quickly ... and added the new feature that a 0 scaling doesn't do anything (instead of overwriting the value with itself)

this confirms what I thought: that TweakScale is a realy good mod with realy good support

 

Edited March 15, 2018 by Rudolf Meier

[kcs123]

Gallery with small bugs noticed:

You can set limits in editor under advanced options, but that limit is not respected in flight, you still can move parts in full range. Move to preset works properly, though.
Not a big issue with simple craft with just 2-3 IR groups, but can be difficult to manage when number of groups grows. Old plugin was having option move to next/previous group on buttons instead of drag&drop. Drag&drop is good enough when craft is simple, but as soon as IR parts number grow, it become more difficult to move some part from group #1 to group #4 when each group contains 10 or more parts.

And a reminder, when using FAR, COL is not updated properly in SPH unless you move some part around:

In flight it seems that it behave properly, but I still didn't make any extensive tests, though.

 

[Rudolf Meier]

35 minutes ago, kcs123 said:

You can set limits in editor under advanced options, but that limit is not respected in flight, you still can move parts in full range. Move to preset works properly, though.
Not a big issue with simple craft with just 2-3 IR groups, but can be difficult to manage when number of groups grows. Old plugin was having option move to next/previous group on buttons instead of drag&drop. Drag&drop is good enough when craft is simple, but as soon as IR parts number grow, it become more difficult to move some part from group #1 to group #4 when each group contains 10 or more parts.

And a reminder, when using FAR, COL is not updated properly in SPH unless you move some part around:

those bugs I will fix them... about the drag&drop... that's an interesting point... I didn't think about this... I'll try to solve that

[kcs123]

1 hour ago, Rudolf Meier said:

those bugs I will fix them... about the drag&drop... that's an interesting point... I didn't think about this... I'll try to solve that

No worries, just reporting whatever I can notice so that you can have better quality plugin when it is finished

[Rudolf Meier]

On ‎15‎.‎03‎.‎2018 at 10:56 PM, kcs123 said:

You can set limits in editor under advanced options, but that limit is not respected in flight, you still can move parts in full range.

I cannot see this... what did you do to get this wrong behaviour?

if you start outside the limits or activate the limits when you are not inside its range, then you see a little bit strange things... but... the question here maybe should be: why do you acitvate a limit from e.g. 20 to 50 when you're at position 2? ... maybe I should not allow to set limits when you're outside of them?

Edited March 18, 2018 by Rudolf Meier

[kcs123]

1 hour ago, Rudolf Meier said:

I cannot see this... what did you do to get this wrong behaviour?

if you start outside the limits or activate the limits when you are not inside its range, then you see a little bit strange things... but... the question here maybe should be: why do you acitvate a limit from e.g. 20 to 50 when you're at position 2? ... maybe I should not allow to set limits when you're outside of them?

No, I didn't started outside of part limits. On my craft one extendratron was not enough and combination of basic extendratron and stackable extendratron gives too much range. I checked how much range I need to both of them to get desired limited position on craft, to prevent having dangerous position. I readed those positions in flight and reverted back to SPH. In SPH I set desired limits and check those in flight. Parts were extending beyond new limits I set, but still inside physical limits of parts.

Strange thing is, I just checked again, to make a craft where you can reproduce issue and I could not reproduce it again. It behaved like it is intended to behave. I havce no idea how I was able to move them beyond limits like first time I noticed and reported this. Sorry about that if it is false bug report. I will try to keep eye on this one and keep notes how to reproduce bug if possible. Something strange is going on here.

I don't recall if I was having some load on parts when I was testing it, maybe load was pushed extendratron slightly over desired limit and that allowed to keep part moving further ? Have to try some experiments to see if I can reproduce it.

[Rudolf Meier]

16 minutes ago, kcs123 said:

Sorry about that if it is false bug report.

No need to apologize... I cannot count how often I investigated something I thought was a bug and in the end it was nothing. But often I did find bugs I didn't search because of such actions. So, for me that's "normal development"  

19 minutes ago, kcs123 said:

I don't recall if I was having some load on parts when I was testing it, maybe load was pushed extendratron slightly over desired limit and that allowed to keep part moving further ? Have to try some experiments to see if I can reproduce it.

I was thinking about this option too... but I don't know if that's possible... maybe... at least I will re-read the code and try to find a possibility for that.

I need to re-think and maybe re-design how the limits work... or maybe just correct some minor issues... could be that something is not how I think it should be  so in any case, it was good we talked about it

[kcs123]

I found something different. I created some simple craft in attempt to reproduce issue. Extendratrons close to probe(craft root) have some limits set while other pair have no limit set. As soon as physics calmed down on runway, craft started to shake violently. Screenshot is not able to catch whole thing properly, but it is visible that free moving extendratron part is out of regular position on axis where it should not be able to move:

With just one pair of extendratron I didn't have same issue. Tested with KSP 1.3.1, I still didn't downloaded 1.4.1 to test it.

[kcs123]

One more thing that I just noticed. Mirrored IR part on craft is for some reason slightly different than original part. On this picture fuel tanks are of same weight placed on extendratron pairs that were placed on craft in mirror symmetry. However, on one side extendratron is offset due to weight in one direction while it is in oposite direction on other side of craft. It is more noticable when IR parts were extended.

EDIT:

When I have attempted to change min/max values of extendratron trough part right click menu I produced whild shaking of craft for some reason.

Edited March 18, 2018 by kcs123

[Electrocutor]

@Rudolf Meier Would you be interested in some ideas that I've always had for IR? It's based around the concept of KISS with the end result being a separate basic and advanced IR. The basic would have no GUIs, menus, or toolbar, and simply allow for mechanics alongside the already-existing building options.

[Rudolf Meier]

12 minutes ago, Electrocutor said:

@Rudolf Meier Would you be interested in some ideas that I've always had for IR? It's based around the concept of KISS with the end result being a separate basic and advanced IR. The basic would have no GUIs, menus, or toolbar, and simply allow for mechanics alongside the already-existing building options.

sure... it's always good to have ideas

[Electrocutor]

Just now, Rudolf Meier said:

sure... it's always good to have ideas

My idea starts that nothing comes from nothing, thus a new resources is needed to drive mechanics:

Resources

• Torque

Production

• Electric Motor (converts electricity into torque) [ Throttle: control rate of conversion ]
• Stepped Motor (converts electricity into torque) [ Buttons: Rotation Up, Rotation Down ]
• Engine (converts fuel & air into torque) [ Throttle: control rate of conversion ]

Transmission

• Axle (acts like the fuel line, only for Torque instead of LF)

 

At this point, you now have the ability to produce and transmit the new resource; but require mechanical means of utilizing it:

Consumption

• Mechanical Actuator [ Button: Extend/Retract, Slider: Min, Max ]
  • Attachment is like a fuel line, thus having two attachment points
  • The right-click menu for an actuator would look very similar to a cargo bay

It is also necessary to have basic structural parts.

Structural

• Hinge
• Bearing
• Ball
• Hitch

 

This is just a quick overview to try to get across a point and has not been well thought out or planned yet; but if you're interested in going down this path, I can spend more time fleshing out the ideas. The main concept is that there are no GUIs, menus, or toolbars and parts provide the ability to add mechanics into the game without making it more complicated. For example, you pop an electric motor on something, then drop a propeller onto that motor and the rotating part of the motor would spin the propeller and cause thrust. You could also attach a hinge to something, an ibeam to the hinge, and an actuator to the base and ibeam to allow the ibeam to move when the actuator is extended or retracted.

You could also add Hydraulic Fluid as another resource that would act in much the same way as Torque, only using pressure as a unit instead of force; but since the applications between the two are shared, I do not see it as necessary.

[Rudolf Meier]

the gui will need more work than I thought... maybe I'll fix the rest first and plan the gui updates for later... (because it's not a real problem, just... not so nice... sometimes) ...

[Rudolf Meier]

3 hours ago, Electrocutor said:

My idea starts that nothing comes from nothing, thus a new resources is needed to drive mechanics:

Resources

• Torque

....

This is just a quick overview to try to get across a point and has not been well thought out or planned yet; but if you're interested in going down this path, I can spend more time fleshing out the ideas. The main concept is that there are no GUIs, menus, or toolbars and parts provide the ability to add mechanics into the game without making it more complicated. For example, you pop an electric motor on something, then drop a propeller onto that motor and the rotating part of the motor would spin the propeller and cause thrust. You could also attach a hinge to something, an ibeam to the hinge, and an actuator to the base and ibeam to allow the ibeam to move when the actuator is extended or retracted.

You could also add Hydraulic Fluid as another resource that would act in much the same way as Torque, only using pressure as a unit instead of force; but since the applications between the two are shared, I do not see it as necessary.

I get the idea of the hydraulic fluid. But I don't think we should model electric driven parts differently... simply because that's not how KSP does it with its electric parts (wheels for example). ... and ... sure, for things like fast running motors, you don't need a controlling gui. But... I don't know if that's realy "robotics" then ...

4 hours ago, kcs123 said:

One more thing that I just noticed. Mirrored IR part on craft is for some reason slightly different than original part. On this picture fuel tanks are of same weight placed on extendratron pairs that were placed on craft in mirror symmetry. However, on one side extendratron is offset due to weight in one direction while it is in oposite direction on other side of craft. It is more noticable when IR parts were extended.

EDIT:

When I have attempted to change min/max values of extendratron trough part right click menu I produced whild shaking of craft for some reason.

try this with a tank in the middle instead of those trusses... then it works... that's the old problem with non-physical parts in KSP... no idea if we can fix that or if we should fix it... maybe I'll try that one day, but it's definitely "normal" for KSP at the moment...

[Rudolf Meier]

6 hours ago, kcs123 said:

I found something different. I created some simple craft in attempt to reproduce issue. Extendratrons close to probe(craft root) have some limits set while other pair have no limit set. As soon as physics calmed down on runway, craft started to shake violently. Screenshot is not able to catch whole thing properly, but it is visible that free moving extendratron part is out of regular position on axis where it should not be able to move:

With just one pair of extendratron I didn't have same issue. Tested with KSP 1.3.1, I still didn't downloaded 1.4.1 to test it.

another standard KSP problem... that's what KJR tries to solve, but doesn't work for all situations... maybe there is a solution for that, but currently... I don't know... maybe I could install huge dampers or something... but it is for sure a default KSP-shaking-joint problem

but... I see, the old IR had no problem with this configuration... maybe I can learn something from that and try to improve this

 it is even better... put one old IR part on that truss and... no shaking... I've to find out why

Edited March 18, 2018 by Rudolf Meier

[kcs123]

Ah, that's good to know and something to consider, to not use truss parts in such combination. Didn't even know that truss is not made as usual physic parts, I always thought that it is similar as empty fuel tanks or structural fuselage part, just of diferrent shape.

Even with some other combination of parts placed on truss IR next plugin work just fine, I only noticed odd shaking in such "simple" configuration. When I placed just one pair of extendratrons shaking was not present, only mirrored part issue. If that tiny piece of info helps at all to narrow down issue.

[Rudolf Meier]

I made some experiments...maybe you can confirm what I think I see. When I'm building your 4 Extendatron with stackable Extendatrons inside ship... and I'm first adding the Extendatrons (mirrored) and then the stackable ones (also mirrored), then it's shaking... when I build just one Extendatron with the stackables inside, then I take those 3 parts and mirror them all in one step... then I don't have the shaking... is that correct or is it just a coincidence?

[Rudolf Meier]

to me it seems to be causes by flaws in the unity solver

Edited March 19, 2018 by Rudolf Meier

[kcs123]

15 hours ago, Rudolf Meier said:

I made some experiments...maybe you can confirm what I think I see. When I'm building your 4 Extendatron with stackable Extendatrons inside ship... and I'm first adding the Extendatrons (mirrored) and then the stackable ones (also mirrored), then it's shaking... when I build just one Extendatron with the stackables inside, then I take those 3 parts and mirror them all in one step... then I don't have the shaking... is that correct or is it just a coincidence?

Yes, I think that is the way I created them. Placed basic extendratron first with mirrored option turned on. On top of that extendratron I have put stackable, still mirrored. After that I copied basic and stackable extendratron by ALT + click on basic extendratron and placed them on rear part of craft. At least that much I can recall, I didn' t pay much attention while I was doing this, I didn't expect shaking of parts on runway and could not know that order of placing parts could influence this.

[Rudolf Meier]

18 hours ago, Rudolf Meier said:

to me it seems to be causes by flaws in the unity solver

I still cannot reproduce this... I don't see the difference between the old IR's joints and the new one... I'm right now modifying the new IR in a way that it's building the joints exactely how the old one did it... but, no idea why the new ones are hanging down while the old ones don't...

[kcs123]

1 minute ago, Rudolf Meier said:

... I'm right now modifying the new IR in a way that it's building the joints exactely how the old one did it... but, no idea why the new ones are hanging down while the old ones don't...

It could be the strength of joints, how it was set. old IR was having joint strenght set way too high and it was still possible to bend joints in some cases. In IR next, joint strength is set to be weaker, but whole behaviour of IR parts were improved, (move limits, not being able to move around axes that is not designed to, etc.). Therefore, while overall behaviour is improved (have a feeling that joints were stronger than it actualy is), it start to bend as soon as you slightly overload above certain limits.

I hope that above makes some sense, just speculative opinion based on observation from within game, without looking in actual numbers.

[Rudolf Meier]

6 minutes ago, kcs123 said:

It could be the strength of joints, how it was set. old IR was having joint strenght set way too high and it was still possible to bend joints in some cases. In IR next, joint strength is set to be weaker, but whole behaviour of IR parts were improved, (move limits, not being able to move around axes that is not designed to, etc.). Therefore, while overall behaviour is improved (have a feeling that joints were stronger than it actualy is), it start to bend as soon as you slightly overload above certain limits.

I hope that above makes some sense, just speculative opinion based on observation from within game, without looking in actual numbers.

that was my first idea too... but even going to float.PositiveInfinity doesn't help... so, that cannot be the point... (just to mention that... if you set damping forces to infinity... then you destroy the sun, right after the launch...)

[Rudolf Meier]

ok... closer now... two problems:

1) when you use the "projection mode" (cheating mode of the solver to prevent such stupid movements that it shouldn't allow anyway) and you don't set limits (set the joint to "free" moving), then you still need to set the limit values (0 and 177 works, 0 and 0 doesn't) ... no idea why that makes a difference... those values shouldn't be used when you choose not to use them... but... hey... anyway...

2) the new way of limiting the joints (built directly into the joint we have, mainly to improve the performance) ... that's not working for this problem here... I will have to revert back to a 2 joint solution (but we do need 2 joints for rotational joints anyway, because there we don't have other possibilities -> otherwise limits from -177 to +177 degrees is the only thing we cal build... and even if this would be enough, you could never store/load a joints not in its default position...)

... so, it's clear now. But it takes some time to modify this. And then we can try again. Maybe the next solution is "better" (and "better" is defined as "fit's better on the solver unity uses"  )

yeah, I'm complaining about units solver all the time, I know that... but... shouldn't those frameworks solve problems and not produce problems? (and there are better ones, so it's not impossible!) ... if I need to write one workaround after the other simply to make it look as if physics works... that's no fun...  

[kcs123]

59 minutes ago, Rudolf Meier said:

 

... so, it's clear now. But it takes some time to modify this. And then we can try again. Maybe the next solution is "better" (and "better" is defined as "fit's better on the solver unity uses"  )

yeah, I'm complaining about units solver all the time, I know that... but... shouldn't those frameworks solve problems and not produce problems? (and there are better ones, so it's not impossible!) ... if I need to write one workaround after the other simply to make it look as if physics works... that's no fun...  

Off topic: this reminds me of Stephen Hawkings quote "Women find a problem for each solution".

Pretty much this can be applied to work with unity game engine