mouse button behavior

[overdhose]

there's a pretty stable version of the radial menu in my dev now, you can open the radial with either the middle mouse button, or by putting the radial tool (recipe : 2sticks and 1 dirt or get by F5 screen) in your toolbar and right clicking it. Not really used to gaming with the third mouse button besides scrolling, so right click feels a lot more natural to me, but hey you have the choice atm. There are no key bindings yet, and no option to disable the extended radial so you can't press the craft button itself to start crafting with the selected item in toolbar (which is my fall back way to do things for people without mice) so you have to click one of the items in the outer inventory to start crafting, but tbh it's hard to go back once you get used to it (specially because you can initiate crafting with an item that isn't in your toolbar)

I hope some of you will take it for a spin and let me know just how awful it is. Just in case this might tip you in favor, here's my repo link, all is in my miniion branch so you can leave dev untouched

 

[overdhose]

On the discussion of what the best use for single right click would be, I'd have to say now that it would become logical to have it close ui's. Once you become used to opening ui's by right click, and closing by right click, any ui that doesn't follow the same behaviour becomes "annoying" as you need to let go of your default keys to reach for that excape key

 

[Cervator]

Awh, I tried to build this in the highlighted branch job in Jenkins but the explicit dependencies on crafting & grammar made the build fail

Same thing locally until I defined the two as explicit dependencies for miniions. Figuring you had to do that too, overdhose ?

After doing that it worked fine and I could use the radial menu

Agreed that it becomes very natural that right click closes UI elements, although it would take a while to unlearn normal expectations for right click. Might take a bit to intuitively find the right stuff in the radial menu, a hovering label following the cursor when over a chevron (totally our name for icons in the radial menu, spread the world!) might help

I'm thinking it might be time to work in either explicit dependencies for modules (probably in mods.txt somehow) or handling for dealing with missing functionality that's survivable

 

[overdhose]

yeah when i said that miniions was now officially dependent on craft and grammar, I really meant "dependent".

As for the unlearning, it comes quick, that's why I mentioned it, because every time I opened an inventory I would sigh when right click didn't close it.

As for the explicit dependencies, I don't really know how to handle that.

 

[Cervator]

Gotcha

And yeah, this is an architectural topic. Maybe Immortius can provide some ideas, or mkalb some guidance on options via Gradle? Maybe a hard coded "modules to compile first" list in build.gradle could be a intermediate solution until we have full dependency management

 

[overdhose]

interesting bit is that actually running with the idea, I noticed there are enough chevrons for each inventory slot... could use them as background for empty slots.

stargate glyphs

it does make pretty radials...

 

[Immortius]

Gotcha

And yeah, this is an architectural topic. Maybe Immortius can provide some ideas, or mkalb some guidance on options via Gradle? Maybe a hard coded "modules to compile first" list in build.gradle could be a intermediate solution until we have full dependency management

My intention was to have a dependencies list in mod.txt, and have the gradle script parse mod.txt and apply those dependencies as it is dynamically adding in the mods as subprojects. Or something similar to this - might need to change mod.txt to a different format or something.

The dependency list would also be reused in the mod selection UI to automatically activate dependencies (or complain they are missing) when a module is selected.

 

[mkalb]

A first and fast solution would by a "build.gradle" file at "mods/miniions" which define the dependencies.

 

[Immortius]

Sorry, I couldn't resist. I actually have dependencies listed in mod.txt working already. Only took a few lines thanks to JsonSlurper.

I'm just looking at getting a couple of related features working and then I'll commit.

 

[mkalb]

Wow, that was fast.

 

[Immortius]

Alright, committed
So you can now include a list of dependencies in mod.txt like so:

{
    "id" : "OreoMinions",
    "displayName" : "OreoMinions",
    "author" : "Maternal Mathes.Wenzel@googlemail.com",
    "description" : "Oreo Invasion for Terasology",
    "dependencies" : ["miniion"]
}

Additionally I improved the ability to create a mod through the gradle build. If you add a new mod entry into settings.gradle, then the directory for that mod and a skeletal mod.txt is automatically generated when running any gradle task. Additionally you can use the "mods:<modname>:createSkeleton" task to generate a full mod directory structure with all the assets subdirectories and source directories.

 

[overdhose]

wach nice... but it's the other way around as far as dependancies go ^^

 

[mkalb]

By the way: Can we move the folder "assets" into "src/main/resources/assets"?

 

[Immortius]

I would prefer not to. For modules with no java code, it just seems inconvenient and confusing, and I'ld like to keep the layout for mods with java code consistent with those that do not. The only reason I've kept the maven directory structure at all is to allow for non-java modules (you could do a groovy module) and unit tests for those with the ability and desire to write them.

Or basically I'm working with a guiding principle that creating modules should be simple and convenient more than rigorous.

 

[overdhose]

I tested the dependencies and it worked... Selecting miniions enabled the other 4 mods by default.
however I decided to run "gradlew eclipse" and ended up with following error :
with --debug :

 

[Immortius]

I will look into this. Does "gradlew idea" similarly fail? One thing that comes to mind is the build script currently expects the mod ids used in mod.txt, in settings.gradle and the directories of each mod to be the same, probably including case. So you might try fiddling with that.

 

[overdhose]

that's why I had already changed the casing of OreoMinions and double checked the spelling, before posting the error. So unless it's acyaully another mod causing the erorr, i did use the "ID" of the mod and made sure it was in a similarly named directory, didn't have intellij installed but will do so now just out of curiosity.

 

[mkalb]

The current "develop" branch use "oreominions". Do you changed it?

 

[Immortius]

Hmm, I have replicated the issue, but only when the case of the dependency doesn't match the case of the mod declaration in settings.gradle (id isn't used by the build), e.g.

{
    "id" : "miniion",
    "displayName" : "Miniions",
    "description" : "A prototype of summonable, commandable minions",
    "dependencies" : ["core","OreoMinions"]
}

with

rootProject.name = 'Terasology'
include ..., 'mods:oreominions'

or if the two don't match at all.

 

[overdhose]

well, for one I forgot to add "core", added it but didn't solve issue. I renamed everything to lowercase "oreominions" => got past oreominions and got an error on cakelie instead... checked everything again, all seemed ok, ran gradlew again and now it completed succesfully, not sure what happened the time before. Anyway seems renaming everything to lower case (in all the mod.txts and all folders) solved the issue for me.