Jump to content

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


Diazo

Recommended Posts

@Crzyrndm: Interesting.

My only question is how is it affected by ModuleManager then?

My understanding is that Modulemanager runs during the loading screen and finishes running and unloads itself as one of the last things that happen on the loading screen before KSP changes to the main menu.

If I am loading my confignode into the database at the main menu, that is after ModuleManager has finished running.

Now, I think I am missing a step I think as looking at your code I can see you calling the GameDatabase to load the settings node from the GameDatabase, but I don't see where you load the data into the GameDatabase in the first place. Is it as simple as making a .cfg file that KSP reads in?

D.

Link to comment
Share on other sites

GameDatabase is where KSP dumps everything on start that it knows how to process (everything in GameData folder that isn't inside a PluginData folder and has a file extension that it recognises). Module Manager modifies the configNode data in GameDatabase, so when I load it out later on I see the config post-MM edits.

Edited by Crzyrndm
Link to comment
Share on other sites

Hi, I wonder if you can help. I am trying to use this mod with IVA props. Without the mod, I can assign the action of the prop to a custom action within the cfg file of the prop (Say custom01) but with the mod, if I try to use custom actions beyond the default first ten (Say custom26) it just disables the prop.

Any idea what I need to do?

Many thanks

Link to comment
Share on other sites

That looks like a whole lot of failed texture loads (the grey white texture is the default for an uninitialised texture IIRC), dds conversion issue sounds likely

EDIT

Checking the source, Diazo is loading the .png files directly, so yes that will fail horrificly if you dds'ify.

Link to comment
Share on other sites

@Everyone: Sorry for vanishing like that for a while, Real Life got busy for a while. I should be back now and can get back to working on this. The next release is about 60% done and will have the Momentary Action Groups and will add the ability for Sub-Assemblies to save their toggle status.

Moving the config from directly reading a .cfg file to using the GameDatabase to allow ModuleManage to be used is uncertain. It is something I would like to add but it is a lot of work and may need to wait for a version or two.

@Svm420: As mentioned, that white texture means the game failed to load the texture as expected. Do you have a link to the DDS converter you are using?

For AGX to load the textures correctly, the .png files in the .zip have to exist with that specific name. (Note that on Linux, capitilisation matters.) If you want to DDS those files, AGX should load them correctly as long as the file name does not change.

@RealTimeShepherd: Your problem with the IVA props stems from a limitation in the base KSP game in that the base action groups can not be touched. AGX gets around this by creating and managing the extra action groups itself on its own. The extra action groups in AGX do not exist in the base game and so when you issue the custom26 command, KSP can't find them and so throws the error you are seeing. You'll need to put something like the following on your prop:


using System.Reflection; //add this at the top of the code page where the using UnityEngine line is, AGX uses reflection to receive commands from other mods.

int actionGroup = 26; //we want to activate action group 26
if(IVA prop triggered) //Never worked with IVA's, whatever code is used to detect a mouse click goes here
{
if(AGXInstalled) //check if AGX is installed, this is a call to the method further down
{
AGXToggleGroup(actionGroup); //toggle action group 26, call to method further down
}
else //AGX not installed
{
Debug.Log("AGX not installed, can not activate group ' + actionGroup); //print error to log
}

The above code depends on the following methods, these methods would be called by any props setup this way, note these methods are static and so can be directly invoked without having to make a reference first:


public static bool AGXInstalled() //returns true if AGX is installed, false if not
{
foreach (AssemblyLoader.LoadedAssembly Asm in AssemblyLoader.loadedAssemblies)
{
if (Asm.dllName == "AGExt")
{
return true;
}
}
return false;
}

public static void AGXToggleGroup(int group) //Toggle action group "group". There is also a method to force activation or deactivating of an action group. This method will toggle the group in question on the currently active vessel.
{
Type calledType = Type.GetType("ActionGroupsExtended.AGExtExternal, AGExt");
calledType.InvokeMember("AGXToggleGroup", BindingFlags.InvokeMethod | BindingFlags.Public | BindingFlags.Static, null, null, new System.Object[] { group });
}

That should work for you, however note I'm doing this on my mobile and copy-pasting from my github, I can't actually test the code so there may be some typos and/or syntax errors present, but it should be 95% correct at least.

Let me know if you have questions on getting this working and I'll try to help,

D.

Link to comment
Share on other sites

Hi! Loving the mod even though I barely understand it. Really wishing I'd kept up my trig and calculus since leaving school.

I've been mostly using Baloan's scripts ( http://kos.wikia.com/wiki/Mission_toolkit_v3 ) and slowly reverse engineering them as I begin to understand more and more of how they actually work.

Currently I'm going absolutely mad trying to understand how his orientation during launch section works.

I've got a reproduction of his script that looks like this :

until alt:radar > 80000 {
WAIT 0.001.
if alt:radar > 1000 {
set gt0 to 1000.
set gt1 to 50000.
set pitch0 to 0.
set pitch1 to 90.
set arr to (alt:radar - gt0) / (gt1 - gt0).
set pda to (cos(arr * 180) + 1) / 2.
set pitch to pitch1 * ( pda - 1 ).
lock steering to up + R(0, pitch, -180).
print "pitch: " + pitch.}
}

What it does is to slowly alter the orientation of the rocket from vertical at 1000m, to horizontal at 50,000m. In order to try to understand how it's doing this, I've used software to plot graphs of the functions involved, and they come out with the pitch rapidly oscillating between 0 and 90 every couple of kilometers. I even got a maths graduate friend of mine to check my working, and he found the same. What am I missing about the way the program processes the maths that means this script actually works?

Really appreciate any help, this has been driving me completely insane.

Link to comment
Share on other sites

Hi! Loving the mod even though I barely understand it. Really wishing I'd kept up my trig and calculus since leaving school.

I've been mostly using Baloan's scripts ( http://kos.wikia.com/wiki/Mission_toolkit_v3 ) and slowly reverse engineering them as I begin to understand more and more of how they actually work.

Currently I'm going absolutely mad trying to understand how his orientation during launch section works.

I've got a reproduction of his script that looks like this :

until alt:radar > 80000 {
WAIT 0.001.
if alt:radar > 1000 {
set gt0 to 1000.
set gt1 to 50000.
set pitch0 to 0.
set pitch1 to 90.
set arr to (alt:radar - gt0) / (gt1 - gt0).
set pda to (cos(arr * 180) + 1) / 2.
set pitch to pitch1 * ( pda - 1 ).
lock steering to up + R(0, pitch, -180).
print "pitch: " + pitch.}
}

What it does is to slowly alter the orientation of the rocket from vertical at 1000m, to horizontal at 50,000m. In order to try to understand how it's doing this, I've used software to plot graphs of the functions involved, and they come out with the pitch rapidly oscillating between 0 and 90 every couple of kilometers. I even got a maths graduate friend of mine to check my working, and he found the same. What am I missing about the way the program processes the maths that means this script actually works?

Is the argument to cos() in radians or degrees? The above script makes sense if cos() takes degrees, but in most (other?) programming languages cos() and sin()'s argument is in radians, and the oscillation you describe is consistent with feeding degrees to a trig function expecting radians.

Link to comment
Share on other sites

Is the argument to cos() in radians or degrees? The above script makes sense if cos() takes degrees, but in most (other?) programming languages cos() and sin()'s argument is in radians, and the oscillation you describe is consistent with feeding degrees to a trig function expecting radians.

Aha! Yep. Turns out the graph program was using radians. Changing it to degrees gets me an output consistent with what's happening in KSP. Thanks so much! :D

Link to comment
Share on other sites

Are you sure this is a question about Action Groups Extended?

..... Posted in the wrong thread. Just typed 'kos' into history and clicked the first one that came up. I'm an idiot lol.

- - - Updated - - -

EDIT: While I'm here, I am actually using AGE as well and it is also excellent :)

Link to comment
Share on other sites

Heh, interesting conversation to see come up in my thread.

@Next release: This is close, I'm currently at the stage of having the features coded and going back and bug squashing so they actually work. Not going to guess at a release date beyond Soon as I've just started seriously testing.

@Svm420: It looks like that DDS converter does not run every time you load the game. I would recommend just copying the .png files AGX needs back from the .zip file. As they come in the .zip file, they are less then a kilobyte already so running the DDS on them does not gain you much. (As opposed to the multi-megabyte textures on the parts that the DDS is intended to compress.)

D.

Link to comment
Share on other sites

The problem is not when he loads it, but how he loads it. Module Manager applies patches to ConfigNodes in GameDatabase. Anything that loads through GameDatabase is almost guaranteed to be ModuleManager compatible. Diazo is not using GameDatabase to load his settings, he's reading the file from the hard drive when he needs it. This is why MM can have no effect on his settings file.

@Diazo

The best way I found to do this is to load the settings file into an object the first time you enter the main menu that persists while the game is running. Thus it is affected by MM and persistent between flights and saves. Any changes made you write to that object and to hard drive (or rather, update the object and then save it).

You can see this approach here where I have a class handling all my presets for Pilot Assistant.

GameDatabase.Instance.GetConfigNode(string url) would be the load function needed for AGX I believe

If this is about the global AGExt window placement, it's also affected by where AGExt stores its window locations, in the file AGExt.cfg which is included with every release of the full mod. That way installing a complete new version or otherwise copying in the original files will overwrite the window locations with their defaults in the shipped AGExt.cfg.

The way some other mods handle window locations and other configs like that is to having the defaults in the code and no window config file shipped, so when it's not there, the code sets the defaults and writes them out to a new file which won't be overwritten by future releases. As an example, MechJeb, which uses the files:


GameData/MechJeb2/Plugins/PluginData/MechJeb2/mechjeb_settings_global.cfg
GameData/MechJeb2/Plugins/PluginData/MechJeb2/mechjeb_settings_type_<rocket name>.cfg

Link to comment
Share on other sites

That's a different thing again. Those aren't affected by Module Manager either (anything in PluginData folder isn't loaded by KSP, and the format is totally different), but plugin configuration files do have defaults defined for when they don't find a requested value. They're reasonably useful for global settings files, but not really for anything you want specific to a save/vessel/etc. (cfg's make grouping a ton easier)

KSP.IO.PluginConfiguration config = KSP.IO.PluginConfiguration.CreateForType<*AClass*>(); // insert appropriate class nameconfig.load();
windowRect = config.GetValue("windowRect", new Rect(300, 300, 0, 0)); // access the value, create a new Rect(300, 300, 0, 0) if nothing found
config["windowRect"] = windowRect; // store the value
config.save; // write the config to disk

Link to comment
Share on other sites

I'm having a problem with this mod. Is it supposed to create a AGExt####.cfg file EVERY TIME the game saves? Can it be made to save only one file? Every time I save with the quick save feature or Kerbal saves the game this mod creates a file in the save game folder called AGExt####.cfg. The #### are numbers which start at 0001 and keep counting up every time it creates a new save. I end up with 60 files with just a few hours of game play.

Link to comment
Share on other sites

I'm having a problem with this mod. Is it supposed to create a AGExt####.cfg file EVERY TIME the game saves? Can it be made to save only one file? Every time I save with the quick save feature or Kerbal saves the game this mod creates a file in the save game folder called AGExt####.cfg. The #### are numbers which start at 0001 and keep counting up every time it creates a new save. I end up with 60 files with just a few hours of game play.

I had wondered about this myself. I had assumed it was something like different files for each craft, but I had no idea. If it is just copies it would be nice to get rid of that bloat.

Link to comment
Share on other sites

I have uninstalled this mod as it just plainly does not work. It has deleted my saved AGs repeatedly, it keeps saving tons of files that I don't want or need. As an added "bonus" I can't get any help on these problems.

Link to comment
Share on other sites

I have uninstalled this mod as it just plainly does not work. It has deleted my saved AGs repeatedly, it keeps saving tons of files that I don't want or need. As an added "bonus" I can't get any help on these problems.

I use this mod, and many other mods, and have exactly zero of the problems you do - and the mod plainly does ​work - so perhaps the problem is with your installation of the mod, your version of KSP, or some other thing and not the mod itself.

Link to comment
Share on other sites

Alright, just a status update to let people know that things are progressing.

The next release will have the "hold-key" option and change how the config file is saved so that you can both override it with a module manager patch and it will no longer reset all your settings each time you upgrade this mod on a go forward basis.

This next version will still reset your settings however as to make this work I've had to change the formatting slightly, but no release after that will reset your settings. (I will post a notepad-edit workaround if people want to save their settings in this next update.)

However, I've cut the toggle state saving to the sub-assembly from the next version. Real life is getting busy for me and I don't want to keep pushing the release back.

On that note, all the primary tests passed tonight so things are looking good. I just need to grab the latest development version of RemoteTech to make sure that still works with this mod and then I'll push the next release, hopefully tomorrow evening as I don't think anything I've done affects the Remotetech stuff so I'm hopeful the tests tomorrow will be quick.

On the numerous AGExt#####.cfg files that are being created, welcome to the limitations of the options we are given in the game code. If you want the ability to go back to an older save file I do indeed have to create a new AGExt#####.cfg file every time the game saves. As the game auto-saves quite often this does lead to many of these files being created.

Which is why there is a clean up routine that runs to delete these files when you start the game. You should note that after you boot the game a second time, all the older AGExt#####.cfg files are deleted and only a few recent ones are kept for your current save games. (Specifically, when you move from the Main Menu to the SpaceCenter the first time after loading the game.)

If you are having issues with the mod, I will certainly try to help out. To do so however, I need the output_log.txt from your KSP\KSP_Managed directory in order to see what error messages are being recorded.

D.

Link to comment
Share on other sites

Version 1.31fh

Version 1.31h download here.

-Add option for "hold-to-activate" groups (as the default Brakes group).

-Change how options save so future updates will no longer reset your settings. (This update will still reset your settings however.)

-(1.31a) Tweaks to support upcoming kOS 1.17 release.

-(1.31b) SubAssemblies save their hold and toggle group state

-(1.31c) GUI display fixes.

-(1.31d) Further kOS tweaks.

-(1.31e) Fix some typos.

-(1.31f) Fix duplication of actions.

-(1.31g/h)Fix a memory leak.

RemoteTech users:

Remotech version 1.7 is required for integration with AGX. As this version of RemoteTech has not yet been officially released, I talked to the RemoteTech devs and have permission to release a development version of RemoteTech 1.7 until the official release.

To do so, first download the official RemoteTech version 1.6.3 and install it. Then download the RemoteTech.dll file here and overwrite the RemoteTech.dll file in GameData\RemoteTech\Plugin\RemoteTech.dll

Note that the latest development build available from RemoteTech's download page should also work, I just have not actually tested it like I have the .dll linked just above here.

Hold-to-activate

There is a new button next to the toggle button (underneath the description field) that switches between "tTap" and "Hold"

Tap: The default setting, this is the existing behavior. Tap (press and release) a keyboard key to activate an action group, tap it a second time for a second activation.

Hold: The new option, this activates the action group when the keyboard key is held down and deactivates the group when the keyboard key is release. This is the behavior of the Brakes group in default KSP.

Note that this option affects keyboard keys only, a mouse click (press and release) will always activate an action group regardless of this setting. (To be consistent with the default Brakes group behavior.)

Options file change

This will be a transparent change to most users and is an adaptation to the CKAN network that automatically installs all files in the .zip file when you updated. As this installed the options file fresh every time, all your settings would return to default when you updated. This will no longer happen in future updates.

However, as I did have to change the formatting of the file to support this, this update will be the last update that resets your options to default.

If you wish to keep your current settings, after updating but before starting KSP, find the GameData\Diazo\AGExt\AGExt.cfg file and add the follow lines:

Two lines at the top of the file:


AGExtConfig
{

and at the end of the file:

}

This also allows for other mods to change settings with a modulemanager patch file, if you want to do this please get in touch with me directly so we can coordinate.

I will also be around if there are any issues. If you do have an issue, please be sure to upload the KSP\KSP_Data\OutputLog.txt file, AGX logs any errors it encounter in that file and is required for me to effectively troubleshoot any bugs.

Happy KSPing all.

D.

Edited by Diazo
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...