[1.2.2](Dec10/16) Action Groups Extended: 250 Action Groups, in-flight editing. Now kOS/RemoteTech

[Diazo]

Having thought on it, I am going to go with the breaking compatibility fix.

I'll push that out tonight when I also fix the symmetry bug from the last page.

@Honeyfox: Do you know if this is a known issue they are looking at, or should I go post about it to get it in the queue to be fixed?

D.

[acc]

That is what I'm looking for. Great work and keep on

[JeffreyCor]

If it can be fixed with RemoteTech2 correcting the addressing but on that end it would be a superior solution as it sounds like this is also the problem with KAS not working properly with those antennas. I had previously posted over there regarding that issue but had never received a reply. Though the unknown wait for .24 and thus the update to RT2 makes quite a quandary as it make it work now, or wait for them to maybe make it work over there.

[brusura]

Do you mean just the Flight Window? I made that as small as possible because I was expecting people would like to have that open so they can see their action groups now that you can name them. Do you mean the other windows? (Selected parts, Group, etc.) Those are not supposed to be visible on flight start and I would ask for more info as that would be a bug report.

D.

I guess he is talking about the Flight Window as I have the same "problem" , it would be nice to have it configurable to show or not to show everytime

[BigD145]

If it can be fixed with RemoteTech2 correcting the addressing but on that end it would be a superior solution as it sounds like this is also the problem with KAS not working properly with those antennas. I had previously posted over there regarding that issue but had never received a reply. Though the unknown wait for .24 and thus the update to RT2 makes quite a quandary as it make it work now, or wait for them to maybe make it work over there.

.24 will see a radically different RT2, supposedly. KAS also has OLD known issues with RT2 and disabling the RT2 dll does not fix it. Hopefully that is eventually fixed but until then, Diazo, you should take the reins and push for better code. People use mods that don't freeze their game.

[Zardiz]

@Zardiz: I can confirm that bug. I've narrowed down the exact line of code causing it, but I'm out of time to apply a fix tonight.

I'll see if I can get something released tomorrow after work to fix this.

D.

Great to hear you know whats causing it! And regarding the animation issue with IR, there is indeed so many mods right now that are in void between game versions, just waiting for 23.5 / 24. I was happy to see you updated your other mod (that I have been using for months, fixed the most annoying part of it always being visible and not remembering where I place it).

Think we have to wait for that code-rebuild of IR to properly adress this I guess?

[rifter]

On Linux, currently (not sure about OSX), the plugin is looking for AGext.cfg, while the file is named AGExt.cfg. Thus, lots of log bloating and null pointer exceptioning does occur. The obvious (quick) workaround is to rename the file in question.

[Faark]

@Diazo

Have you considered uploading this plugin to a public code host like Github? There are a few things i would like to... customize, and that would make it a lot easier.

I would generally concur, better if need be to break compatibility earlier than later.

But, in this case (thanks HoneyFox who clearly pointed the issue), the fault is entirely on RemoteTech. Any additional module will still change the module index number, and it can't be a viable solution to ask for any possible other modules (heck, even new ones from Squad?) to be renamed so to be loaded after "ModuleAnimateGeneric". The solution chosen by RemoteTech to use a module index is not perfect and needs to be addressed (and that may already be in the works, as Cilph said to be rewriting large parts of RT2).

What? Why does RT have to support other mods changing its parts? Yes, RT seems to not really support ModuleManager and that is sth RT should improve, but you cannot say RT is "broken" for not supporting ModuleManager. And Squad will definitively not swap modules of RT parts around, so they will not break anything.

Another way to avoid this specific compatibility issue would be to ditch ModuleManager and add ModuleAGExtData manually after the parts usual modules.

[Diazo]

@Faark: I'm certainly thinking about uploading to GitHub, it is more that these mods for KSP are the first real coding I've done so it is really just that I am unfamiliar with this stuff.

The other reason is I'd like to clean the code up a bit. I have dozens of lines I commented out while going through the various rewrites of the save/load routine that are now useless that I'd like to get rid of and I want to add some commentary as well.

Either way, it is going to wait for a couple more days while I hotfix the stuff that's coming up.

As for modulemanager, when I started this I did not know how to add the partmodule I use and modulemanager looked simpler to learn. Today, I think I know how to add the partmodule manually with code, but it is low on the priority list to go back and change.

D.

[diomedea]

What? Why does RT have to support other mods changing its parts? Yes, RT seems to not really support ModuleManager and that is sth RT should improve, but you cannot say RT is "broken" for not supporting ModuleManager. And Squad will definitively not swap modules of RT parts around, so they will not break anything.

Another way to avoid this specific compatibility issue would be to ditch ModuleManager and add ModuleAGExtData manually after the parts usual modules.

Well, you seem to have quoted me wrongly while writing about Squad swapping modules (definitely not what I wrote, and you better acknowledge you did so). About the rest, you think the fault is from MM? Certainly it's not. SO what? Are we to change every other mod and constrain KSP itself, because of RT2? Again, No.

[Diazo]

Well, this is odd.

Change my partmodule name to zModuleAGExtData, it still appears in front of ModuleAnimateGeneric when I look at the saved vessel in the persistence file.

Going to have to shelve this one, the symmetry bug is more critical and I need to fix it this evening. I suspect I'll have to move to adding my partmodule in code instead of in modulemanager to fix and that could take me a bit.

D.

[Diazo]

Okay, version 1.2 is out.

This has the symmetry bug fixed as reported by Zardiz and the Flight Scene window now remembers it's visibility setting as requested.

I also fixed the capitilization so Linux systems should no longer flip out.

This version does not include a fix for breaking the RemoteTech antenna animations. That is looking to be quite complex.

D.

Edited April 1, 2014 by Diazo

[Fraz86]

I believe I've managed to fix the RemoteTech compatibility issue. All you need to do is add the "Final" tag in your ModuleManager file, like this:

@PART[*]:Final
{

[INDENT]MODULE
{
[INDENT]name = ModuleAGExtData
AGXData = Empty
AGXNames = Empty
AGXKeySet = 0
AGXActivated = 0
[/INDENT]

}
[/INDENT]
}

[JedTech]

Do you think there are some parts which do not need the ModuleAGEData module? Like a Strut or other things that don't have action items? It might be better if we used search criteria that applied the module only to parts that we want it to instead of all parts.

[Diazo]

I believe I've managed to fix the RemoteTech compatibility issue. All you need to do is add the "Final" tag in your ModuleManager file, like this:

That's ModuleManager 2.0 only though isn't it?

I know ialdabaoth is back and MM 2.0 is soon, but MM 1.5.6 is still the last stable so that's what I'm distributing.

Another couple weeks for MM 2.0 to firm up and I'll be willing to move to that. As far as I know the first alpha release of MM 2.0 is available and that's it.

Do you think there are some parts which do not need the ModuleAGEData module? Like a Strut or other things that don't have action items? It might be better if we used search criteria that applied the module only to parts that we want it to instead of all parts.

But on what criteria? One of the big things I need to do is support all mods, hence the current "apply to every part in GameData". I'm not going to go and make custom MM configs for each mod.

Also, one of the long term goals is to move away from ModuleManager and add the PartModule in code anyways. Not going to happen in the next bit, but I am planning to do so.

D.

Edited April 1, 2014 by Diazo

[HoneyFox]

Well, this is odd.

Change my partmodule name to zModuleAGExtData, it still appears in front of ModuleAnimateGeneric when I look at the saved vessel in the persistence file.

Going to have to shelve this one, the symmetry bug is more critical and I need to fix it this evening. I suspect I'll have to move to adding my partmodule in code instead of in modulemanager to fix and that could take me a bit.

D.

No it has nothing to do with the name of your PartModule class name... it's the folder name of your plugin that matters.

So if you change your folder name to ZActionGroupExt, the plugin (and the ModuleManager cfg file inside that folder too) will be loaded after the RT2, hence there won't be such problem.

EDIT: Adding :Final is also a working solution, since it forces the MM cfg to be processed after all non-Final MM cfgs (including RT2's).

[Fraz86]

That's ModuleManager 2.0 only though isn't it?

I know ialdabaoth is back and MM 2.0 is soon, but MM 1.5.6 is still the last stable so that's what I'm distributing.

Another couple weeks for MM 2.0 to firm up and I'll be willing to move to that. As far as I know the first alpha release of MM 2.0 is available and that's it.

The "Final" tag is supported by MM 1.5.6.

Also, to follow up on jmanidb's suggestion, I believe you could at least safely restrict your module to parts that already have a module (I don't think there are any parts, stock or otherwise, that have actions associated with them but no module). I believe this could be accomplished with the following:

@PART[*]:HAS[@MODULE[*]]:Final

{

MODULE

{

name = ModuleAGExtData

AGXData = Empty

AGXNames = Empty

AGXKeySet = 0

AGXActivated = 0

}

}

[Mulbin]

EDIT - Ignore this post... think I have another mod messing things up!

Edited April 1, 2014 by Mulbin

[Diazo]

Okay, just tested the Modulemanger Final thing.

On my test installation it results in duplicate ModuleAGExtData modules, resulting in actions showing up twice in the game.

I suspect on a clean installation it would be fine, but on a game that's run Action Groups Extended previously I need to remove the old module first.

The Modulemanager documentation I was using is apparently old (as it did not include the Final option either) and I'm hoping someone can point me towards the Modulemanager syntax I need for that.

D.

edit: So, on an existing installation, this works:

@PART[*]:Final
{
MODULE
{
      @name = ModuleAGExtData
	@AGXData = Empty
	@AGXNames = Empty 
	@AGXKeySet = 0
	@AGXActivated = 0
}

}

but on a installation that has not run AGX before does not work as the @ is the "modify existing" setting.

Does modulemanager have a "modify if existing and add new if not"? statement available?

edit the second: Bah, I think I wrecked my test game. Can someone who has not upgraded to the remotetech fix change their AGExt\part.cfg to:

@PART[*]:Final
{
MODULE
{
      name = ModuleAGExtData
	AGXData = Empty
	AGXNames = Empty 
	AGXKeySet = 0
	AGXActivated = 0
}

}

If you get actions showing once, that works. If actions do not show, or show twice, it did not. Please post results if you do.

It turns out I had an orphaned part.cfg in my KSP directory so I now can't trust any of my modulemanager tests.

Edited April 2, 2014 by Diazo

[Diazo]

As KSP 23.5 is out, this fix is no longer needed.

Make sure the part.cfg file in GameData\Diazo\AGExt is as follows as you should be good to go.

@PART[*]:Final
{
MODULE
{
      name = ModuleAGExtData
	AGXData = Empty
	AGXNames = Empty 
	AGXKeySet = 0
	AGXActivated = 0
}

}

If no actions display, or actions display twice in the available actions list, this did not work and please let me know.

D.

Edited April 3, 2014 by Diazo

[Diazo]

Version 1.3 for KSP 23.5 compatability is out.

No changes of note.

D.

[harpwner]

Would it be possible to have an action group hierarchy.

Let me explain.

say you had a bunch of missiles on a jet. You wanted to fire all those missile with the same key, but NOT at the same time. Say missile 1 (on the very inside to the left) then missile 2 with the same key (on the inside to the right) and then 3 (a little out on the left wing) and so on. Would it be possible to add this feature, it's been something I have wanted to use in ships, something that recognizes the key has been pressed before or if the missile is gone or something.

Just a suggestion.

[Diazo]

Hrm.

That is certainly technically possible.

Essentially, you are asking for Staging (as with the spacebar) but with an action group key.

I can certainly see some value in having multiple staging queues, setup a multi-mission vessel with each mission having its own stage queue.

Having said that, it is not simple.

I'm currently cleaning up the code in order to add a couple other features (notably the highlighting of the part when you mouse over it on the current actions list).

I will add this to the long term plans, but as it currently can be done (although in a more cumbersome manner) with an action group for each, it will be a low priority.

D.

[Dirt_Merchant]

Just wanted to give this mod a bump to let you know how awesome it is! Thanks so much for getting this out to us, the flexibility of my planes has just increased tenfold!

[NoMrBond]

I must try this tonight if I get time