Not logged inOpenClonk Forum
Up Topic General / Feedback and Ideas / QuickShift: an alternative
1 2 3 Previous Next
Parent - - By Zapper [de] Date 2016-02-28 16:18
Are you gonna change that then <3
Parent - - By Sven2 [us] Date 2016-02-28 17:14
Yes, you can put it on my bug tracker list.
Parent - By Zapper [de] Date 2016-02-28 21:02
Done!
- - By Clonkonaut [de] Date 2016-08-02 17:40
Something I just realised:
When changing the number keys to select an inventory slot only on key up, it is now possible to have an easy way to sort one's inventory: number key + number key to switch two inventory slots.
Reply
Parent - - By Sven2 [us] Date 2016-08-02 22:44
Now inventory switch on number keys is completely broken. I can only switch on Q.
Parent - By K-Pone [de] Date 2016-08-02 22:55
Confirmed
Parent - By Clonkonaut [de] Date 2016-08-02 22:59
Oh, sorry. Fixed!
Reply
- - By Clonkonaut [de] Date 2016-08-03 12:39
To keep everyone posted:

Yesterday evening I experimented with showing the quick switch slot item on the clonk. Because I liked the look back when there were two items on the clonk. Kind of. I didn't like that the clonk carried two things in its hands. When you want to use an axe and carry a hammer around, you probably don't take the axe in one hand and the hammer in the other.

Anyway, I will experiment further. Right now, I am changing all the GetCarryMode (or GetCarry*) callbacks to include the slot the item is in (active slot / quick switch slot). Items can then return two different carry modes. Looks already with the shovel, carried in hand when active, carried on back when inactive. I will try if stuff like 'carry on hips' works and looks nice.

In order to do this, I will 'degeneralise' Library_Inventory. Right now, it still got all the remnants of the previous, two-handed control style. I changed GetHandItem to either return the active slot or the quick switch slot. But if you prefer, I will do this in the clonk's script instead in order to keep Library_Inventory as it is, i.e. ready to reactive two-handed controls. Feel free to state your opinion!
Reply
Parent - By Maikel Date 2016-08-03 13:23
Cool that you implemented this and are working on further details, hopefully I can test this weekend and give some feedback.
Parent - - By Zapper [de] Date 2016-08-03 14:06

>In order to do this, I will 'degeneralise' Library_Inventory


I remember that back then someone asked me to leave the functionality intact in the inventory library. That's why I didn't change it.
Parent - - By Clonkonaut [de] Date 2016-08-03 14:38
I'm curious to hear the reasons for this. Right now, the clonk's script is clustered with seemingly outdated or superfluous stuff (I was horrified to see that the scaling animation stuff saves an integer in 'this.dist' without any information what exactly this is). The 'hand item' attachment methods contain functions which are never called throughout our entire content. I also saw that the stuff I did with the numbered hotkeys (like saving which one was pressed in this.inventory.*) is also done in a kind of similar way in this.control.*. I am fearing now that this created another case of 'which library has to be included before another one in order to not break'. When writing the new functions, I was also not sure what exactly belongs in 'Library_Inventory' and what in 'Library_ClonkInventoryControl'. These two are kind of interdependent.

Everything, just to keep the illusion that the clonk's libraries are somewhat generalised and would work when being cherrypicked into your new X-Clonk. I grant you that currently you can set two hand objects (or three, four, five) and it will work (but of course, you have to write a new control library in order to actually use the second hand item). So it is not like you just include different code and everything works out of the box. I am wondering whether it is sensible to keep this code at all.
Reply
Parent - - By Zapper [de] Date 2016-08-03 14:47
I don't think I even remember who it was who told me to leave that in.

But yeah, the best would probably be to turn the Clonk libraries from stuff that is included into stuff that is just called from the Clonk script. But that would be a whole new can of worms.

PS: For example like this:
Clonk.ocd/Script.c:

public func RejectCollect(object obj)
{
    if (this->Call(Lib_CarryHeavy.RejectCollect, obj)) return true;
    if (this->Call(Lib_Inventory.RejectCollect, obj)) return true;
    if (this->Call(Lib_Controls.RejectCollect, obj)) return true;
    // more checks...
    return _inherited(obj, ...);
}


That would solve the issue with the order of inclusion and possibly with name pollution. It would have some other issues, though.

PPS: For all I care, go ahead and clean up the inventory stuff
Parent - - By Luchs [de] Date 2016-08-03 14:53

>name pollution


Locals in the libraries would still end up directly on the Clonk like this. Maybe something like local CarryHeavy = new Lib_CarryHeavy { Target = this };
Parent - By Clonkonaut [de] Date 2016-08-03 15:06
I guess it would already help a lot to see the engine callbacks in the clonk and then also see which libraries do decisive stuff. Right now, you have to manually scan through all the included scripts.

Then it would be okay if every library saved stuff in clonk.library_name.* - unfortunately, 'inventory' and 'controls' are not that ideal right now. 'this.dist' is just the worst but that's superold code. And there is also "fBothHands" and "iHandItem" for the attachment stuff.
Reply
Parent - By Zapper [de] Date 2016-08-03 15:16
Yes, that would also be nice. Even though you'd have to change the signature for the callbacks a bit.

Currently, at least the libraries I reworked, use a namespace for their variables (this.inventory.foo, this.controls.foo), which can still clash (if someone used e.g. "inventory") but the chances of a silent, unnoticed clash are practically 0.
Parent - - By Clonkonaut [de] Date 2016-08-04 01:13
Looking good so far!
Reply
Parent - By K-Pone [de] Date 2016-08-04 14:06
Yeah, especially the dynamite backpack
Parent - - By Clonkonaut [de] Date 2016-08-05 00:19
Pushed. There are maybe still some updating errors that sometimes show the items not in the proper way but those are minor bugs.

I also sorted all scripts I touched in a similar way, so all items are streamlined.

Check out these new and excited holding styles below!
Reply
Parent - - By Luchs [de] Date 2016-08-06 08:45
When scaling, both items seem to overlap on the back of the Clonk.
Parent - By Clonkonaut [de] Date 2016-08-06 10:06
I see how this might happen. Maybe I'll do something about it!
Reply
Up Topic General / Feedback and Ideas / QuickShift: an alternative
1 2 3 Previous Next

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill