So how does the *input.ini hook together with *intput.uc

[TheSpaceMan]

From what I have read, the ini file contains the keybinds, these keybinds can target and modify a target var in a input.uc For instanse set a value to aAxisX.

Anyone know where the two get hooked up? Is it a config setting that decides the used input.ini and does that input then get used on all input instances and just ignore a input.ini bind that doesn't have a corresponding var.

The reason I am asking is because if i make mutliple mod with diffrent controllsettings to make sure each layout is simply just the controlls for that game...

[Taxxem]

If you look at defaultinput.ini you will see that defaultinput reads from baseinput or something like that and that then removes certain elements and adds elements to make UTinput.ini. Playerinput from what I can see doesn't make the config file even though it seems to be referenced in the utinput and the defaultinput file as [Engine.Playerinput].

Basically if you have seperate games going on with different input settings you will need to make seperate input.ini's.

[TheSpaceMan]

Yeah i did see how the input ini files hooked together. But it doesn't seem clear what ini file you have access to at what point. Also, extending some objects, will make them automaticaly write to ini files. Probably part of some default implementation to save configurations. The config(Input) config(Game) config(Editor) somehows tie into this, but i am not sure how, since for instance something that are not part of a input*ini file still can be accessed. Maybe the config(Engine) will give you access to everything [Engine.*] But I am just guessing. The only thing that is certain is that it only seem to hook up with the obvious var ...config...

[immortius]

When a class has a config specifier, all of its config vars are saved to an ini file (and all inherited non-globalconfig vars). The bit in brackets determines which ini file ( config(Input) -> UTInput.ini, for instance). The settings are saved under a [<package>.<class>] section header.

When you start the game or editor, if the ini file is not found, it is created by inspecting the respective Default*.ini (so for UTInput.ini, DefaultInput.ini).

If you wanted multiple bindings, you'ld need multiple classes subclassing PlayerInput, or a PerObjectConfig class (which allows you to have multiple config blocks for the one class, each qualified by a name). Not sure if you can add that to a PlayerInput subclass, worth experimenting with.

This is all specified in the UnrealScript reference documentation.

[TheSpaceMan]

Thanks. Totaly forgot about the reference documentation. Doh.
Now time for some tinkering.