sirkut / infernalrobotics Goto Github PK

I'd have submitted a pull, but it looks like the configs aren't source controlled?

Part config from other parts works:

MODULE
{
name = TweakScale
type = IR_RoboticStock
TWEAKSCALEEXPONENTS
{
mass = 0.025, 0.05, 0.1
}

TWEAKSCALEEXPONENTS
{
    name = MuMechToggle
    ElectricChargeRequired = 0.5,1.0,2.0
}

}

I am sure that these buttons had an original purpose, however it is unclear what that is. I know that people like Scott Manley have confused these for intending to actually rotate the joint of the part, rather than the part itself.

I suggest either clarify the functionality of these buttons and make them work as intended if they don't already (axis seems wrong), or remove them from the editor window. Of course for compatibility retain the core function so as not to break old craft.

Would be nice if free spinning joints were a flag that was set, rather than a fudge of the spring force. Particularly, this would allow checks to be made to have Free joints not appear in the group listing in the VAB/SPH. Also, I would like for joint limits to still be valid, for instance for a free moving hinge.

It would be nice to have some limited control of the angle of parts within the VAB/SPH. After seeing TweakScale resize the part and reposition the parts that are attached to it's surfaces, surely it must be possible to adapt this to rotating (or translating) the joint of a part?

Suggested by Gryphorim on the forums:
http://forum.kerbalspaceprogram.com/threads/37707-0-23-5-Magic-Smoke-Industries-Parts-Infernal-Robotics-0-14-stable%29?p=1125924&viewfull=1#post1125924

Preferred Proposal:

Would you be willing to alter the KSPField parameters for rotation and rotation axis so that they appear (read only) on the right-click popup panel for the IR parts? (I think it's just guiEnabled=true, so it's not a matter of how hard it is, but of whether you're willing to expose the numbers to view).

The reason is for purely selfish reasons but I think IR would benefit from a lot from this too - It has to do with making the mod Kerbal Operating System interact well with IR and get the two to play nice together so users can write scripts that move the robotic hinges. I'm one of the two active devs on the kOS mod at the moment.

We're trying to come up with a good way to let kOS do everything a player could do manually as a pilot. One scheme we are partway through implementing is exposing all the KSPFields, KSPEvents, and KSPActions for PartModules to the kOS script so it can "click" the same buttons the player can click when flying manually, and so it can "look at" the same readouts the player can look at when flying manually, and tweak the same tweakables.

But one problem we immediately thought of is that just because KSPFields have to be public to the other programmers that doesn't mean the maker of the mod wants them to be exposed to users. So we wanted to respect the decisions of all the other mod writers and only expose those KSPFields which are currently visible to the human player in the rightclick panel. If it's not guiEnabled at the moment (or ever), then we won't let users see it.

And that's where this request comes from. We'd like to let kOS scripts "read" the current position of IR hinged parts, since unlike the human player the script can't just look at the screen to figure it out. But those fields are hidden from the gui in IR (because they're actually accessed through IR's own unique gui windows) and we'd have to violate the rule we're trying to adhere to if we exposed them.

A kOS script can move an IR hinge using the action groups, but it can't read where the hinge currently is, at the moment, because we're trying to avoid writing special exception one-off cases for each mod out there.

Secondary, alternate proposal

If you are unwilling to expose these two KSPFields to the user on the rightclick gui panel, would you mind if we made an exception for your mod and allowed kOS users to read them even though they're not on the gui panel? I'm thinking of something involving a whitelist we make in kOS - KSPFields that are on the whitelist are fields we will allow users to access even though they aren't visible on the menu panel.

This secondary proposal would involve absolutely zero work from IR at all - just your blessing for us to do a thing that is already technically possible, but might be a bit rude and unstable for us to implement without your go-ahead.

Thanks for your time in reading this. I think this would benefit both kOS and IR. We get users requesting that they wish they could control IR parts through their kOS scripts a bit better than they can now, where the script has to be "blind" about the current position of the hinge.

Wouldn't be handy if we could use the same joint multiple times in other groups: when using a ARM for grabbing things, it would be handy able to move the grabber forward with the joints rotating so that it goes straight forward, yet want to be able to use the first joint seperately to pitch up the arm and oter parts aswell.

And also hide some of the groups from the GUI as some sort of collapsable menu type.

When joining the rover on the right to the craft on the left with an articulating arm, all the moving parts on the joining arm stopped working. All the other moving parts continued to work. I was able to reproduce in orbit with a model of the canadarm2. Again, all the parts between the root and the larger target vessel became immobile. In each case I was focused on the articulated craft during docking. I'd guess it has something to do with changing the root and therefore the direction of the branches in the vessel tree, but that's only a guess.

(Reloading the vessel from a save seems to fix the issue.)

If I'm mirroring parts in SPH and select a group(assumed, might work with just one if IR) of parts, possibly ones that have had rotation adjustments, the node indicator sprites will remain stationary in 3d space while I can move the selected parts around. They will not attach unless I turn mirroring off.

I can't seem to iterate correctly though negatives and positives values when I'm building presets. It looks like the values always move forward (i.e. I can't move from a positive angle to a negative one, the preset API always put the negative one first). It is a severe issue when I'm building extensible arms with multiple cylinders and hinges, because I need some parts to be facing the opposite direction and decrease in angle or position. Please fix.

Would be nice if we could adjust how long it takes for a part to start moving at the set speed, so that they would slowly accelerate (and/or decelerate to a stop).

Right now when applying movement to the parts, they immediately move at the specified speed.

For example; we could set the servo acceleration to take 2 seconds and deceleration to take 1.5s and have servo speed at 1.

This might decrease the wobble with robotic arms and cranes when moving around large objects.

Add the ability to specify a speed multiplier per part in the VAB/SPH. The intention of this is to allow 90 degree, 180 degree and 240 degree rotational parts (such as those in the model rework) to be all reach the end of their travel at the same time whilst controlled as a single group.

This is an issue I encounter very often, especially when combining a clamp-o-tron with a hinge. The root cause is a geometric issue

I have a rover that grabs a tool with a clamp. The tool consists of two hinges and a clamp at the end (Macaroni-L shaped).

The tool works great in the beginning, but gets damaged after moving things around. (docking/undocking), causing unwanted moves and stresses. The problem gets as severe as tipping over a 20-ton construction vehicle and making it fly in the air like a crazy poltergeist!

Broken hinge:.

Same broken hinge before I tried to move it:

I can supply a Craft file that makes the problem appear.

Also, another interesting side-effect is that the gantries get affected too, somehow, with their bases now hovering in the air.

I was playing around earlier and observed that some tweakables do not apply to all they symmetry groups. For example, put lights in a symmetry mode and the Light On tweakable is separate for each, yet the colour is common across them all.

I wonder whether this could be applied to specific joints we allow (e.g rotatrons), so that the default behaviour is to invert the rotation (since that's useful to most people), but they can then disable it by right clicking on the problem part. Of course this shouldn't be available to all parts, since that may cause clipping.

I updated my save game to 0.24.2 and new mods, and the game complains that it can't load some ships because the part IR.StrutDecoupler.Large is missing. What is the new name for this part, so I can fix the save file?

IR parts can be scaled down in size, but not up. Someone, somewhere wrote that it might have to do with node sizes getting increased by TweakScale at a certain threshold - probably 2x size, but I really have no clue. Would be great!

I'm sorry I can't be more specific. I'm trying to find a reproducible set of steps that make the issue occur. I've sent missions to duna and eve using IR hinges attached to long struts to use as adjustable landing gear, so that I can balance the ships if I land on uneven terrain. When I build in the VAB they're fine, when I launch them they're fine, but somewhere between my ejection burn and my insertion burn, something goes haywire. When switching back to a ship, I will find parts still connected to each other in terms of behavior, but far away from where they're supposed to be attached visually.

All of the interface controls operate as expected, as far as I can tell. The servo screen lists everything it's supposed to. The editor screen lets me move groups around. Using the servo screen to adjust the hinges has the correct effect when the hinges are still visible.

Here's a shot of a crane arm I built using rotatrons, hydraulic cylinders, and hinges. You can see they're floating in space, not attached to each other and the craft.

Here it is after I've rotated the Shoulder H hinge about 90 degrees.

Same thing from another angle:

I've looked through the log, but the only IR-specific entries I see are "setupJoints - !gotOrig" and I do not understand what that means. Based on where it is in your code, it seems likely to have something to do with it, but I'm not very familiar with KSP modding so I'm not sure.

Please let me know what other information I could provide that would be of help. I can provide the craft file of the unbroken version of the ship pictured above, as well as the save file containing its current state, if that would help. I only see a way to attach images here, so I will have to post them somewhere else if you want them. Same for the KSP log file.

Thanks for making an awesome mod! Combined with KAS it truly revolutionizes the game and opens up a lot of cool possibilities!

In VAB/SPH, after undo, the main IR window with group arrangement goes unresponsive. It basically blanks out when you mouse over. I can fix by saving the and re-loading the craft file.

How to reproduce: use any girder, attach a hinge to it. Use either "move" buttons in group editor (<-/->) or position editor gui. Open the hinge a little, close it, repeat until it starts to collapse into itself. See screenshot:

Note the "-1" in position editor. Problem appears to exist only in editor, I wasn't able to reproduce it in flight.

As an extension of #39, I'd like to also suggest the following:

preventPresetOverride = true

Ziw noted that this seems like a rather restrictive flag, but the reason I'd like to see this is because I'd like to design a IR-powered payload rack carousel that "steps" to each angular position, and I don't want people to misconfigure my specific part in the VAB/SPH (otherwise, we'd have a situation where someone mucks around with my presets and ends up having the carousel turn halfway, making it impossible to grab something out of the rack).

In SPH or "mirrored" symmetry with one part mirrored to both sides, especially rotatrons. Set one side to "inverse" so they both move the same way. If you right-click a rotatron after setting unique min/max values via the main "grouping" GUI, the values of one immediately overwrite the min/max values on the other side.

I'm guessing the values on both refresh when the right-click GUI is drawn. I suggest not updating those values unless the UI sliders are moved

In place of where the tweakables should be there is just empty space. This is likely related to the release of KSP 0.24.1.

http://forum.kerbalspaceprogram.com/threads/114014-WIP-MSI-s-Infernal-Robotics-Plugin-Rework-%28Updated-25-03-2015%29?p=1806745&viewfull=1#post1806745

ZodiusInfuser is apparently working on allowing a serialized list of intermediate positions to be specified within the robotics part CFGs themselves:

presetPositionsSerialized = 0.0|90.0|180.0|270.0

This could be useful for pre-configured servo / stepper motors made by third-party add-on authors.

I still can't replicate the issue other than to say "Mirror parts, maybe, then set min-max values, then manually adjust position, and then move the mirrored parts. But this is what I'm seeing. Rotatrons and Hinges where the 0 position value moves over time.

http://cloud-4.steampowered.com/ugc/22839855466945507/875B175B84CFAD937C030A438563388FBFA4B738/

Note the tweakable context menu shows "Rotation: 0" on a 90 deg pivot where it's definitely not at the zero position.

Completely broken in ksp 0.23.5