Config.cs always overwritten?

#1 Config.cs and prefs.cs will be resaved every time on exit.

#2 But when are they overwritten?

What I'm seeing (I guess I should have said this before) is that any control key changes I make through the gui are lost when I restart the game.

#3 This is intended to save any control changes.

Let run over it:

default.bind.cs is loaded provided default key mappings
config.cs is loaded overriding these defaults
player change in game config
config.cs is saved so that changes are saved (these will be reloaded next time)


After you quit does the new config.cs reflect your changes?

Are you sure you are still exec()ing config.cs from script?


Config.cs is ALWAYS overwitten. Make your changes in default.bind.cs where it is intended.

#4

Quote:
Config.cs is ALWAYS overwitten.

Not for me, I need to delete it (subsequently a new one is generated) after making manual changes to default.bind.cs. Only then will the new changes appear in config.cs.

AFAIK config.cs is actually used to load key bindings, they are just passed on from default.bind.cs

#5 If you search through the standard scripts you can find the lines which are responsible for writing these files out. Commenting out will disable such, however you will lose persistence of any input remapping you might do through the standard options dialog or the likes.

Gabriel

#6 @Tim: You can make it append but this doesn't make sense. The Config.cs is always overwritten by the current settings when you exit the program. Which is when the file is saved (in script 'server/scripts/main.cs:onExit() by default for starter.fps). If you make changes to default.bind.cs you should delete your config.cs files. This is by design. The last settings will override your default settings (which have been changed).

I am working on a default binding versioning system. My plan is to allow the developer to increase the version number in the default.bind.cs whenever it changes and all clients would automatically be reset. There are better ways of doing this I suppose but this works for my case (syncing developer (me) to artist).

@Lee: If you have created your own custom move maps (named other name 'moveMap') you will need to add a line in the above mentioned onExit() function to save your action map as well.

#7 Hmmm. Well, what is the Torque way, then, of allowing the user to change keymappings?

It's all fine and good to change them in default.bind, but it's not very user friendly. It's the players I'm thinking about here. All they know is they go into a screen called "options" and change their movement keys, for example. It works fine during that session, and indeed config.cs gets written with their values. But when you restart the game config.cs is overwritten with the defaults, and they lose their custom key mappings.

It seems to me that config.cs should only be overwritten if there has been a change to default.bind.

So I guess I'm trying to understand the way the Torque developers intended it--because surely this is not it? I just don't want to go off into lala land customizing that stuff if there is a working system already in place.

#8 The order should always be:

load default.binds.cs
load config.cs

This does, as you expect (in stock) load up a moveMap on the defaults, and then, if config.cs exists (which it will on every run after the very first) loads the keymaps there. Config.cs actually deletes the moveMap that default.binds.cs loads by the way, and this is intended.

It sounds as if you may have changed the order in which config.cs gets loaded (it should be after defaults.bind.cs, not before).

#9 Ok, thanks, y'all.

After reading Stephen's post I checked my raw TGE install (which I keep around for just such occasions), and sure enough it worked just fine, saving the keybinding changes I entered via the gui between sessions. So I knew it had to be some clever move on my part.

Turns out that during my most recent port from TGEA back to TGE, I kept the example/main.cs from TGEA, which does not save out the movemap changes to config.cs in the onexit() function. I guess they figured when they made TGEA that people would be so wow'ed by the cool shader technology that they would completely forget they had remapped their control keys last session and not mind doing it again :-P

The movemap stuff is such a mystery to me, it's one of the areas of Torque that has so far resisted my complete comprehension, so I assumed it was something bizarre instead of my usual first assumption, which turned out to be the correct one in this case--that I had screwed something up :-)

Thanks for the input though, I actually did learn a few things!

lee