Resolved modding problem, indirect reference

overdhose

Active Member
Contributor
Design
World
GUI
tried to solve this myself, but not really my expertise here.

first of all, maybe let me state I'm using eclipse atm, as I had it installed, not sure of that changes anything.

anyway, loading the miniions mod project, I received this error :

DescriptionResourcePathLocationType
The type org.newdawn.slick.Color cannot be resolved. It is indirectly referenced from required .class filesUIMinionBehaviourMenu.java/miniion/src/main/java/org/terasology/miniion/componentsline 44Java Problem
the prob comes from using UIImage (the gui widget) which uses said slick.color type. Not really sure how I have to solve this, any pointers are welcome.
 

overdhose

Active Member
Contributor
Design
World
GUI
ok while this error appeared, it was not what made me crash. It was a call to bulletphysics. Will change my code as workaround.
 

Immortius

Lead Software Architect
Contributor
Architecture
GUI
Hmm, interesting. One of the issues with our current UI system is no decision on which of the multiple-available Color classes to use - preferably not slicks. But not the matter at hand

That error is usually a compile error, it means that the slick library isn't being provided to the mod when compiling - while the mod doesn't directly use it, a class it uses does. Are you using IntelliJ or Eclipse? I might need to experiment more with the build setup.
 

overdhose

Active Member
Contributor
Design
World
GUI
using eclipse, as stated above. Anyway, launching Terasology it simply seems to ignore this issue all together and works just fine. Also keep in mind that these UI's were created quite a while back and as such might need cleaning / optimizing. But it works.

Actually, I created an action called OpenUiAction, I just feed it the ID of the window I wonna open (after registering them) and that enabled me to open just about any ui I need in the mod :p

So, I created 2 books with an ui that resembles the item list, 1 book contains cards that let you summon minions, and the other book iterates summoned minions and displays a list of summoned minions. This would make that pesky minion bar obsolete and move all code to the mod itself.

here are some initial screens
cardbook.pngminionbook.png

let me know what you think of it.

PS : forgot, the idea is to let you select an active minion in that second book, and set it's behaviour through the book. Then you use that minioncomand item to command him around.
Obviously I didn't get that far yet.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Looking good :)

As far as GUI stuff goes, want to look at the work pending by x3ro in this post? If we can get that integrated early (he might not be able to get to it till March or later) it'll be easier to work with anything GUI related.

We also had a discussion on where to put what and I've thought on that slowly getting used to my not-so-new-Android phone now - namely widgets taking up x,y slots in a grid-based GUI layout. I figure that would be a good way for modules, like miniions or books, to register a location for a custom GUI component, with fall-back options in case some spot is already reserved or not available on an alternate platform. Could nest it like I've described somewhere (I think..) so you can use multiple small components in a corner together. But we really need solid GUI definition options to try something like that.

I'm also remembering that we still have your old thread on GUI stuff. I wonder if that needs to be merged into something that has sprung up since :)
 
Top