Skills and Screen problem

Been a little while since my last post. I have worked on the skills. There is a skill class with all the variables that will do most of the math (and there will be a LOT of it). Actions will mostly be Strings in an ArrayList which will be unlocked as soon as some variables are high enough. There is an updater in the skill class that makes that check. Later on, I think I will have the Skill as top class which gathers all the "subskills", like fighting skills, woodcraft skills etc... . Just because I like to keep my classes small and structured.

That's about all about my skill class. There is one problem though... that nasty Skill screen. I want the following: the player presses either the direct key for a skill class, for example carpentry, OR a node screen from which the player can choose the "subskills". From the "subscreen / carpentry" skill screen, he will choose between "actions" (which will be made on world tiles) and "crafts" (in the inventory).

I have now the following setup: As I only have put in a very basic woodworking skill (I don't know why I always stick to wood haha), I left the most structure/ selection screens out. The player presses "R", and a screen with a collection of possible actions, currently only felling a tree pops up. The player presses "a" for felling a tree. It works quite much like an inventory, putting lines in from the Creature classe's private ArrayList<String> woodSkills.
Then comes the error: it should show the fellTreeScreen, which extends the DirectionBasedScreen and extends it only by starting a System.println.out("justatest").

The DirectionBasedScreen has a KeyEvent handler that returns the coordinates of an adjacent tile to the player depending on what direction button he presses. I made a test extension Screen of this, returning the coordinates in the console. In this test extension screen, it asks for the user input. However, the Felltree screen doesnt, even though it is almost absolutely identical. I have even given the same instructions to the constructor, but it just returns to the game after the player presses the "a" button form the skill action Screen. I wrote more system output lines and it all seems to work, both constructors are loaded. But there is not Key Input possible. Gotta find that error.

Oh and a happy new year in case anyone is reading this 🙂

  Post edit: I think I found the source of the problem, although I don't have a solution yet. Each basic screen class has a KeyEvent handler, which returns a screen object. Each class that derives from that base screen class, for example the FellTree extends the DirectionBased screen and accesses/extends this super class functions.

At some other place, in the main game loop, I have the following condition:


if(!subscreen == null){subscreen.keyHandle();}
else {
  keyHandle (here come the normal game controls)
}


This means, if there is a subscreen active, the key inputs go to that screen. Otherwise, they will go to the main game loop.

The problem is, in order to return from the keyEvent handler in any of the screen classes, it needs to return to null at some point, so that function ends (else it will always keep asking for some user input). However, for some reason the main loop detects that null value faster than the subscreen, which means that the subscreen doesn't have time to make his call. This is what I understand and I am sure there is a better explanation than this. So.. I either need to find an other way to return from the keyHandler or do something different about the main game loop.

02/01/2013 01:01

It works!
Unfortunately, it wouldn't make much sense if I explain it in detail. It had something to do with the Screen system I "borrowed" from Trystan's tutorials. I kept one function, which was the "use" fuction, which launched the creature's action (felling the tree in my case). What I ignored was the fact that that "use" is no function but a Screen object. So, instead of return this or return null, I did return use(stuff). The f*cking eclipse always told me: needs to return a Screen. Easy, but took me at least 2 hours of my life searching for a solution, including the deletion of at least 20 System.out.printlns() for debugging.

Leave a Reply

Your email address will not be published. Required fields are marked *