[WIP] Infernal Robotics - Next

[Rudolf Meier]

30 minutes ago, kcs123 said:

Until changes are made from ferram side, you might distribute your forked/changed version of KJR ...

ok then... here's a compilation for 1.3.1 http://meiru.square7.ch/reg554ui9wert/KerbalJointReinforcement_special.zip

 

Edited February 26, 2018 by Rudolf Meier

[Rudolf Meier]

*hmm* ... very interesting that mass is scaling wrong... I thought this should be handled correctly without my interaction... EC... well... how should I scale this? I'm doing it quadratic at the moment, because I thought it's not completely cubic... but I didn't investigate the values for real life motors enough

and... I don't know why it's not working for you, but when I scale extendatrons, they scale correctly... how did you do that??

[AccidentalDisassembly]

Mass scaling is working correctly, I think, but EXTENSION scaling isn't - I didn't change the associated TWEAKSCALEEXPONENT values, which should be this:

translateMin = 1
translateMax = 1

... meaning linear, in theory 2x size = 2x extension distance, or 8x size = 8x extension distance.

It's just that once you scale up past a certain point, it does not scale the extension/movement of the IR parts correctly. Or I have done something wrong somewhere in a config, but I don't *think* so...

I remember long ago figuring out exactly what the largest scale was that TS + IR could do without messing things up, but I can't remember, except that it was vaguely around 2.0 before things got weird. HOWEVER, duplicating an IR part and changing values accordingly does not suffer from that issue, so there's some interaction with TweakScale that's not quite right.

I did quadratic for EC, dunno, kind of arbitrary but it "felt" ok, and I did quadratic for mass as well. Maybe Mass should be something like exponent of 2.3 (ish?). The potential issue was always that, when things are scaled down, the mass becomes absurdly small (in game terms) and the joints may be come useless... But with the new KJR.... hmmmm....

Edited February 26, 2018 by AccidentalDisassembly

[ZodiusInfuser]

Mass should always be cubic I thought? And as for EC unless there is a reason to change it, use whatever the original IR used, otherwise its yet another thing to test.

How are you achieving such a large scale? Pretty sure the values I set do not let my parts go beyond the x2 problem size.

[Rudolf Meier]

7 hours ago, AccidentalDisassembly said:

Mass scaling is working correctly, I think, but EXTENSION scaling isn't - ...

Oh... you know what the "bug" is? ... I fixed it, but did not recompile and not upload it. You are still working with the damaged one  ... I will upload a new one with all scale-fixes later.

1 hour ago, ZodiusInfuser said:

Mass should always be cubic I thought? And as for EC unless there is a reason to change it, use whatever the original IR used, otherwise its yet another thing to test.

How are you achieving such a large scale? Pretty sure the values I set do not let my parts go beyond the x2 problem size.

Sure... but I seem not to have the correct values set. I need to verify this. Some settings don't work currently. This must be because of wrong names and my modules are using IRescale instead of config files... but we need a mix of it. Feeding IRescale with parameters from our own config files. Should be an easy fix, once I do have time to do it.

[AccidentalDisassembly]

7 hours ago, ZodiusInfuser said:

Mass should always be cubic I thought? And as for EC unless there is a reason to change it, use whatever the original IR used, otherwise its yet another thing to test.

How are you achieving such a large scale? Pretty sure the values I set do not let my parts go beyond the x2 problem size.

Cubic mass seems like it should be realistic (8x the volume, 8x the mass, right?) but I don't think it really is. I'm no engineer, but attributes like stiffness are proportional to the cube of thickness... So presumably when you build something 2x the size in all dimensions, it seems plausible that you wouldn't actually use 2x thicker materials on every single part of it (8x as stiff for 2x the size?), hence not 8x the mass all together. But mostly - no mass values in the game are realistic, and I think a scaling exponent between 2-3 produces a result that "feels" more right in the game and allows for more possibilities with crafts. Also prevents incredibly small mass when scaling down.

[AccidentalDisassembly]

OK, found the problem with the old TS config and am fixing it (while introducing other niceties).

I really think the TweakScale modules should be removed from individual parts' configs and instead applied via a MM patch - this makes it significantly easier to edit, update, correct, modify, or completely disable TweakScale on IR parts depending on users' preferences.

Consider for example: if someone wants to play with TweakScale, but NOT with IR parts, they have to go write an MM patch to delete the TweakScale module from every part config rather than just deleting IR's TweakScale patch. Similarly, if I want to change the name of the SCALETYPES in my config so that they're clearer, for instance, I have to use an MM patch to then update each part config rather than copying/pasting one thing in the TS patch. Simplest just to have one TweakScale patch in the first place, IMO.

I'll have a working config some time soon! (TM)

A random note : There's either a texture missing in the IR_AthleteTruss_XXXX folders (possibly called StructuralSegmentsUV) or the parts weren't ever textured. I seem to remember once having a version of the rework parts where they were textured, though...

[ZodiusInfuser]

4 minutes ago, AccidentalDisassembly said:

OK, found the problem with the old TS config and am fixing it (while introducing other niceties)

What was the problem and what niceties are you adding? For all the rework parts I chose the scale values and ranges for specific reasons, so I hope you're not just adding in x5 scales for example.

8 minutes ago, AccidentalDisassembly said:

I really think the TweakScale modules should be removed from individual parts' configs and instead applied via a MM patch - this makes it significantly easier to edit, update, correct, modify, or completely disable TweakScale on IR parts depending on users' preferences.

Consider for example: if someone wants to play with TweakScale, but NOT with IR parts, they have to go write an MM patch to delete the TweakScale module from every part config rather than just deleting IR's TweakScale patch. Similarly, if I want to change the name of the SCALETYPES in my config so that they're clearer, for instance, I have to use an MM patch to then update each part config rather than copying/pasting one thing in the TS patch. Simplest just to have one TweakScale patch in the first place, IMO.

Purely for the point of removing the errors that appear about TS when you only have IR installed, I agree. I am hesitant about players just modifying scales as they wish though as that means you cannot rely on scales being correct when sharing craft files for instance.

I should point out that the Rework is still a separate mod from IR itself. Its parts are included here for player convenience because Rudolf asked me.

14 minutes ago, AccidentalDisassembly said:

A random note : There's either a texture missing in the IR_AthleteTruss_XXXX folders (possibly called StructuralSegmentsUV) or the parts weren't ever textured. I seem to remember once having a version of the rework parts where they were textured, though...

Nope, I never did texture them in the end.

[AccidentalDisassembly]

4 hours ago, ZodiusInfuser said:

What was the problem and what niceties are you adding? For all the rework parts I chose the scale values and ranges for specific reasons, so I hope you're not just adding in x5 scales for example.

Purely for the point of removing the errors that appear about TS when you only have IR installed, I agree. I am hesitant about players just modifying scales as they wish though as that means you cannot rely on scales being correct when sharing craft files for instance.

I should point out that the Rework is still a separate mod from IR itself. Its parts are included here for player convenience because Rudolf asked me.

Nope, I never did texture them in the end.

What I'm doing is:

1. Creating two new unified TweakScale configs, one for Legacy, one for Rework, in which are combined the necessary SCALETYPE definitions and patches adding TS modules to appropriate parts
2. Making TWEAKSCALEEXPONENTS{} definitions work with the new / differently-named variables in ModuleIRServo_v3.
3. Updating mass exponents to 2.4 across the board - easy to change before anything gets released, if that exponent isn't the right one.
4. Updating EC usage exponent to 2.4 as well. A bit arbitrary, but I figure there's some kind of logic in having EC use be proportional to part mass when scaled... I guess?
5. Niceties: adding tab stops to the config files so they're quicker/easier to read, commenting changes
6. Niceties: Creating a separate, optional patch for people like myself who want larger scales to be possible.

I'm not sure why it would be problematic to include larger scales by default, though, [EDIT: looking at the TS configs, actually, at least the original IR allowed for 4x scale...] assuming everything gets fixed with respect to scaling/extension interactions... Especially given the apparent effectiveness of the new KJR. Not sure all is fixed yet, still testing stuff out.

With respect to craft sharing - yes, but that's an issue when any part is TweakScaled, and players can already change any of the scales they want by editing configs. I wonder, actually - would things actually be broken if the SCALETYPE on your save was different from the SCALETYPE used to create a craft? What does TweakScale actually save in a craft/part - the name of the scale that got used, or just some numerical value that says "resize stuff by X, EC consumption is now Value Y" and so forth?

EDIT: Here are the updated configs. Nothing is changed with respect to how things used to work, I don't think... Hopefully didn't leave any parts out. Put the mass exponent in as a MM patch so that it would be easy to play with, but it could be different for different types of parts easily...

https://www.dropbox.com/s/z2htmyrsfpr9x6z/New IR TweakScale Configs.zip?dl=0

ANOTHER EDIT: Playing with TS values, and having just recently downloaded the GameData131.zip from the first post, extension still doesn't work correctly at large scales for certain parts - I made a 5x scale to test, and the stackable extendatron does not extend at all at this scale. However, standard Extendatrons do. When scaled down to 1.25 or so, the stackable one extends just fine...:

EC is scaling appropriately, mass too (I think), and the sounds play and stop at appropriate intervals when i try to extend the thing in flight, but it doesn't move.

FINAL EDIT: EC is not scaling correctly on the parts that can't be moved when they're scaled above whatever threshold. Off by a factor of 10 or so. Shows correctly in the editor via EEX, but moving the part in flight results in ~10x the power drain.

Edited February 27, 2018 by AccidentalDisassembly

[Rudolf Meier]

11 hours ago, AccidentalDisassembly said:

EC is not scaling correctly on the parts that can't be moved when they're scaled above whatever threshold. Off by a factor of 10 or so. Shows correctly in the editor via EEX, but moving the part in flight results in ~10x the power drain.

EC is now related to the speed... that's probably the problem here. Maybe we need other values now (smaller). But it doesn't make sense that a rotatron is using the same amount of electricity when turning 1 deg/s and 1000 deg/s ...

Edited February 27, 2018 by Rudolf Meier

[kcs123]

On 27. 02. 2018. at 11:55 AM, Rudolf Meier said:

EC is now related to the speed... that's probably the problem here. Maybe we need other values now (smaller). But it doesn't make sense that a rotatron is using the same amount of electricity when turning 1 deg/s and 1000 deg/s ...

How about:

EC/s = part_mass * speed * some_constant

Would be much closer to real life energy usage that depends on mass and speed at same time. "some_constant" is probably needed to fine adjust EC usage in game as "EC" is made up unit that does not have much relation with real life. IRL energy consuption would be related to all part mass that IR part want to push, not just itself, but that would be overkill to code just for that.

That way, when you scale up part mass, you will "properly" scaled up EC usage. If you slow down IR speed, you can adjust to have same EC consuption, but with cost of moving IR part more slowly.

[Rudolf Meier]

It is related to torque... and you cannot read out those values in this unity version... but I did think about a possible solution.

I like the idea with the mass. This could be an option. Didn't think about that... but one of the problems I do have with this is that we'd need to find out what the current gravity forces are on those masses. I didn't find out (up to now) how to calculate this (I tried this for other ideas). The values I find don't make sense to me at the moment... I need some explanation here.

 

[pellinor]

On 2/27/2018 at 12:44 AM, AccidentalDisassembly said:

With respect to craft sharing - yes, but that's an issue when any part is TweakScaled, and players can already change any of the scales they want by editing configs. I wonder, actually - would things actually be broken if the SCALETYPE on your save was different from the SCALETYPE used to create a craft? What does TweakScale actually save in a craft/part - the name of the scale that got used, or just some numerical value that says "resize stuff by X, EC consumption is now Value Y" and so forth?

Just "resize stuff by X", and all non-persistent values are scaled each time the part is loaded into a scene, according to what the configs say at that time. So each time a craft is loaded it would look up the exponent for EC and apply it to the value from the part's prefab.

Edited February 28, 2018 by pellinor

[kcs123]

1 hour ago, Rudolf Meier said:

It is related to torque... and you cannot read out those values in this unity version... but I did think about a possible solution.

I like the idea with the mass. This could be an option. Didn't think about that... but one of the problems I do have with this is that we'd need to find out what the current gravity forces are on those masses. I didn't find out (up to now) how to calculate this (I tried this for other ideas). The values I find don't make sense to me at the moment... I need some explanation here.

It can be safely "assumed" that torque on motors is "magicaly adjusted" with additional gears/mechanics in combination to motors on each IR part, so you can have some constant torque that would not allow for motors to suffer. Simply put, same motor can be used for small part and for large part to move it, but it will need to move larger part with higher mass for longer period of time and at slower speed due to gearbox reduction.

I use this to calculate gravity and weight of craft trogh kOS script:

local Body_g to SHIP:BODY:MU / (SHIP:BODY:RADIUS+altitude)^2.
local CraftWeight to SHIP:MASS * Body_g.

SHIP:BODY:MU is gravitational parameter of SOI body for your craft. Those values should be obtainable trough KSP APIs somehow, because kOS mod reads them from game database. In most cases you can even disregard current ship altitude due to low influence on gravity acceleration when you are close to planet. I think that would be sufficient to use only IR part mass for that calculation, reading each part mass that is attached to IR part might be overkill and cause unwanted FPS dropdown, when used just for game purpose.

[AccidentalDisassembly]

4 hours ago, pellinor said:

Just "resize stuff by X", and all non-persistent values are scaled each time the part is loaded into a scene, according to what the configs say at that time. So each time a craft is loaded it would look up the exponent for EC and apply it to the value from the part's prefab.

OK, thanks!

So in that case, it seems to me that you could create any scaletypes you want, with any names you want and any min/max values you want, and it would not affect crafts loaded from someone who used completely different values.

Instead, TS would simply read the "resize by factor of X" value, regardless of whether it would in theory be permitted by the scaletypes you've set up for your own game.

But, in order to define the attributes other than model size for the part, it would look up your (current) TWEAKSCALEEXPONENTS values to set them - like mass and EC, or values fed to a converter module, or whatever?

TL, DR: There should be no problem loading a craft with a part rescaled to 398x size even if your scaletypes don't allow for that value, but if you've messed with TWEAKSCALEEXPONENTS, it could radically change resources or mass or whatever.

If I'm understanding correctly, that is...

[pellinor]

19 hours ago, AccidentalDisassembly said:

Instead, TS would simply read the "resize by factor of X" value, regardless of whether it would in theory be permitted by the scaletypes you've set up for your own game.

If my memory is correct, I once did something so that the scale is not checked on load. So in the editor the scale probably loads like it was in the craft file, and jumps to the nearest legal value once you open a part's right click menu. But better test this if you want to be sure.

Edited March 1, 2018 by pellinor

[hypervelocity]

Whoa!! so glad to see plans for improvement for this great great mod!

Forgive me as I haven't managed to read the complete thread and maybe this has been mentioned in the past, but if anyone might accept a humble suggestion, I would love this new version to support the attachment of Docking Ports to IR parts - but hey, just a thought!

I will be following this thread! best of luck with development, and thanks in advance!

[Rudolf Meier]

5 minutes ago, hypervelocity said:

Whoa!! so glad to see plans for improvement for this great great mod!

Forgive me as I haven't managed to read the complete thread and maybe this has been mentioned in the past, but if anyone might accept a humble suggestion, I would love this new version to support the attachment of Docking Ports to IR parts - but hey, just a thought!

I will be following this thread! best of luck with development, and thanks in advance!

Thanks for the support... by the way... the docking port - ir part interaction (and reversal of joints) was the main reason why this project was started ... and currently I don't see any problems with that anymore... this works. You can download the alpha version. All that's not working in there is scaling. But I will soon release the fixed version.

[hypervelocity]

jajajaj wow @Rudolf Meier, the above will probably compete as the best answer ever!!! what a coincidence! that's so good to hear! I will definitely be supporting this project and I will test the alpha version this weekend and will provide feedback then! 

now I don't want to get greedy - but I remember an old bug that I have always attributed to IR (although not quite sure actually). I really liked IR to create big solar arrays: the way I would construct them would be using a pair of foldatrons attached to the truss of my station, and a few girder segments attached to the foldatrons. Finally I would attach the solar panels to those girders. The bug appeared after switching vessels: when I reload my station, the girders would appear to be disjointed instead of properly attached forming a straight line. I don't know if I'm explaining myself correctly but maybe you have seen this in the past.

EDIT: well, today seems to be coincidences day! I just saw a Tyler Raiz video and he is experiencing the exact same bug I am trying to describe, have a look (bug visible at 27min40secs, check the solar arrays): 

 

Edited March 1, 2018 by hypervelocity
coincidence

[Rudolf Meier]

18 minutes ago, hypervelocity said:

now I don't want to get greedy - but I remember an old bug that I have always attributed to IR (although not quite sure actually). I really liked IR to create big solar arrays: the way I would construct them would be using a pair of foldatrons attached to the truss of my station, and a few girder segments attached to the foldatrons. Finally I would attach the solar panels to those girders. The bug appeared after switching vessels: when I reload my station, the girders would appear to be disjointed instead of properly attached forming a straight line. I don't know if I'm explaining myself correctly but maybe you have seen this in the past.

Well... I've seen a lot of those sort of bugs. To be honest, I've never seen it that way you have it in your video.

But what I can promise is, that in case you can reproduce this with a test vessel with the new parts, then I will try to find this bug and fix it. I'm not sure if it's only realated to IR parts. I saw those problems also for "structural" parts. There must be a reason for that and this must be fixable. ... another odd thing is the little "jump" that a vessel makes when you load a scene often (e.g. my robotic tests on the launch pad... after 20 times loading them they make a pretty big jump... and it's getting higher every time... this is also very strange...).

[AccidentalDisassembly]

1 hour ago, Rudolf Meier said:

Well... I've seen a lot of those sort of bugs. To be honest, I've never seen it that way you have it in your video.

But what I can promise is, that in case you can reproduce this with a test vessel with the new parts, then I will try to find this bug and fix it. I'm not sure if it's only realated to IR parts. I saw those problems also for "structural" parts. There must be a reason for that and this must be fixable. ... another odd thing is the little "jump" that a vessel makes when you load a scene often (e.g. my robotic tests on the launch pad... after 20 times loading them they make a pretty big jump... and it's getting higher every time... this is also very strange...).

There's a mod that tries to address the jumping, and in my experience it's pretty effective:

 

[Rudolf Meier]

20 minutes ago, AccidentalDisassembly said:

There's a mod that tries to address the jumping, and in my experience it's pretty effective.

Yep... I know that. But what I'm intersted in is if the part-drift that you can see between some part (not all types! it's just between specific types of parts) is the same problem or another and... I would like to understand if it comes from unity or KSP. Yeah, I know... I alwas want to know everything... by the way, is there a "Kerbal Colbert Emoji"??   is this one close to it?

Edited March 2, 2018 by Rudolf Meier

[Rudolf Meier]

Sorry for the delays with the next upload... I'm currently doing some experiments with the joints.

[kcs123]

15 hours ago, Rudolf Meier said:

Yep... I know that. But what I'm intersted in is if the part-drift that you can see between some part (not all types! it's just between specific types of parts) is the same problem or another and... I would like to understand if it comes from unity or KSP. Yeah, I know... I alwas want to know everything... by the way, is there a "Kerbal Colbert Emoji"??   is this one close to it?

Yes, most probably it comes from KSP stock game and unity game engine itself. Not that I'm expert on this,  but I come across to post that is talked about it recently and for some odd reason I tend to remeber such stuff:

As much as I'm able to understand this, main issue is lack of decimal digits in float point type used for enough precision. This issue is reason why you have "Reattach fixed meshes" button in last IR plugin available. At least you can fix it to some degree if not completely avoid.

And you can avoid such thing to happen if you don't time warp while having craft with such IR parts on flight scene. If you need to time warp, try to switch to tracking station, warp time and then get back to flight scene.

Other possible workaround of this issue would be careful placing of IR parts and usage new locking parts as soon as new mod from whale_2 become available.
You can see possible fix as described in this post:

First alpha of InnerLock is available to try on github. While not everything is possible to solve with just one mod, it might be possible with combination of few different mods.

Hope that tiny bit of info will help.

[Rudolf Meier]

ist was first  and then  and after that  ...

anyway... the problem of saving and restoring forces on joints is solved... works great... and...

yes... then it jumps, when you had forces on joints and come back from time warp... now... why is that? this time it's not unity fault... nope... it's because gravity is turned off and then turned on over a period of some frames... and now, if your force comes from gravity, then this doesn't work anymore

but that's solved too...

it's a bit of an irony... they do this gravity stuff to make the transition from time warp into the normal time easier and that's why we have so many problems

... the only problem with all this is that it took so long, that I didn't have time to build a new release. In case nobody find's huge KSP problems in the next 24 hours, I hope that I can finally build one

Edited March 3, 2018 by Rudolf Meier