Jump to content

[0.90] Magic Smoke Industries Infernal Robotics - 0.19.3

sirkut

By sirkut
in KSP1 Mod Releases

 Share

Recommended Posts

Jaxx

Jaxx

Posted
Posted (edited)
@Jaxx:

I have no idea since Infernal Robotics is not only compatible with TweakScale, it requires TweakScale. Are you using the latest versions of both mods?

Please read the How to Get Support (READ FIRST) sticky in the Support (modded installs) forum.

I'm just exasperated from getting tossed from one mod dev to another because no one really knows what the problem is. https://dl.dropboxusercontent.com/u/74775048/output%20logs/ksp/output_log.txt

If you're going to tell me to go to someone else, I've already been to them, and they told me to go to someone else.

Here's another one https://dl.dropboxusercontent.com/u/74775048/output%20logs/ksp/output_log%20%282%29.txt

Edited by Jaxx
Link to comment
Share on other sites
BudgetHedgehog

BudgetHedgehog

Posted
Posted
I'm just exasperated from getting tossed from one mod dev to another because no one really knows what the problem is. https://dl.dropboxusercontent.com/u/74775048/output%20logs/ksp/output_log.txt

If you're going to tell me to go to someone else, I've already been to them, and they told me to go to someone else.

Here's another one https://dl.dropboxusercontent.com/u/74775048/output%20logs/ksp/output_log%20%282%29.txt

The first one has 

[KSP Interstellar] Exception caught adding to: FNSmallerAugmentedArcjet part: System.InvalidOperationException: Operation is not valid due to the current state of the object

  at System.Linq.Enumerable.First[ModuleInfo] (IEnumerable`1 source) [0x00000] in <filename unknown>:0 

  at FNPlugin.PluginHelper.Update () [0x00000] in <filename unknown>:0 

..

ArgumentException: An element with the same key already exists in the dictionary.
  at System.Collections.Generic.Dictionary`2[System.String,ScienceExperiment].Add (System.String key, .ScienceExperiment value) [0x00000] in <filename unknown>:0 

  at ResearchAndDevelopment.loadExperiments () [0x00000] in <filename unknown>:0 

  at ResearchAndDevelopment.GetExperiment (System.String experimentID) [0x00000] in <filename unknown>:0 

  at DMagic.DMConfigLoader.configLoad () [0x00000] in <filename unknown>:0 

  at DMagic.DMConfigLoader.Start () [0x00000] in <filename unknown>:0

And points to FinePrint in the stack trace at the bottom.

The second again has that DMagic error and again, points to the contract system in the stack trace.

I could find no errors regarding IR or TweakScale in either - both appeared to load correctly. When you say you've already been to mod devs, who do you mean? I'm hoping it's Arsonide, DMagic and either FractalUK or WaveFunctionP, depending on which version you have installed - I can't seem to find KSPI on the list of installed mods for some reason.

Just saying.

Link to comment
Share on other sites
sirkut

sirkut

Posted
  • Author
Posted
I'm just exasperated from getting tossed from one mod dev to another because no one really knows what the problem is. https://dl.dropboxusercontent.com/u/74775048/output%20logs/ksp/output_log.txt

If you're going to tell me to go to someone else, I've already been to them, and they told me to go to someone else.

Here's another one https://dl.dropboxusercontent.com/u/74775048/output%20logs/ksp/output_log%20%282%29.txt

Are you using 64bit KSP? There's a running joke of sorts that KSP 64bit is so unstable it's not even worth trying to help because the crashes are random and generally the mods don't cause the issue.

Also, humor me. Temporarily remove ALL mods and install just Infernal Robotics (and TweakScale since it's required) and tell me then if it crashes. I'll be up front that ALL the people who have reported that Infernal Robotics has crashed KSP were incorrect due to the fact that they were using 64bit KSP and as I have stated before it's severely buggy.

ps. Are you using the correct version of Active Texture Management? I believe there is a 32bit and 64bit version.

Link to comment
Share on other sites
Alewx

Alewx

Posted
Posted
Are you using 64bit KSP? There's a running joke of sorts that KSP 64bit is so unstable it's not even worth trying to help because the crashes are random and generally the mods don't cause the issue.

That is not a joke, that is sad reality.

I even got crashes just by using x64 with alternate resourcepanel.

IR is so rocksolid, it naver gave me any real trouble, except when I use it out of it natural bounds.

Link to comment
Share on other sites
Jaxx

Jaxx

Posted
Posted
Are you using 64bit KSP? There's a running joke of sorts that KSP 64bit is so unstable it's not even worth trying to help because the crashes are random and generally the mods don't cause the issue.

Also, humor me. Temporarily remove ALL mods and install just Infernal Robotics (and TweakScale since it's required) and tell me then if it crashes. I'll be up front that ALL the people who have reported that Infernal Robotics has crashed KSP were incorrect due to the fact that they were using 64bit KSP and as I have stated before it's severely buggy.

ps. Are you using the correct version of Active Texture Management? I believe there is a 32bit and 64bit version.

I've repeated the process three times by uninstalling IR and reinstalling, testing each time, and loading the pre-existing save with IR installed is what's crashing it, no random factor involved. I know it's two mods not playing well but every time I go to where the stacktrace says I should, the mod developers tell me to go elsewhere. Arsonide said the same thing, you are, fractal_uk, and DMagic was never even involved.

Link to comment
Share on other sites
Master Tao

Master Tao

Posted
Posted

@Jaxx:

It's absolutely possible this is just another random KSP Win 64-bit crash, and since you've caused the crash with different mods, it's probably not the mods' fault at all.

There is one thing to try based on those logs. It looks like both crashes happened while handling contracts. Could you rebuild the contract database from the debug menu? You'll lose any current contracts.

Link to comment
Share on other sites
Jaxx

Jaxx

Posted
Posted (edited)
@Jaxx:

It's absolutely possible this is just another random KSP Win 64-bit crash, and since you've caused the crash with different mods, it's probably not the mods' fault at all.

There is one thing to try based on those logs. It looks like both crashes happened while handling contracts. Could you rebuild the contract database from the debug menu? You'll lose any current contracts.

I can if that doesn't rely on having the KSC load, since it crashes before I can do anything else. I'm assuming it'd rebuild it under the assumption of the planetary progress I'd made?

Having done this and installed Universal Storage, Infernal Robotics, and Interstellar with no apparent issues, I just wanted to say thank you, Tao, for being helpful. Rep + . :D

I suspect FinePrint was having problems making contracts with new mods installed for some reason, so wiping it did just the trick.

Edited by Jaxx
Link to comment
Share on other sites
sirkut

sirkut

Posted
  • Author
Posted (edited)
I can if that doesn't rely on having the KSC load, since it crashes before I can do anything else. I'm assuming it'd rebuild it under the assumption of the planetary progress I'd made?

Having done this and installed Universal Storage, Infernal Robotics, and Interstellar with no apparent issues, I just wanted to say thank you, Tao, for being helpful. Rep + . :D

I suspect FinePrint was having problems making contracts with new mods installed for some reason, so wiping it did just the trick.

I'll consider this your apology. j/k. Glad you got everything working again.

Updated to 0.19.1 Enjoy.

Edited by sirkut
Link to comment
Share on other sites
  • 2 weeks later...
Fell-x27

Fell-x27

Posted
Posted

There is one bug within hangar movements.

1) take some robotic part (hinge is good example).

2) open movement editor for it, or IR panel.

3) Turn this part forward and backward many times aaaand..

4) We can see offset. Part looks like more or less than 0 degree, but in info we see 0.

5) Go to launchpad. Part will be moved to default state, but base of part will be moved, not active segment.

6) Back to hangar and...all very bad, because part now fixed in wrong position.

Link to comment
Share on other sites
Fell-x27

Fell-x27

Posted
Posted (edited)
Fell-x27,

Are you using IR 19.1? It should prevent that problem (though I haven't had time to try yet).

Yes, 0.19.1. Unfortunately, this bug is still exist here. Yes, I installed new version after deleting an old. Not by merging.

Gantry Rail is bugged too. Just try to change state of it in hangar editor and after try to use it on launchpad with hangar-changed position.

And after all, door hinge have wrong axes mirroring, when you use symmetry.

P.S. Sorry for my English, it's not my native lang, and I still have some troubles with grammar.

Edited by Fell-x27
Link to comment
Share on other sites
Master Tao

Master Tao

Posted
Posted

Had a chance to test – the creep bug is still present, though the effects have been much reduced.

For the door hinges, you can fix their orientations individually using the rotate buttons in the IR window.

Link to comment
Share on other sites
Fell-x27

Fell-x27

Posted
Posted

For the door hinges, you can fix their orientations individually using the rotate buttons in the IR window.

But not when some part already attached to it. Its bad, when you mirroring some complete and confidured system with it.

Link to comment
Share on other sites
JordanL

JordanL

Posted
Posted
Had a chance to test – the creep bug is still present, though the effects have been much reduced.

For the door hinges, you can fix their orientations individually using the rotate buttons in the IR window.

Yeah, this creep bug is preventing me from building my crane unfortunately. It's especially bad for rotating parts.

Link to comment
Share on other sites
Maelin

Maelin

Posted
Posted

I've been having some trouble with rotation limits on rotatrons disabling themselves and not reliably staying enabled on some of ZI's rework parts (haven't tried on original MSI parts yet). Is this a known issue already, or should I poke around with it some more and see if I can reliably reproduce it?

Link to comment
Share on other sites
Fell-x27

Fell-x27

Posted
Posted
Yeah, this creep bug is preventing me from building my crane unfortunately. It's especially bad for rotating parts.

So, just test your IR-systems on launchpad and after it configure them in hangar. Not awesome, but works.

Link to comment
Share on other sites
sirkut

sirkut

Posted
  • Author
Posted
Yeah, this creep bug is preventing me from building my crane unfortunately. It's especially bad for rotating parts.

Keep in mind not too long ago you didn't even have the privilege of moving the parts in the VAB/SPH

So the chances of having bugs may occur. If I have CLEAR instructions on how to reproduce the bug please say so. The one I fixed was when it reaches the limit then the part is removed causing the base to shift by 1 increment.

Link to comment
Share on other sites
Master Tao

Master Tao

Posted
Posted

More experimenting shows the creep bug is solved for a few situations: :)

  • Closed Powered Hinge at 0 degree limit
  • Open Powered Hinge at 0 degree limit
  • Powered Hinge 90 Degrees at 0 degree limit
  • Rotational parts at 0 degree limits

There's now an opposite creep bug for hinges at other limits: the animations for the Powered Hinge 90 Degrees, Closed Powered Hinge, and Open Powered Hinge do not reach 180 degrees, and the Powered Hinge animation doesn't reach ±90 degrees. This results in creep away from the limit, rather than past the limit as before.

Picture of a Closed Power Hinge with reverse creep.

The translational parts show creep past the limits on both ends. Rotational parts show the same reverse creep as the hinges for non-zero limits.

Short version (rotating/pivoting parts):

  1. Move a part in the editor to a non-zero limit. The part will not reach the limit.
  2. Move the part back a little.
  3. Repeat 1-2 to increase creep.

Translational parts:

  1. Move a part in the editor to either limit. The part will pass the limit.
  2. Move the part back a little.
  3. Repeat 1-2 to increase creep.

Minor issue: The click-through bug is still present for the Position Editor window.

Link to comment
Share on other sites
JordanL

JordanL

Posted
Posted
Keep in mind not too long ago you didn't even have the privilege of moving the parts in the VAB/SPH

So the chances of having bugs may occur. If I have CLEAR instructions on how to reproduce the bug please say so. The one I fixed was when it reaches the limit then the part is removed causing the base to shift by 1 increment.

Wow. See this is an example of how sometimes introducing a feature makes people not think about what if that feature wasn't there.

I didn't even consider testing on the pad instead of in the VAB/SPH. Thanks, that will solve my problem. :)

Link to comment
Share on other sites
sirkut

sirkut

Posted
  • Author
Posted
More experimenting shows the creep bug is solved for a few situations: :)

  • Closed Powered Hinge at 0 degree limit
  • Open Powered Hinge at 0 degree limit
  • Powered Hinge 90 Degrees at 0 degree limit
  • Rotational parts at 0 degree limits

There's now an opposite creep bug for hinges at other limits: the animations for the Powered Hinge 90 Degrees, Closed Powered Hinge, and Open Powered Hinge do not reach 180 degrees, and the Powered Hinge animation doesn't reach ±90 degrees. This results in creep away from the limit, rather than past the limit as before.

Picture of a Closed Power Hinge with reverse creep.

The translational parts show creep past the limits on both ends. Rotational parts show the same reverse creep as the hinges for non-zero limits.

Short version (rotating/pivoting parts):

  1. Move a part in the editor to a non-zero limit. The part will not reach the limit.
  2. Move the part back a little.
  3. Repeat 1-2 to increase creep.

Translational parts:

  1. Move a part in the editor to either limit. The part will pass the limit.
  2. Move the part back a little.
  3. Repeat 1-2 to increase creep.

Minor issue: The click-through bug is still present for the Position Editor window.

The fix for the rotational parts will be in the next release when KSP 0.25 is released. I can't however reproduce the translational bug. What am I missing?

I'll see about fixing the click-through. I'm unfamiliar with the editor lock code that TriggerAU was so kind to provide.

Link to comment
Share on other sites
Master Tao

Master Tao

Posted
Posted
The fix for the rotational parts will be in the next release when KSP 0.25 is released. I can't however reproduce the translational bug. What am I missing?

I tested the adjustable rail and pistons. Moving them out and back repeatedly caused them to creep into their own bases. The same was true at the extended end. They're behaving just as they did with 19.0. If that's not clear, I'll see about putting together a sequence of screenshots or video.

Link to comment
Share on other sites
sirkut

sirkut

Posted
  • Author
Posted
I tested the adjustable rail and pistons. Moving them out and back repeatedly caused them to creep into their own bases. The same was true at the extended end. They're behaving just as they did with 19.0. If that's not clear, I'll see about putting together a sequence of screenshots or video.

When you have time that would be great, I'm just not doing it right I suppose.

I also have the click-through fixed so that will be in the next update.

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