I also started working on the Controls branch alongside Zapper to make a merge possible. Here I will list the issues which are still blocking a merge, since I have lost overview in the last thread on the Controls branch.
Urgent
* Fix a certain desync (more info from Zapper).
* Menu hover and selection offsets due to ingame upper board.
Blocking
* Test multiplayer network Melee round.
* Test multiplayer network Settlement round.
* General test of all features (no bugs, no crashes).
Bugs
* Sawmill production can be changed and can lead to strange behavior.
* Move all button does not work to surroundings.
* Move all button does not work from surroundings to containers [not reproducible so far].
* Crash when ending a round.
* Fix tooltip showing in submenus.
Nice to have
* Clean sell interface in interaction menu (money display and tool tip on items which can be sold and a sell all button).
* Controls to move all objects of one type (maybe Shift+LMB or Shift+RMB).
* Fix backwards throw when running hitting you in the face.
* Test and improve the feel of controls (instant reaction vs. acceleration).
* Implement drag&drop for the new gui system + script interface.
* Reimplement the old HP and breath bars as objects.
* Think about interactions (Space bar) and which can be moved to the interaction menu.
* Test and think about dropping on throwing straight down.
* When having two players on one pc, all hud elements are placed inside the first players viewport.
I will update this post regularly until we have merged Controls into master, then we can start using the bug tracker I suppose.
Urgent
Blocking
Bugs
* Move all button does not work to surroundings.
* Move all button does not work from surroundings to containers [not reproducible so far].
* Crash when ending a round.
* Fix tooltip showing in submenus.
Nice to have
* Clean sell interface in interaction menu (money display and tool tip on items which can be sold and a sell all button).
* Controls to move all objects of one type (maybe Shift+LMB or Shift+RMB).
* Fix backwards throw when running hitting you in the face.
* Test and improve the feel of controls (instant reaction vs. acceleration).
* Implement drag&drop for the new gui system + script interface.
* Reimplement the old HP and breath bars as objects.
* Think about interactions (Space bar) and which can be moved to the interaction menu.
* Test and think about dropping on throwing straight down.
* When having two players on one pc, all hud elements are placed inside the first players viewport.
I will update this post regularly until we have merged Controls into master, then we can start using the bug tracker I suppose.
Question: should the structures in the hammer menu be ordered, and if yes according to what?
![[de]](/mwf/flags/de.png "Germany")
The buy menu orders by price. So I'd suggest to do the same here. Early buildings (sawmill f.e.) will automatically come first while advanced buildings (inventors workshop) will be be farther down.
Should that be a definition property (e.g. ConstructionMenuPriority), or by value, or by component value?
I am against introducing a new property.Just use the value. I am not sure whether we have a value for all structures, though. Then I'd suggest to either remove it everywhere and use the component value or to add it everywhere and use it then.
I think we need a value for settlement points anyway?
I'll use component value for now then, I am against giving value to buildings since it is a useless property. I hope we have removed settlement points from the game completely.
![[us]](/mwf/flags/us.png "United States")
I think value makes a lot of sense for buildings. For example, you could have a NPC that buys or sells buildings by value. An enemy AI might target buildings by amount of damage needed versus value.A building might be hard to construct because it needs exotic components that have little value. E.g. a statue built from a spider leg, a dead fish, a burned piece of wood.
Of course, we could have something like func GetValue() to the structure library which adds up the components and adds some for the construction work. Then structures can choose to overload it as needed but object designers don't need to worry about how much value to give to their structures.
I don't like the idea that a function like GetValue() needs to run a loop though...but I guess it would be premature optimization to call for a cache.
>Of course, we could have something like func GetValue() to the structure library which adds up the components and adds some for the construction work. Then structures can choose to overload it as needed but object designers don't need to worry about how much value to give to their structures.
>I don't like the idea that a function like GetValue() needs to run a loop though...but I guess it would be premature optimization to call for a cache.
Sounds like a sensible solution @overload GetValue().
Also, since the cache would be only one additional line of code, I'd say that would be reasonable too :)
Zapper, I saw that you removed ContainedUseAlt and friends. What is the reason for doing this? Now the right mouse button has no use whatsoever when being inside vehicles. I could imagine for example the being in the plane and having lead shot on the LMB and boompacks on the RMB.
Also when inside the plane and pressing E there is some weird behaviour for the interaction menu.
Also when inside the plane and pressing E there is some weird behaviour for the interaction menu.
>What is the reason for doing this?
I guess that just got thrown when I removed right-click interaction for items. I can see that it would might sense to at least provide that interface - for example for third-party packs
If you can point me to the commit of the removal I can reintroduce it myself :)
I guess some of it was in that commit. But especially if I already did something before the Great Cleanup, it might be easier (and a lot cleaner) to just reimplement it with the current layout of the library instead of trying to revert some old commits.I mean, what you are trying to do is pretty straight-forward: also accept some sort of UseAlt (lower priority than Throw), and then use an alternative callback (*Alt). In the old library that was tighly coupled to the second-hand item. Now this should be a lot easier (and cleaner!) to implement
PS: Some pointers to UseAlt in the PlayerControls.txt
The desync has now been fixed, great work Zapper!
One remaining issue is the menu offset ingame which prohibits decent testing.
One remaining issue is the menu offset ingame which prohibits decent testing.
That should be a trivial fix. I know the reason and I will just have to fiddle around in which places exactly I have to add the offset
Edit 2: Caesar fixed the display bug and I had no crashes today.
I like how you can fill the whole inventory by quickly rolling the mouse wheel. And it is good to have one button for throwing things again. Especially because of melees, I would prefer the throw button on the left mouse and the activate button the the right mouse button but that's not very important because I will be able to change the control settings. :)
One bug that I found was that if you have a few objects in the inventory and select Put all items to surroundings, only one object will leave the Clonk.
Attachment: OpenClonk.log - Log when loading another scenario. (5k)
>..and select Put all items to surroundings, only one object will leave the Clonk.
Yeah, I noticed that too. Maikel?
Other than that, weird.. You have the latest snapshot version? Maikel, you are using unix, too, right? I have only tested on windows yet. There isn't any really platform-specific code, though
This can be fixed by changing SetCommand to AddCommand in DropInventoryItem(int slot). But I am not sure whether that is the change we want, the problem is that on dropping all items the helper calls this function X times in the same frame resetting the drop command X-1 times.
Yes I am using unix, and don't have any problems here.
By the way, I think we are ready for merging, once we have tested a multiplayer network round.
Yes I am using unix, and don't have any problems here.
By the way, I think we are ready for merging, once we have tested a multiplayer network round.
>once we have tested a multiplayer network round.
I have played at least one round of Caedes online. But a more classic one would probably be a good idea, too :)
He said Caedes! *drool*
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
