![[es]](/mwf/flags/es.png "Spain")
Big HUD and control changes are in sight. We worked out a new interface for useable objects already so work on that can begin without the actual new controls and hud in place.The old Activate callback will vanish. Instead, there will be - consistent with all the other Control* callbacks - the following:
ControlUse(object clonk, int x, int y)The clonk uses the object. In the standard control, this is a click with the mouse. x and y are local coordinates of the cursor. It gets called when the player presses the mouse button down.
ControlUseStop(object clonk, int x, int y)Same as above but gets called when the player releases the mouse button.
We are not sure about how a callback that is continuously called while the mouse button is hold. For now, it is:
ControlUseHolding(object clonk, int x, int y)But it may be subject to change.
For objects which are controlled from the inside (submarine etc.), the callbacks are called Contained*, again consistent with the other callbacks.
![[de]](/mwf/flags/de.png "Germany")
>In the standard control, this is a click with the mouse. x and y are local coordinates.
yes
![[ca]](/mwf/flags/ca.png "Canada")
so what about the retancle selection area? is it disabled when there is a "ControlUse" in the clonk-object?
The mouse selection of objects (like Clonks) will probably be removed. This is just my thoughts of course, but to be logical it could create unnecessary complication and confusion. Only being able to select objects when you aren't holding a mouse-controlled tool seems ridiculous.
Will there be any option for a secondary Use command (ie Mouse2)? It could be useful for complex items (ie reloading a gun before the magazine is completely empty).
I wanted to have such a button as well, but it was not liked by the majority. But I think we should see whether we will need it when it comes to that point (since it is not very hard to implement)
Imo, any object should have an infinite amount of possible usage commands. It's just that one "use" option is kind of primary and has a generic shortcut.
If we have multiple use commands, confusing menus won't be necessary. :)
To me, having Use1 thru Use50 assigned to arbitrary commands sounds much more complicated than some kind of menu. If we restrict ourselves to limited actions per object, we will end up with the same awkward controls as in CR (Double-Special2 for one action; Single-Special2 for another...).That's not to say there shouldn't be something like Use1 and Use2, assigned to the same key or mouse command. It's just that we also need an interface for as many commands as are needed for a specific object.
Indeed, it would be rare for a hand-held object to require more than two commands. Another idea I had for 2 use functions was for the barrel; Use1: Empty Barrel, Use2: Open/Close Barrel Lid. This way you could safely throw barrels around (ie into lorries) without the barrel emptying immediately. I've got most of this already implemented, just no command to set the barrel to "closed".
You could put the open/close function on the same button as a toggle. In fact, I don't believe it's very useful to have it as two different buttons.
It'll always be possible to fill the available number of possible Use-commands. If we have two, there will always be a third possibility. If we have three... and so on.I am strongly for just one Use command to keep the (usage of the) objects in the game easy. I'd rather have 9 weapons with each just one shooting-mode than 3 with three shooting modes each. I'd rather have a sword (stab), a hammer (stomp) and a shield (block) than to have a sword (and most other weapons) that has each up to 3 different functions.
Why? KISS - one object, one function.
The practical reason for just one Use command is the limited space on the mouse. I plan to use the controls like this:
LMB - use selected object (e.g. bow)
RMB - use other selected object (e.g. shovel)
or e.g. sword and shield. Then, you'd stab with the left mouse button and block with the right one. I fear if we use up both mouse buttons for use controls to one object, the gameplay will be more tenacious than in CR because even in CR you could use the shovel and e.g. a bow without switching the inventory around.
I think this is a good idea, indeed. I had actually completely forgot about tool usage. :SAlso, in the event that an object would definitely require more than one usable function (ie magic wand/book/playable-guitar xD) there is always scripted menus.
Note the ";-)". It's not trivial to script a reliable, fast and easy-to-use gesture recognition system (if it should do more than distinguish a horizontal line from a vertical line or something).
Would there be a need for more complicated mouse gestures? In the current system you have, simple mouse gestures are already possible. For something like the sword, there could be basic mouse gestures for chopping (vertical) or stabs (horizontal).
>some kind of menu
A menu with shortkeys. Joint of both principles. (Uhm, I'm sure s.o. suggested that already somewhere.)
Possibly:If an object has greater-than two Use commands, left clicking could operate the first Use command, and right click could bring up a menu of all possible Use commands for the object (selectable with short-keys).
What do you think?
|There obviously needs to be some kind of menu. But I don't see why you would need to press an extra button to open it.
Your mouse has two buttons. Put the context menu on the left and ignore the right one. I prefer having one most important action and other less important ones, but yep, that's a question of style, noone can answer for everyone.
I was also thinking of a helpful function; something like:ControlUseIdle(object clonk, int x, int y)...in which it continually returns the position of the mouse-cursor when the object is selected in a Clonk's inventory. That way bows/guns could track the mouse smoothly, instead of snapping to the proper angle when the mouse button is pushed.
We need to synchronize cursor coordinates across the network in that case; depending on latency, you could see noticeable lag.
Hmm. I had thought that could be a problem. Would it be possible to lower the cursor-position synchronization frequency? (for instance, only synchronize the cursor across a network every 1.5 seconds)
Actually, in the current PlrCtrl build, the mouse cursor position is transferred every control frame (though I had planned to change that once we know when the cursor position is actually needed).
>you could see noticeable lag.
The only way to circumvent that is to have synchronous and asynchronous scripts. The asynchronous ones would capture the mouse events for drawing whenever they are available and the synchronous ones would capture mouse events that affect the game. IF you like to implement that, ... I'd be happy about it, you could distribute profiling stuff between the faster machines or make complex HUD functions available for a larger amount of players, and whatnot. But I think we've had that in #oc-dev, right?
It might lag? Every game we play in CR you have ~ 500-1000 objects lying or flying around the landscape. What would one extra coord-pack per player affect? Player 1: Mouse at 1293 | 457... Player 2: Mouse at 494 | 764... and so on. Ok, in CR synchronization rate can be changed and is mostly played on 2-4 frames per sync. But we can sacrifice a ridiculous amount of bandwith for some coordinates.
In CR not the objects are synchronised, but the controls. So these 1000 objects don't slow down the network traffic. They only slow down, because the game has to wait for the slowest computer.
Well I'd think that for the bow, the clonk only starts to aim when pushing down the mouse button, gets an arrow out of his quiver and drawing the bow. After that, if the mouse button is released, he shoots into the direction. After the drawing animation and before the shooting (so, when the mouse button is hold) he'd aim.
If ControlUseHolding(object clonk, int x, int y) returns -1, the Using of the object is stopped (ControlUseStop is called) and no more ControlUseHolding-calls are made anymore, even if the mouse button is still held.
To prevent too much network traffic, the object that wants to use ControlUseHolding(object clonk, int x, int y) needs to define a function called HoldingEnabled() that returns true. Perhaps later it is added that it can return an int if a call per frame is not needed.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
