Update Object.Offset when reloading Menu?

Short Version:
I am telling a few Objects, via Lua, to change their Offset when starting the Scene. Some change it, some stay in their Default Position -- seems very random. How can I make sure all of them change?

Long Version:
I am creating a Settings-Menu for my Game and there are some Elements which, on reloading the Menu, should get their Object.Offset.x updated, like Sliders -- if the Music, for Example, is set to 50, but I open the Menu and the Slider's Graphic is at 100 although the eMusicVolume really is at 50, that is obviously unacceptable. So I wrote a little Script to be executed at the Beginning of the Scene, in Order to put the Sliders into the correct Place. Strangely, this works flawlessly when I start the Game, and start it in that Menu-Scene, but when I then leave the Menu and open it again, or just click a Button that had to reload the Menu-Scene (i.e. switching the Language), the Sliders all fall back into their Default-Offset -- almost, that is. Because very strangely, after Reloading the Menu some Sliders (randomly some of those I manually changed before the Reload) stay where they should be, but others fall back (randomly some of those manually changed before, and all of those which were not manually changed before).
(I use ":to", but I also tried ":setValue", but with the same Result.)

So, how can it be that some Objects get their Offset updated and others don't? And obviously: How can I fix this and instead get all of the Sliders to get their Offsets updated?

Here is my Code:

Hmm, you used actual scene objects for your sliders? I would actually recommend using looped single frame animations instead. You could actually add the query inside of the animation frames if you wanted & have it calculate the position on each loop.

Yes, actual Scene Objects. And they slide smoothly if dragged with held Leftclick, not in Steps -- and I suppose if I used Animation Frames, I could only do Steps? Also, I would still have to make sure that the Animation would be updated to match the corresponding Value, so would it be any better?
(Though if it were easier that Way, I might indeed have to redo my Sliders.)

All I need is Visionaire to update the Object Offset. It works the first Time I open the Menu, but not if I refresh the Scene or leave and return. What could be making this happen?

With animations it would function the same way. You could still left click & drag it. Have you not seen the slider scripts floating about on the forum / wiki?

Instead of offset we specify the start pixel & end pixel of let's call it a slider rail. We then convert the percentage of a volumes value into x percentage of the total distance which then updates the position of the slider handle on the rail. So left clicking & dragging while a loop's running will update it in real time. I agree though that using objects with offset might be better when it comes to fine tuning, but animations are just easier to position as you can specify absolute x,y coordinates.

By the way, you shouldn't need to use the to() tweening function for updating the scene objects as you are updating them with 0 delay / transition timing.

P.S: back when the slider scripts were written we didn't have the object offset feature.

First off: Sorry if I am clinging a little too much to the Slider-Mechanics I have already made for myself, as the Thought of possibly having to abandon my own otherwise well-functioning Creation just kind of hurts.

“

we specify the start pixel & end pixel of let's call it a slider rail. We then convert the percentage of a volumes value into x percentage of the total distance which then updates the position of the slider handle on the rail. So left clicking & dragging while a loop's running will update it in real time.

„

Pretty much what I did.

“

By the way, you shouldn't need to use the to() tweening function for updating the scene objects as you are updating them with 0 delay / transition timing.

„

Yeah, I figured, but it was kind of a Leftover from experimenting with Tweening for my regular Slider-Code (not the one shown here), and since it still worked, I was a little too lazy to change it, I admit.

“

Have you not seen the slider scripts floating about on the forum / wiki?

„

(rambly Bit incoming, I guess I am beating around the Bush because I am ashamed or so)
I have seen that there are some, mainly the one you adapted from Einzelkämpfer's, but there is a Lot of Code and I hoped I could get it done on my own so I would have a better Grasp of the Mechanics. And I admit that in my shameful Hubris I did not actually try to implement your Script but, after having a quick Look, decided to make my own Sliders. (And my Sliders work totally fine, so that was a Breeze. It is just saving/updating/refreshing the Offset that is a Problem.)

I can, and maybe I should, try to use your Slider-Script instead, but that would still leave me with similar Problems I did not adress in this Thread -- namely that there are Buttons too, where you can click on the Language for Example, and click "German" or "English", both already visible in the Menu and only highlighted by a Frame Image around them -- and with that Frame Object, I also had the Problem that its Position would not be updated properly. So if I do something else for the Sliders, I still would have the same Problem with my Buttons/Highlighting-Rectangles. But I can still try to change those too, like making two such Frame-Objects dependent on some Condition... well, I wouldn't like that Solution as it makes the whole Thing just a Tad more complex, but I guess I should give it a Try.

But maybe if I inspect your Slider-Script well enough I can find its Slider-Position-Saving-Ability and implement it into my Code.

gow do you save and load the value for the slider?
could it be that there is something missing when loading the values from the config.ini?

Shouldn't really have to load the values from the config.ini file. Actually you don't even have to write them. For some reason VS automatically reads & writes the volume values, which is strange as everything else has to be done manually.

Anyway... all you should need to do is check the current volume values with the getVolume() function & then do the calculations & update accordingly.

I forgot to ask... is nothing mentioned in the messages log file after opening up the options menu & it doesn't update the sliders offset accordingly.

P.S: I think that objects might actually be the better way to go as the object interaction polygons move when you offset the object. The animation version requires you to create one long interaction polygon that is the same height as the handle & the same width as the rail.

I'm curious to see how you setup your sliders. Would you be willing to share some screenshots or a video or something?

P.P.S: both Einzelkaempfers original script & my rewrite of his script are years old & VS has come a long way since then, so there are probably much better methods that could be used now. Actually I did create another slider method last year but for some reason I never actually shared the script or tutorial on the wiki. Don't remember the reason why, or if there even was a reason or not!

I have not yet come to letting the Game read anything in particular from the .ini File -- except for the Default Stuff the Build just has anyway.
And while saving the Values, also for the Volumes maybe, is currently not necessary for the Menu at this Point, I wonder whether saving it into a Visionaire-Value and reading it from there would somehow help in the Process, as a Workaround... I would doubt it, but I do not know.

The Log says nothing about it. Not after using the Sliders, not after reloading the Menu-Scene.

Actually, I also use a rectangular Polygon defining the Slider-Rail Area, like you described, while clicking on the Slider itself has no Effect. After some trying around with a clickable Slider, I figured it would be better/more efficient without that.

https://youtu.be/DM_4T_9ujlo

Here is a Video (with rather provisoric WIP Slider-Graphics), and here a little Description of what is going on.
Everything before 0:31 is the Setup in Visionaire, after that I start the Game.
Then I open the Settings-Menu (via F2, which you cannot see in the Video), and randomly play around with the Sliders (Brightness-Setting works fine, but the Videocapture-Tool did not pick up the Change), where you can also see that my Sliders, although moving smoothly when dragged, snap into Position when nearby a particular Point I defined -- Brightness-Slider snaps at 0, 100 and 200, all Volume Sliders snap at 0 and 100.
As you can see, when I opened the Menu, the Volume Sliders were already in Place according to the Volume-Settings I had predefined in another Startup-Script. But then I change them and click the Language Selection, which also reloads the Scene (and the Effect is the very same if I leave the Menu and return), and you can see some of the Sliders go back to 100%, although the corresponding Volumes stay as they are (and should be). Also, if I then reload a second Time without having changed any Slider, I can be sure that all Sliders will be in their Default-Position. So, only those which have been changed before the Reload have some Chance to stay, all others will not be updated. But other than that, I fail to see a clear Pattern.

Hmm... So you have added an execute a script action into the at begin of scene action inside of the scene tab, that should update the values on scene load?

Simply checking those at begin of scene should be enough to update the slider positions to the correct position.

I would recommend adding your scripts into the script section of the tab & maybe using a function so you don't have to keep declaring multiple local variables. It could be the local variables that are causing the issue as they are only being registed in that execute a action part when you create them. It might be a better idea to make them global by not assigning "local" before them...

sfxvol = nil

instead of...

local sfxvol = nil

Like I said, the getVolume() function should always return whatever is in the config.ini anyway, so sure you could use values if you like, but it shouldn't matter.