I’ve done a lot of testing with different sets of planes and liveries via add on manager and didn’t encounter that, but then I wasn’t changing the data, just changing what was in the community folder.
Also had many cases of not loading planes between sessions, but when I do load them tags are retrieved correctly, because the keys haven’t been modified.
It sounds to me like somehow the planes reference name has been changed in the data, or reset, I’m not sure. You could try putting it all back to the same state everything was when you saved the tag and see what happens. There is no active tag deletion code, so the only way it can lose the tag is if the reference plane name has changed. If the other planes are retrieving their tags ok, then you can see it’s working, especially if the only one missing is one you’ve been playing with.
As to what changed the planes name, unsure.
I have to draw a line somewhere though, and manual changes by users to the underlying data is it.
That’s an endless can of worms with too many use cases to cater for, and simple code is the best code.
I have been considering adding a reset all button to nuke all tags/notes to start again, maybe at some point. But if an individual aircraft metadata for keys has changed (by dev or user), easier just to recreate the tag for now.
This is the case already. I added the tag, but name was already changed before that so I have not changed the name in the eyes of AM.
Then I removed the livery for 1 boot up. When I put the livery back in (no changes, just activated again with Linker) it no longer has the tag. As of loading and viewing the “list” without the livery there has wiped its tag out? Maybe I’m wrong but seems to be what occurred.
No, I understand, but the only way AM rewrites tags is via manual edit of the tag to fire off that process.
If the rest of the planes tags are there, then code is fine as far as I can see.
The only possibilities I see atm are:
Plane name has changed somehow which means unable to retrieve previous plane name key
Tag was accidently deleted manually
?
I’ve done livery testing as well, with no issues like this, but then I also didn’t edit them.
or if I rename the folder and the references in the JSON and CFG files to make it appear first if I WANT it to be the default)
I’m not referencing livery data, though I did do some extensive work looking into the livery system as well, but I’m not implementing anything there for a number of reasons.
But I’ll run some more tests again just to be sure.
When you removed it, were there any liveries in there? I guess it comes with some embedded, or did you remove them?
Seeing as I’m up working on a new addon (sssssh) I ran a quick test using the Milviz Corsair.
It has a bunch of embedded liveries, and I have 3 add on liveries.
It was installed with the addon liveries, and has tag.
I tried various combinations removing the addon liveries (one set as default) via addonslinker, restarting, check tags, exit, reenable addon liveries, restart , check tags, select addon livery again++ etc, and tags are there every time.
btw if you have a livery set as default and the plane is active, if you remove that livery the plane automatically gets unselected as the active plane on next start up, which is sim behavior.
In any event, I’m seeing the expected behavior when doing various combos of adding/removing liveries, without doing any manual editing of livery or aircraft files. I don’t cover those use cases.
In each case the plane tags are always there. So it appears to be working to me as expected.
If you can replicate it with another plane and 3rd party livery let me know.
Just because “it works on my machine” doesn’t mean there might not be an issue, but at least the way I anticipate it working (and how users might add/remove liveries) it seems to be aok.
Yeah that is how I first noticed. But moreso that if you tagged it WITH that livery active, then after adding it back it was not tagged. When I went back to find it after re-enabling the livery, it wasn’t tagged with my “Y”.
But yeah I take your points and appreciate the time you took to test it your side. I will try and test it with another plane and see what happens. Probably not today though!
Apologies for the delay, though I’m not sure if anyone is actually waiting on the edge of their seats for this
I’ve been held up on release waiting for a few blockers to be cleared.
One of them was website “stuff”, which has finally been cleared so I can move ahead on that for launch.
Size of notes storage in AM.
I was waiting on some more information about how the DataStorage worked on XBox/PC and one of the Asobo devs kindly replied with a little bit more info (see below). So I’m going to cut the notes down to 200 characters (down from 1000 characters) for now, maybe increase later. It’s only room for a para or two, but longer than the tags and you should still be able to save some working notes or whatever.
@sonicviz,
The JS Datastore writes to the savegame which is cloud synced. I don’t believe there are restrictions to it on Xbox.
One piece of advice: Writing too much data into one key:value pair can corrupt the savegame. I don’t know the exact limit but I would try to stay under 200 characters per value to be safe
Working on another app to scratch another itch with the UI UX, I discovered a couple of things I need to consider deploying multiple apps into this space. So I’m doing a bit of redesign and rework to tighten that up so they don’t conflict, and also stay under the currently advised safety limits with the storage. A little bit more testing time in the oven is needed.
Free version of Location Manager is out.
If you’ve got Aircraft Manager installed, it would be great if you could give Location Manager a tryout too, and any feedback if you see any issues or conflicts between the two. It’s been tested, but bugs are sneaky like that. I’m sure you’ll find it useful though as well
New free version release, no version number change.
Performance improvements + fixes
Mandatory install for data migration prior to pro version release, if you want to keep your current tags.
Anticipate Pro version release in the next day or so.
Highly suggest testing with this version first though, especially if you intend to upgrade and edit your current tags.
But if that is truely the case, and you really want more than the 200 chars, one could have multiple keys to hold >200 character data,
ie instead of a key NOTES, you could have NOTES.1 NOTES.2 etc
and assemble the Notes data from Multiple keys.
PITA, but possible
More to the point though, is the question why their is a perceived 200 char limitation, and why that cannot be increased to a much greater size. (say a nice round number like 128K ) - so that it can hold , for example, complete Flight Plans …
I ran some tests with keys and values exceeding 256 characters and didn’t notice any problem so I’d say there’s no known limitation.
Let us know if you encounter any issue.
Start small, see what people do with it, get feedback, increase as needed in measured steps.
In this first instance the intent is for short notes anyway, so will see how it goes and what people think they might want to do with it.
Too much potential for disruption otherwise, and the main UI is a key UX, so needs to be reliable.
There are also performance implications with loading/unloading huge blobs of text in the UI, and I’d like to strike a good balance between utility, value, and performance. There’s always trade offs with this kind of thing.
I personally stress tested ~250 planes @ 1000 characters, but just because “it works on my machine” doesn’t mean it will in the wild.
Ditto for the current 200 location limit in Location Manager Pro. It likely does much more, but I’ll run with that for a while and see what the results are like from the real world.
Didn’t realise the pro version also includes a control preset manager. My question is if you change aircraft in the manager, does that also automatically switch the control profile defined for that aircraft or do you have to manually switch this in the control preset manager?
Once you define what preset to load for each device for each plane, then whenever you change planes (be it via the new list view, the preset assigning view page or the built-in large grid of thumbnails page), all banks of presets automatically change for you from then on.
Small note: Depending on how many need to change from the previous presets that were being used before you changed, you need to wait a little while to give the system “time” to set them all for you — but it’s like 5 seconds wait and you’ll be safe.
It’s really really good and I could not imagine dealing with the sim without it now as it’s allowed me to make a few more custom presets per plane that I couldn’t be bothered to do before
EDIT: I just read that second paragraph back to myself and it’s not very clear what I meant lol
Basically it’s changing one-by-one for you, so the more that need to change, the longer it takes as it’s actually navigating the clunky slow to respond menu behind the scenes on your behalf
Also, I am not 100% sure if the Asobo default big grid view also changes profiles to be fair as I just don’t even use that any more but I think it does. I’m sure @Sonicviz will jump in to clarify
Thanks @Baracus250 , that’s more or less what’s going on behind the scenes. Tricky bit of code tbh, I’m sure Asobo are looking at how they can optimise when if/when they rewrite the UI.
Yes, if you switch planes anywhere it will trigger a control preset switch.
Also, please check the Known Issues on Aircraft Manager for MSFS - Sonicviz for pertinant info about this. eg: Duplicate devices are not supported due to an MSFS bug with them, but some users have found workarounds. I just found out the Velocity One actually shows up as two duplicate controllers under Windows (one under XBOX!) so it looks like they have two chips in it do its magic. Appears to work fine though, it’s a bit of a unique case. I’ll be adding that to Known Issues asap.
