![[de]](/mwf/flags/de.png "Germany")
I have some questions for my project, regarding the player controls. As I read in the documentation, all the player controls can be overriden, for example in a scenario folder, by changing the PlayerControls.txt and placing it in my System.ocg subfolder in that scenario folder.
How does the frontend handle my changed controls then? As far as I understand, if I were to define entirely new commands, then the player could not map his buttons to these new commands, but has to use my presets. Also, what happens if I define more than the keyboard and gamepad presets?
Secondly, how can I limit the magnification factor with SetPlayerZoomByViewRange() correctly? I do not want the player to see only 1000 pixels in certain directions, I want the factor to be between 1 times and 4 times magnification for example. So how much pixels does the player see in 1 times magnification, is that limited by the screen resolution, by the landscape dimensions, or by something else entirely?
How does the frontend handle my changed controls then? As far as I understand, if I were to define entirely new commands, then the player could not map his buttons to these new commands, but has to use my presets. Also, what happens if I define more than the keyboard and gamepad presets?
Secondly, how can I limit the magnification factor with SetPlayerZoomByViewRange() correctly? I do not want the player to see only 1000 pixels in certain directions, I want the factor to be between 1 times and 4 times magnification for example. So how much pixels does the player see in 1 times magnification, is that limited by the screen resolution, by the landscape dimensions, or by something else entirely?
> How does the frontend handle my changed controls then? As far as I understand, if I were to define entirely new commands, then the player could not map his buttons to these new commands, but has to use my presets. Also, what happens if I define more than the keyboard and gamepad presets?
The startup options screen cannot handle custom player controls yet. It is planned to add a reduced options screen in-game, which will allow you to reconfigure keys at runtime.
The engine functionality to override per-scenario keys is already present, but there is no user interface for this yet. You would have to define the overrides in a config file or the registry under Windows.
> Secondly, how can I limit the magnification factor with SetPlayerZoomByViewRange() correctly? I do not want the player to see only 1000 pixels in certain directions, I want the factor to be between 1 times and 4 times magnification for example.
A function like that does not exist. I don't really see the point of having it. We've deliberate changed OpenClonk so changing the resolution does not affect gameplay any more. In Clonk Rage, people would put the resolution all the way up (and cause lag in internet games) so they could see further in melee games. This was a silly advantage, so we got rid of it.
If you have a legitimate use case for such a function, you can go ahead and file a feature request in the bugtracker. It would be trivial to implement in the engine.
>If you have a legitimate use case for such a function, you can go ahead and file a feature request in the bugtracker. It would be trivial to implement in the engine.
The question is: which is more appropriate? I implemented it in c4 script in the System.ocg of my scenario now, but I can't say whether it will work the same on all systems/resolutions.
By the way: I have a retro scenario lying around which defines the old-style Clonk Rage control for OpenClonk - complete with Down-Down-Left-Throw for sideways material drop. If you want, I can upload it tonight so you can have a look.
That would be great. In the end I don't want to port the old controls exactly as they were, because they had some serious disadvantages...
http://cognium.de/misc/S2Classics.ocs.zipThis is Minor Melee with mostly Clonk Rage controls and objects. It's using three control sets (i.e., QWEASDZXC, IOPK:<>? and the NumPad controls) all just mapped to the same controls, so you should be able to start and play on either set.
Thanks a lot! The script helps a lot in understanding how the new control schemes work. I am expanding it to incorporate some of the new keys now :)
Double-posting now: Another issue has turned up. Is there any way for detecting an active player menu? In the standard OC controls one can safely open the player menu, navigate it and no commands are issued to the clonk. With my modified S2Classic controls I can also navigate the player menu, but all button presses are forwared to the clonk.
So, can I detect the player menu? This is also valid with other objects, because a menu that is created by a rule object for example should also block movement, but it is quite some effort to implement a solution (object saves which player opened an object menu, check all objects if the player has a menu open, if so block movement).
Also, could it be an issue of my PlayerControls.txt? I have CON_Left assigned to A with priority 100, CON_MenuLeft assigned to CON_Left with priority 150 and CON_ObjectMenuLeft assigned to CON_Left with priority 200. Pressing CON_Left while a player menu is open makes the clonk move.
So, can I detect the player menu? This is also valid with other objects, because a menu that is created by a rule object for example should also block movement, but it is quite some effort to implement a solution (object saves which player opened an object menu, check all objects if the player has a menu open, if so block movement).
Also, could it be an issue of my PlayerControls.txt? I have CON_Left assigned to A with priority 100, CON_MenuLeft assigned to CON_Left with priority 150 and CON_ObjectMenuLeft assigned to CON_Left with priority 200. Pressing CON_Left while a player menu is open makes the clonk move.
I think the Clonk will not move when a menu is open as long as you do SetMenu(pMenuObject) on the Clonk. That's obviously no solution for the player menu.Maybe the menu controls are just missing from the S2Classic controls or something?
I wrote my own PlayerControls.txt with S2Classic controls as a base. I did not know about SetMenu(), it is not in the documentation :(
Are you using scripted controls for CON_ObjectMenuLeft or the internal controls? If it's scripted, be sure to return true if the control has been handled.If it's the internal controls, I haven't tested if overloading works properly there. If it doesn't, it might be an engine bug for which you could file a bug report and do a scripted solution (if (cursor->GetMenu()) return true;) until it's fixed.
I use:
[ControlDef]
Identifier=PlayerMenuLeft
GUIName=...
GUIDesc=...
Action=MenuLeft
[ControlDef]
Identifier=PlayerMenuLeft
GUIName=...
GUIDesc=...
Action=MenuLeft
![[cn]](/mwf/flags/cn.png "China")
Regarding your project: What about the removal of trainable physics in OC?
I think trainable physics were nice in Clonk 4 and Clonk Planet, but the removal was a good step.
Well, you can always reimplement it in script when users might want it.
P.S. Maybe you can specify with which engine version your pack is playable.
P.S.S. And maybe you can give your Folder.txt a different index to not move it in front of the original packs, or move it in front of the Tutorials as well if you want to really make it stick out ;)
P.S. Maybe you can specify with which engine version your pack is playable.
P.S.S. And maybe you can give your Folder.txt a different index to not move it in front of the original packs, or move it in front of the Tutorials as well if you want to really make it stick out ;)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
