Jump to content

[0.90] Magic Smoke Industries Infernal Robotics - 0.19.3

sirkut

By sirkut
in KSP1 Mod Releases

 Share

Recommended Posts

kcs123

kcs123

Posted
Posted

@erendrake, thanks for pointing out in right direction. Friendly modders/users and developer of game in the first place is what was attracted me to the forums in the first place. I will need some time to study already written documentation, but hopefully I could learn how to use it properly.

Maybe I will be able to make some scripts for simple mechanic parts, who knows, if I do, I will share it on that forum.

Link to comment
Share on other sites
Dunbaratu

Dunbaratu

Posted
Posted
Thanks Darren, it seems that is KOS Scriptable Autopilot Sytem on that video. I don't know if it is possible to make everything trough action groups. I don't even need action group extender, one or two action groups I can spare. However pistons got only move to center or move +/- commands available trough action groups. Missing "move to position 0.62 and stop" command for example, so I don't know if it is possible to do such stuff even trough KOS SAS or Flight Computer if those are restricted to commands available trough action groups.

This is a problem I ran into when making that video. I couldn't use kOS to query the current position of an Infernal Robotics slider because the KSPField that infernal robotics uses to represent the part's current position is a hidden field not shown on the right click menu. and kOS *deliberately* does not give itself permission to expose a hidden field to the script programs.

When we started working on the system for kOS to be able to query and manipulate the values of other modules, we were very conscious of the fact that we could make a lot of other mod writers very mad at us if we started letting users fiddle all willy-nilly with any KSPFields they felt like at any time in any way. This is because there's a lot of mods out there, and Infernal Robotics is one of them, for which a lot of things which are really conceptually internal data for the mod's private use, which the user shouldn't see or change, are still listed as KSPFields anyway, for reasons other than letting the user see or fiddle with them. One possible reason for doing this includes wanting the value to be changeable via a Part.cfg file, but not necessarily changeable in flight by the pilot. Another possible reason for doing this is because it makes it easy to save the value to the persistence file. Because KSP requires all such fields to be declared as public, we can't assume that just because it's public that this means it's okay to let users use it. There's a large difference between "I don't mind other mod programmers messing with this" versus "I don't mind the user in-game messing with this". It's not safe to assume one from the other.

Therefore, even though there *are* KSPFields in Infernal Robotics that kOS *could* very easily enable kOS scripts to use, that would let a kOS script get the current position of the moving hinge or slider, we're deliberately not exposing them to the scripts because we don't know if we have the blessing of the authors of IR to do so. (hint, hint).

At the moment, the rules we established when we don't have explicit blessing are as follows:

1. Is the KSPField currently visible and showing on the right click menu?

If it isn't, then kOS will act as if the field doesn't even exist. Not only will kOS scripts be disallowed from altering the value, they cannot even read it either.

2. Is the KSPField visible on the right click panel but has no gui tweakable control on it?

Then the kOS script can read the value but not change it.

3. Is the KSPField visible on the right click panel AND it also has a gui tweakable control on it active in the current context? (i.e. during flight versus in the VAB).

Then the kOS script can both read and write the value, but even then it doesn't have full reign to write anything it feels like. It still has to abide by the restrictions in the GUI control. (i.e obeying the min/max/increment values of the slider for a floating point value.)

Our basic philosophy was "Allow a kOS script to do everything the player can do on those right click menus as a manual pilot, *and no more than that*."

It's the "and no more than that" that's causing us to deliberately not expose the current IR part's position to the kOS user.

Link to comment
Share on other sites
kcs123

kcs123

Posted
Posted

Thanks for brief explanation on kOS, Steven. That brings me idea how to exploit rules :), if it is possible of course :)

1.) Current position of any IR part is visible trough right click menu. - you can read it, but you can't set it

2.) there is no GUI for adjust on right click menu - you can't set variable to desired value

3.) move +/- is availabe trough AG (also move to min/max position) - you can bind AG to do move part to chosen direction

So, according to rules it is possible to write script like this:

Preseted action groups should be like this:

AG1 = move IR part in positive direction

AG2 = move IR part in negative direction

Do AG1 until IR position = desired_value;

Since you can exploit it, my suggestion is to alow parts fields/functions that is already available trough AG to be also available trough kOS scripts.

Don't be so stiff on your own rules :) In that way you can spare AG fields for other things that some user may need for ship.

Just a quick thought, I understand that you have to respect game engine and other modders rules, it is not easy to maintain high level of compatibility between large number of mods from various authors without rules that everyone need to respect.

Link to comment
Share on other sites
Dunbaratu

Dunbaratu

Posted
Posted
You have my blessing to utilize whatever you see in the right click menu to get kOS working. As long as I don't have to code anything extra you have free reign to do as you please.

I've just had a look at the github and it looks as if some new fields have had the guiActive=true parameter added to them since the last time I tried this when I made that video. When I made the video, those fields I needed were still hidden. Now it looks like they're not anymore. Thank you for the change. I'll have to get the update and try again, making a smarter version of the script now that it can read the position.

Link to comment
Share on other sites
sirkut

sirkut

Posted
  • Author
Posted
I've just had a look at the github and it looks as if some new fields have had the guiActive=true parameter added to them since the last time I tried this when I made that video. When I made the video, those fields I needed were still hidden. Now it looks like they're not anymore. Thank you for the change. I'll have to get the update and try again, making a smarter version of the script now that it can read the position.

I told Erendrake and it looks like I forgot to tell you too. I apologize for not notifying you.

Link to comment
Share on other sites
Fell-x27

Fell-x27

Posted
Posted

Sirkut, can you make IR-parts more inflexible? 2 rapier-engines in vacuum-mode can insanely deform it and we have bad thrust-vector as result :(

There is no ways to fasten parts, which can move. So, please, make them harder in active joints :)

Link to comment
Share on other sites
MartGonzo

MartGonzo

Posted
Posted
Just wondering - was anything ever figured out about why TweakScaling an IR part up to 2x size works fine, but anything over 2.0 doesn't rotate/move anymore?

All the infernal robotics part default to the largest sizes, they should all work.

Link to comment
Share on other sites
AccidentalDisassembly

AccidentalDisassembly

Posted
Posted
All the infernal robotics part default to the largest sizes, they should all work.

When I say TweakScaling an IR part up to 2x size, I mean 2x its standard size. As in twice as large as it starts out. This works fine - I've rewritten all the TS stuff to be much cleaner and easier, and scaling up to 2x the original size of the part does not cause problems. Things move like they should, as far as they should, etc. But 2.5x scale (or 3x, or 4.238x, anything over 2x) using the exact same code causes the part not to work at all.

Link to comment
Share on other sites
sirkut

sirkut

Posted
  • Author
Posted
Sirkut, can you make IR-parts more inflexible? 2 rapier-engines in vacuum-mode can insanely deform it and we have bad thrust-vector as result :(

There is no ways to fasten parts, which can move. So, please, make them harder in active joints :)

It's the nature of configurable joints. Just have to deal with it. Use active struts to see if it will help but there is nothing I can do.

I'll look into tweakscale issue. What does the log file say?

Link to comment
Share on other sites
MartGonzo

MartGonzo

Posted
Posted
When I say TweakScaling an IR part up to 2x size, I mean 2x its standard size. As in twice as large as it starts out. This works fine - I've rewritten all the TS stuff to be much cleaner and easier, and scaling up to 2x the original size of the part does not cause problems. Things move like they should, as far as they should, etc. But 2.5x scale (or 3x, or 4.238x, anything over 2x) using the exact same code causes the part not to work at all.

Well I don't know if you are running a different tweakscale / IR version from me but I can't scale them beyond the size they start at they only scale down and all the sizes work as far as I can tell.

Link to comment
Share on other sites
AccidentalDisassembly

AccidentalDisassembly

Posted
Posted (edited)
It's the nature of configurable joints. Just have to deal with it. Use active struts to see if it will help but there is nothing I can do.

I'll look into tweakscale issue. What does the log file say?

I'll try to come up with a log and append it to this post when I do - meanwhile, I had a kind of weird, possibly impossible question.

I get the impression that IR joints are sturdier the heavier the IR part is - I tried making the mass of a rotatron something like 30 tons (ridiculous, I know) and it seemed to make the whole system more rigid, attached engines kind of "pushed out" from the joint less.

So, question number one is: is that accurate? If the parts weighed even more, like 500 tons, would the joints be even more stable? Or is this a perception thing on my end?

Second part of that question, and the weird part: I know that Goodspeed parts have a configurable test weight that uses a resource called "ExtraTons", one unit of which weighs one ton, to add or subtract weight from that part. Is it possible to create a resource with negative mass? If so, I wonder if the following scenario would work at all:

1. Make IR parts weigh something ridiculous in order for them to have stiff joints.

2. Add this resource, invisibly if possible, to IR parts such that the net weight of the system is the weight the part really ought to be.

3. In theory, the actual mass of the part might be used to determine joint stiffness, and the negative-mass resource would then cancel out most of that mass so that the whole vessel wouldn't weigh so much.

Would that even work?

EDIT: logs. Here's my procedure:

1. New game. Go to SPH. Build craft with some parts.

2. Put a rotatron on it, scale it to 2.5x.

3. Launch.

4. Use IR control to attempt to rotate part. SOMETHING appears to rotate in the part (sort of...), but the actual rotating platform that normally turns does not. When it's an extendatron, the part that usually extends instead kind of moves to the side and backward relative to where it would move normally. Eventually (maybe when power ran out?) the IR control window just closed itself and the craft did some weird, mild bouncy things.

5. Closed KSP and copied logs.

Output_log: https://dl.dropboxusercontent.com/u/59567837/output_logIRLargeScale.txt

KSP.log in case it's useful: https://dl.dropboxusercontent.com/u/59567837/KSPlog_IRLargeScale.log

Also, just in case that's a concern, I am pretty sure my TweakScale configs are not at issue - they seem to work flawlessly for anything scaled 2.0x, 1.5x, 1.0x, 0.5x, and 0.25x... I removed all TS modules from part configs and instead put everything (including scaletypes) in an MM patch. This is the MM config: https://dl.dropboxusercontent.com/u/59567837/Rework_TweakScale_New.cfg - which also eliminates the need to set individual values for every mass or muMechToggle variable for every rescaleFactor.

SECOND EDIT: Basically don't have a clue what's going on with the scaling interactions. I'm using TS 1.44, but same applies to newer (and in some ways buggy) versions.

Certain rescaleFactors applied to parts makes them not work, basically. I used an MM config to duplicate various IR parts with TS modules built in during duplication, names changed, etc. The parts (rescaleFactor of the part and associated muMechToggle variables) are scaled up 4x by the MM patch. The TS module applied to these new parts allows for 0.625x, 0.75x, 1x, 1.5x, and 2x scaleFactors. The really weird part is that now, after duplicating these parts, the TweakScale configs that previously worked on the NORMAL parts no longer do. The normal parts move fine when scaled to 0.25x, 0.5x, and 1x, but no longer work at 1.5x and 2x. The duplicated parts work fine when scaled to 0.625x, 0.75x, and 1x, but not 1.5x or 2x either. What. The. Hell. This changed even though I didn't change any of the code previously applied to non-duplicated parts. Log: https://dl.dropboxusercontent.com/u/59567837/output_logIRLargeScale2.txt

Edited by AccidentalDisassembly
Link to comment
Share on other sites
jospanner

jospanner

Posted
Posted

Hi, I'm experiencing a bug... this install has no other mods than IR and Tweakscale.

http://imgur.com/yYplg6s

This happens with any ship as soon as I put a single IR part on it. In this case it was just a Mk1 pod with a hinge joint stuck on the top. As soon as I click "launch" it loads and does this. I can't revert either, only go to the space centre. This is with a fresh sandbox save.

Here's my KSP_Data/output_log.txt:

https://www.dropbox.com/s/ra69xw8tj3mru2w/output_log.txt?dl=0

Link to comment
Share on other sites
sirkut

sirkut

Posted
  • Author
Posted
Hi, I'm experiencing a bug... this install has no other mods than IR and Tweakscale.

http://imgur.com/yYplg6s

This happens with any ship as soon as I put a single IR part on it. In this case it was just a Mk1 pod with a hinge joint stuck on the top. As soon as I click "launch" it loads and does this. I can't revert either, only go to the space centre. This is with a fresh sandbox save.

Here's my KSP_Data/output_log.txt:

https://www.dropbox.com/s/ra69xw8tj3mru2w/output_log.txt?dl=0

You may need to do a clean install. I'm seeing errors such as:


Cannot find a Module of typename 'TacLifeSupport'
Cannot find a Module of typename 'DeadlyReentryScenario'
Cannot find a Module of typename 'CrewFilesServer'
Cannot find a Module of typename 'DangIt'
Cannot find a Module of typename 'KerbalConstructionTimeData'


Cannot find a Module of typename 'StnSciScenario'
Cannot find a Module of typename 'KerbalAlarmClockScenario'
Cannot find a Module of typename 'CustomAsteroidSpawner'
NullReferenceException: Object reference not set to an instance of an object
  at IVASun.LateUpdate () [0x00000] in <filename unknown>:0

Do you do a clean uninstall of the other mods?

Do you have any MM configs lying around?

Link to comment
Share on other sites
sirkut

sirkut

Posted
  • Author
Posted
I tried rolling Tweakscale back to 1.45 on this new install (because it updated to 1.46 yesterday), and I'm still getting the same issue.

Try version 1.43 (which is what I have) and see if you get the same issue.

Link to comment
Share on other sites
sirkut

sirkut

Posted
  • Author
Posted
It also works with 1.44. According to the changelog for what I assume is supposed to be 1.45:

Could this be the problem? It seems it has problems with data types according to the log.

Biotronic has updated TweakScale so it should be working again. I haven't had a chance to test it.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...