If so, I'd say the bucket should either round down or remember single pixels like digging in CR did.
I feel like I remember that we had this problem at some point in the past already.
PS: even if the bucket rounded down, I'd say the positive aspects of easier handling for the players still outweight that
A newbie who tries to figure out how to build loam has a high chance of failing this (e.g. water barrel or earth bucket not full) and will have no idea what went wrong. It's also completely unnecessery to make loam building so complicated, because both earth and water are typically available in abundance. You just don't get them into the foundry.
If the containers automatically emptied themselves into the foundry and there were an easy way to see how many pieces of loam I could build with the current materials, that would be an incredible improvement.
> CreateContents(Earth, 5)
Or CreateContents(Earth)->SetStackCount(5) if it's using the stackable library.
Another advantage would be that if destroy e.g. a foundry that contains earth, the earth could eject and the earth object could automatically dissipate into PXS on ejection.
>Or CreateContents(Earth)->SetStackCount(5) if it's using the stackable library.
As long as we don't win anything with that (like compressing things to one slot for the Clonk), I don't think we should complicate things just because we can. I'd prefer unity over individual solutions any time. Especially if we are still hoping to win new scripters, who start scripting/coding with OpenClonk.
The problem with the bucket is that you don't know how much earth it picked up after you used it. It makes an irregular shape of tunnel into the landscape wich makes it hard to know how much earth you have picked up. Especially when you are mining earth in a cave, wich is 99% the case. I often take in only ONE PIXEL and didn't realize it.
So the problem with the bucket is not the way the contents are measured, but how you obtain them. Having the contents show up as items instead of pixels doesn't change the fact that mining with the bucket is still a pain. You'd just get 1 or none earth-items into the bucket, instead of getting 1 or 2 pixels on your first try.
You could show the buckets contents either as items, or pixels, but you'd still have to probaby try several times until you get it full. So I see really no downsides in showing contents as pixels. I see more downsides with an item based approach, thoght. Like Clonko said, rounding errors. CR had that problem, that sometimes you'd get an earth object from 1 pixel earth, bacause you digged away some earth before. Showing pixels has the advantage, that you know what you have, it doesn't change, and you can't exploit it.
At this point I'd just thro out the bucket from the game (also because in minecraft bucket holds liquids, not dirt).
We could instead put clay items directly into the earth. Just a few, so you don't get spammed. They could even be very rare and big and carry-heavy. But you'd get like 5 loam out of one. It would make a positive expierience for the player to find a clay-item.
One advantage of "chunk items" versus pixels is that we can use the same component-based scripting for item assembly. So components of loam are e.g. Components=Earth=1;Water=1; and no extra scripting is required to handle material components. At the moment, the material components scripting pretty much doubles the scripting effort in the producer library.
We could also use pixels if we then use the stackable library. Then 200 pixels of water would just be CreateContents(Water)->SetStackCount(200). With 200 individual items per full water buckets, we would soon reach areas where performance may be affected.
> At this point I'd just thro out the bucket from the game (also because in minecraft bucket holds liquids, not dirt).
> We could instead put clay items directly into the earth. Just a few, so you don't get spammed. They could even be very rare and big and carry-heavy. But you'd get like 5 loam out of one. It would make a positive expierience for the player to find a clay-item.
I am not sure about this. The upside of the current approach is that once you have set up loam production, you can make any amount of it. Also, I like the clonk graphics when he/she carries two buckets :D
> So components of loam are e.g. Components=Earth=1;Water=1; and no extra scripting is required to handle material components. At the moment, the material components scripting pretty much doubles the scripting effort in the producer library.
That would be nice and simple. I like it.
>Yes, picking up objects by pressing DOWN would be really convenient, having to scroll to a free spot really isn't.
I am now testing the following:
* automatic collection into free slot is gone (automatic collection in general..)
* you can collect stuff by tapping [Ctrl]
* if you hold Ctrl, you can also navigate through possible objects via left/right
After test: I fixed some script errors, but I need to press both of my Ctrl buttons to make it work (on ubuntu 14.04 x64).
> I fixed some script errors
Was
effect
a script error for you? That should be the right keyword there> but I need to press both of my Ctrl buttons to make it work (on ubuntu 14.04 x64)
Meh. I had to use
Key=Ctrl+LeftControl
to make it work for me (on windows). But I assumed windows and linux would at least behave the same..Sven2, help! You know better than me how this stuff works :)
PS:
>This works also when swimming?
Yes, it should. It should actually work everywhere - maybe it's actually too lenient (during tumble etc.), but we'll see.
What about just LeftControl?
>What about just LeftControl?
I tried every possible combination of single buttons (Ctrl, LeftControl, LCtrl) just to then step through the debugger and see that I needed Ctrl+LeftControl.
But Sven has now implemented support for simply LeftControl, so it's rejoicing time now.
PS:
>No effect was not a script error, has this keyword been introduced recently? I always though it was a proplist.
It was introduced in 2011. And effects are proplists, but so are
id
and object
I get the same error as in the autobuilds:
https://autobuild.openclonk.org/builds/ec09d03b-677b-46bd-8628-fbe6ad621583/#make_3A_20openclonk
PS: wait, gammaramp? So it was PeterW!
Are there even two control keys on a mac?
I have one more problem now, though:
Previously, I had the navigation on Ctrl+CON_Left and Ctrl+CON_Right. Now, the picking up is not hard-wired to the "ctrl" key anymore but to an arbitrary key "LeftControl", that the player could also put on "A" or something..
But when I hold down LeftControl now, the normal CON_Left and CON_Right controls do not fire anymore. I guess that is somewhat intended, but could it be changed so that a control with a modifier is tried without its modifier in case the modifier-control was not caught by a script?
Then the user could also put that key on LeftAlt/LeftShift/X and it would work with any key. (I don't want to leave it on Ctrl+CON_Left, because the user should be able to put the control from LeftControl to f.e. Gamepad_X1)
You can just define a second navigation key as "Key=Ctrl+NavigateLeft" (or however your navigation control is called) and give that low priority. It would effectively be the fallback you want, but only for that control. Of course you would also need Shift+NavigateLeft in case the user decides to put pickup on shift (they cannot put it on Alt obviously).
Key=Pickup,NavigateLeft
with simultaneous keys and the pickup key is "Control", then the NavigateLeft key should automatically be filled in as Ctrl+(whatever was assigned to NavigateLeft)?
I find this combination rather awkward btw. So it is LeftControl+A and LeftControl+D?
As a left-hander using the keyboard with the right hand, I would press LeftControl with the thumb. But how do right-handed players do it?
Also test + finish your checkbox on the trello card please!
>I find this combination rather awkward btw. So it is LeftControl+A and LeftControl+D?
>As a left-hander using the keyboard with the right hand, I would press LeftControl with the thumb. But how do right-handed players do it?
It's not like I made up that control scheme myself. I think it's how 99% of all shooters handle crouching or walking since 1993. And it seems to work decently there.
But yeah, I am using my pinky to hold ctrl as a right-hander
>Okay, implemented it that way and pushed.
Doesn't seem to work flawlessly yet. When I use the key
Y
for CON_Pickup
and use Key=CON_Pickup,CON_Left
for switching, the controls seem to be passed as expected.When I use
LeftControl
for CON_Pickup
(same for switching), it doesn't work anymore. I have to use Key=CON_Pickup,Ctrl+CON_Left
for switching then, which kind of defeats the purpose of a free key assignment for CON_Pickup
.Sooo, I guess either I misunderstood how I should use it or I was too vague about how I was going to use it :I
Can you paste a reduced sample PlayerControls.txt that does not work?
Windows Key Lock
Accidentally pressing the Windows key during an intense game can result in losing rather than winning. You have the power to completely disable the Windows key by merely sliding a switch.
http://eustore.madcatz.com/Categories-EU_2/keyboards-category-EU/Mad-Catz-Titanfall-S-T-R-I-K-E-3-Gaming-Keyboard-for-PC_2.html
Btw the text floating up after collection is perfect, that is a really nice feedback for the player.
>Did you try to overlay the whole object with an additive version of itself as "selection mark"? I think this might even look better than this light flash
I can try that. Won't work well for very dark stuff like coal then, but I guess that's not really an issue
Plane
so that it's in front of everything (see bucket behind coal) - I like it :)@Particles: How about removing the glitter (imo this kind of fect should be used only for "ingame" effects, not menu selections) and adding this short light flash again? The flash made the newly selected object "pop up" better
Also, to further make it clear that it is just a selection the player is doing, perhaps highlight both the particle (flash) and the overlay in a certain common color - best the same color that is used for selections in menus. I'd suggest "light bluish" because it is a color that is well different from the rest of the colors in the game so it is clear to the user that the light/effects he sees there is nothing "ingame" but just a selection. (Not glow worms, not signifying that the item is worth very much and also not a light source)
>Wasn't there a blit mode next to additive that effectively made the object brighter? GFX_BLIT_Mod2
That seems to be glitched for sprites - maybe a shader problem or so. But in this case, I really don't think it's important. The coal really is a corner case and for 99% of the items it works well!
>How about removing the glitter (imo this kind of fect should be used only for "ingame" effects, not menu selections) and adding this short light flash again?
>[...]make it clear that it is just a selection ..[...]
I get your point with the particles. However, I don't like the flash.
What about a standard selector effect like the players know it from 99% of all other games :)?
PS: I like how the selector circle is just a pure particle effect!
PPS: and it's in player colour of course!
>What about a standard selector effect like the players know it from 99% of all other games :)?
Looks good. Just keep in mind that darker player colours could be a problem regarding visibility.
So ein helles Licht hinter dem Objekt wie im ersten Bild fänd ich besser. :D
@Kohle:
Wie wäre es mit SetGamma(), aber für einzelne Objekte?
Oder Lassen sich einzelne Objekte mit Shadern verändern? Und diese Shader dann per script an- und abschalten?
E: I forgot to english.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill