Agent in JADE behaviour not working - java

I'm trying to create a game where JADE Agents are the 'enemies' and they chase a player around a maze.
So far I have:
MazeView.java (uses Swing to paint various things on the screen, and lets the user interact through button presses)
Enemy.java (a JADE agent that will have behaviours like search, pursue, etc.)
And a few other classes doing things like generating the actual maze data structure etc.
My problem is that, while I can instantiate an Agent and paint it on the screen, for some reason I can't add any behaviours. For example, if I wanted something like this (in Enemy.java):
protected void setup() {
// Add a TickerBehaviour that does things every 5 seconds
addBehaviour(new TickerBehaviour(this, 5000) {
protected void onTick() {
// This doesn't seem to be happening?
System.out.println("5 second tick... Start new patrol/do something?");
myAgent.addBehaviour(new DoThings());
}
}); // end of addBehaviour
System.out.println("End of setup()...");
} // end of setup
When I run the code, no errors are thrown, and I can see "End of setup()..." displayed in console. So for some reason it's just not going into the addBehaviour() method at all. Even if the DoThings() behaviour didn't work (right now it just prints a message), it should at least display the "5 second tick" message before throwing an error. What is going wrong here?
I think it could be something to do with the fact that currently there is no concept of 'time' in my maze. The user presses a key, and THEN processing happens. So having an agent that does things every 5 seconds might not work when there is no real way to facilitate that in the maze? But I'm still confused as to why it just skips addBehaviour() and I don't get an error.
A possible solution might be to re-implement my maze as a constant loop that waits for input. Would that allow a concept of 'time'? Basically I'm not sure how to link the two together. I am a complete beginner with JADE.
Any ideas would be appreciated. Thanks!

I've never used Jade, but my first thought was that you are adding behaviors and then assuming that Jade will decide to run them at some point. When you say that you never see your behaviors activate, it strengthened that hypothesis.
I looked at the source and sure enough, addBehaviour() and removeBehaviour() simply add and remove from a collection called myScheduler. Looking at the usages, I found a private method called activateAllBehaviours() that looked like it ran the Behaviours. That method is called from the public doWake() on the Agent class.
I would guess that you simply have to call doWake() on your Agent. This is not very apparent from the JavaDoc or the examples. The examples assume that you use the jade.Boot class and simply pass the class name of your agent to that Boot class. This results in the Agent getting added to a container that manages the "waking" and running of your Agents. Since you are running Swing for your GUI, I think that you will have to run your Agents manually, rather than the way that the examples show.
I got more curious, so I wrote my own code to create and run the Jade container. This worked for me:
Properties containerProps = new jade.util.leap.Properties();
containerProps.setProperty(Profile.AGENTS, "annoyer:myTest.MyAgent");
Profile containerProfile = new ProfileImpl(containerProps);
Runtime.instance().setCloseVM(false);
Runtime.instance().createMainContainer(containerProfile);
This automatically creates my agent of type myTest.MyAgent and starts running it. I implemented it similar to your code snippet, and I saw messages every 5 seconds.
I think you'll want to use setCloseVM(false) since your UI can handle closing down the JVM, not the Jade container.

Related

slow (JavaFX) code even after reseting the repository

I just faced a strange behavior and I can't even say if it is a JavaFX specific problem, Eclipse problem or even where to start fixing first.
But first things first: I'm writing a JavaFX application (Eclipse Kepler/ Java 1.7), containing some extended ListViews. The program takes about 1sec to load.
The extended ListViews look something like that:
public class NewList<T extends Obj> extends ListView<T>{
public NewList(){
// addEventHandler(KeyEvent.KEY_RELEASED, new EventHandler<KeyEvent>(){
//
// #Override
// public void handle(KeyEvent arg0) {
// if(arg0.getText().equals(KeyCode.DELETE)){
// getItems().remove(getSelectionModel().getSelectedItem());
// }
// }
// });
}
}
There are also some MouseEvents (like drag and drop) inside the same constructor, and they are working as expected.
Now I want to add an EventHandler to my extended ListView (see commend in the code above).
The code takes now about 8sec to start aka 8 times longer as normal. To my surprise 90% of the loading time the program is inside the .show() method of my primaryStage (there is just one). After the loading time, the GUI is extreme slow and the cpu usage is on 100%.
Maybe the Handler is implemented wrongly and is doing some strange stuff during the whole time.
I can't find any solution or even comparable problem on the internet....but now the real problem just begun:
When I delete the Handler and run the program again, it will stay slow! So the program is in the same state as before - just still broken! That makes me crazy, because I can't see any logical explanation for that behavior.
What I have already tried:
delete the bin folder inside the repository and build the code again (+reboot)
reset the repository via git
throw half of the code away and started again. At any point it worked again, unfortunately I was not able to reproduce the effect. Then I implemented the Handler again and the problems started from the beginning...
edit: it looks like there goes something wrong during the building process/updating the binarys. I deleted 99% of the code (>5k LOC), then it worked. I copy/pasted the original project back into my workspace and the hole code worked smoothly - even with the Handler on. So I can't imagine a way to produce a minimalistic setup. btw: I'm not allowed to release the complete project folder (university stuff...)
edit2: I' using win7 64bit with java64. other javaFX programs are working (even then grafic intensive oracle samples). I'm not using any JavaFX specific repository setup or builder
Okay, I faced the same problem a few minutes ago and I think I found the source this time.
I'm running my code ALWAYS in debugging mode. To check the EventHandlers condition, I created some breakpoints in Eclipse. I also created a breakpoint at the following line of code (see above for more code)
public void handle(KeyEvent arg0) {
A mouseover over the breakpoint provides the following information:
Multiple markers at this line
Method breakpoint:NewList [Entry] - handle(KeyEvent)
implements:javafx.event.EventHandler .handle
I don't know what is happening here exactly but I think its something like this:
I'm overriding a JavaFX EventHandler Method and the debugger has to check the breakpoint on every single JavaFX interaction/EventHandler call. So Eclipse cant handle the flood of checks in a propper time and all seems to be very slow.
To clear that out: the breakpoint itself does not have to be called at any time, just the existing of it is enough to cause the problems.
Deactivating the breakpoint or running the application in a non-debugging mode will fix all problems. I think it should be a good idea to avoid all entry-breakpoints in any kind of Listener/EventHandler :)

Eclipse. Run two different mains when the second reads a static field of the previous

I have a Java project in eclipse which is divided in two parts; two different main classes that run two different Threads basically.
One contains loading, initialization and debug-showing procedures that are quite slow. While, the other manipulates the initialized data. In order to retrieve the information in the second part, the first one "saves" all the references inside a static map which contains instances of classes.
Does exist a way to run the first part only once, and then compile and run the second part more times? I tried with just set two different console and pressing the run button in different times but the static field of the first class looks not existing when the second runs.
I am working now only in the second part, so I need to test and start it many times. I really appreciate an help to save a lot of time wasted in always initialize the same thing.
ps : Everything works fine if I run both parts together.
thanks in advance
Luca
thanks to the replay (Multithreader, Stephen C) I am trying to make the question more clear and to ask how to solve it since my solution does not look the best one.....
EDIT 1 : The "first part" initializes the program and then runs an easy GUI which is periodically update. So as long as it shows up we shouldn’t care about how to manage input and output from the user
EDIT 2 : the "second part" reads information from the previous and send back strings to the GUI for debug purposes.
EDIT 3 : I do not have specific constrains in the shape of the project, so I can change the structure if there are better solutions. As well as for the way to run it.
FARTHER QUESTION 1 : there is a possibility to compile only one part of the project in eclipse while it runs all together? I mean, if two threads are running, can I stop one, re-compile it and run it again in a way that it can see the instances created from the first thread which never stops? Basically I need to refer at the same static variable loaded in memory, if it exists.
FARTHER QUESTION 2 : or more luckily does exist a way to store and load in a file instances of Java classes avoiding to write from sketch a mapping mechanism from/into txt files?
It is not entirely clear what you are asking here, but I'm assuming that you are talking about running the "first part" and the "second part" in the same JVM ...
Yes, it is possible. But it is not straightforward.
Basically, you need to refactor your code so that there is some kind of "control box" that the user can interact with from the outside. For instance, this might just be a simple command loop that reads commands from standard input and runs them. (Alternatively you could turn your application into a "service" that accepts requests over a network socket, via RMI, via HTTP, etcetera.)
Then you wire things up so that there is a "command" to run the "second part" of your application in response to the user's request.
That's the basics. The other thing you want to do is to "compile and run the second part [many] times". That implies that you need to set up your "control box" so that it can load a fresh copy of the code for the "second part" after you have modified and recompiled it. To achieve this, you will need to create a new ClassLoader object (each time) and use that to load the classes that make up the "second part". This is possible, but a bit tricky. The problems you are going to need to address include:
Splitting the "first part" and the "second part" into separate JAR files (or directory trees). The "first part" needs to be self-contained ... no dependencies on classes in the "second part".
Make sure that there are no runtime references from the "first part" data structures to instances of objects / enums in the "second part".
If you don't get the above right, you are likely to experience "permgen" storage leaks and mysterious type cast errors.
All in all, there's a lot that needs to be done to make this work. Unless you already understand all of the technologies involved, I'm doubtful that it will save you time overall. A better idea might be to figure out how to speed up the initialization of the "first part"; e.g. by doing lazy initialization, or caching the data structures using some fast / light-weight persistence mechanism.
I think it is better to change your design unless there is a requirement for it to stay the same.
Although I do not have the requirements or what you are actually trying to accomplish, I suggest you the following design:
1. App_1 does the calculations and then writes the results into file
2. App_2 reads checks for the file, if NOT exists display error message; otherwise read the file and keep going...
I guess I found a tricky solution. It is dirty but it works natively in the eclipse debugger.
I am running in debugging mode a main method which create a thread that works as a caller. This runs the first part of the project and wait until the initialization is complete (note that the first part doesn't end here, it remains looping to show debugging information based on a static class which evolves with the second part of the program). Then it starts with an infinite loop where it just calls the second part that I want to test and change: here there are also a breakpoint.
Well, now I can coding in the second parts while the eclipse debugger is waiting in the breakpoint than save it and hit F8. The debugger resumes, the algorithms runs and then it stops again in the breakpoint. Just check if works, eventually change something then save and hit F8 again without wait to re-initialize the first part of the project.
Probably this method has to be restarted after a while but still, it better then restart every time :)
many thanks to all your help.
If somebody has more elegant way to do that they are welcome!!

With Slick2D, how to change the resolution during gameplay?

I am developing a tile-based strategy game using Java and the Slick2D API.
So far so good, but I've come to a standstill on my options menu. I have plans for the user to be able to change the resolution during gameplay (it is pretty common, after all).
I can already change to fullscreen and back to windowed, this was pretty simple...
//"fullScreenOption" is a checkbox-like button.
if (fullScreenOption.isMouseOver(mouseX, mouseY)) {
if (input.isMouseButtonDown(Input.MOUSE_LEFT_BUTTON)) {
fullScreenOption.state = !fullScreenOption.state;
container.setFullscreen(fullScreenOption.state);
}
}
But the container class (Implemented by Slick, not me), contrary to my previous beliefs, does not seem to have any display-mode/resolution-change functions! And that's pretty much the situation...
I know it's possible, but i don't know what is the class responsible (if it exists)!
The AppGameContainer class, used on the very start of the game's initialization, is the only place with any functions for changing the display-mode that I've found so far, but it's only used at the very start, and as of Slick's tutorials, is implemented as local.
//This is my implementation of it...
public static void main(String[] args) throws SlickException {
AppGameContainer app = new AppGameContainer(new Main());
// app.setTargetFrameRate(60);
app.setVSync(true);
app.setDisplayMode(800, 600, false);
app.start();
}
I can define it as a static global on the Main class, in order to use it inside the update() method of the options screen, but it's probably a (very) bad way to do it...
There is an easy way to do this. I found this on another site. You can cast the GameContainer object (the one you get from the update method) into an AppGameContainer method. Then you can access the setDisplayMode:
AppGameContainer gc = (AppGameContainer) container;
gc.setDisplayMode(800, 600, false);
Original post here.
Theoretically all you have to do is create a new AppGameContainer object, and then re-run all your initialization code, except for code that resets the state of your game (you don't want the game to be reset to its starting state, after all).
You're right that the tutorials don't cover this, so I don't think you're missing anything. Here's a list of concerns that you'll have to handle when changing resolution. So long as you break these out into separate methods in such a way that you can re-run init any time in the game, then you should be fine.
Your render method needs to check the current resolution with each execution when it determines what to draw. To say it another way, the render method shouldn't care what the current resolution is - it should just look it up each time, and do what's appropriate.
If you're using the Slick buttons and other UI events, including event listeners, then before you re-initialize everything, you need to get a list of all the subscribed listeners, re-initialize your UI elements in the new AppGameContainer, and have all the listeners re-subscribe to the new elements.
Analyze your code and look for any other place that depends on the UI being a certain state, and re-initialize it from the init method when the resolution changes.
So, the pseudo-code version of this is:
When your game first starts up:
main(args)
- initi()
if (gameStartingForTheFirstTime())
- initUI()
- initGameState()
- initWhateverElseYouNeedToForYourGame()
if (resolutionChanging())
- initUI()
After also consulting gamedev.stackexchange and Slick2D's forums, the action i took to solve the problem was to use a mix between #normalocity's solution, the use of the ScalableGame interface, as well as, and most importantly, compiling my own version of the API (since it's open-source).
The changes to the API include, but are not limited to, a more direct access to Container's setDisplayMode(), with solved the problem related to this question.
For anyone with the same or similar problems, this is the solution I suggest.
EDIT-NOTE: Although my answer is still valid, and I am not developing with Slick2D, #Requios' answer is a better approach without any problems, judging by the positive votes and lack of comments pointing out any problems. So that's the approach I'd recommend, and I've accordingly switched the "chosen answer" to his, as well as cast my own upvote.

rJava startMainLoop() function kills Java operations

I've developed an interface that allows a user to load and manipulate data. The GUI is developed in Java and all the computational stuff is done in the background by R, linking the two with jri. The idea is that the user doesn't have to have any knowledge of R to use it, it's all options and buttons. However, i'd like to give the user the option to write some code if necessary. So here is my problem:
If I use the following code to start the Rengine and not let the user interact via console, everything works fine:
Rengine re=new Rengine(null, false, new TextConsole());
But if I use this:
Rengine re=new Rengine(null, true, new TextConsole());
The functionality of the gui doesnt work. I tried using the
re.startMainLoop();
function after the data was loaded. I was able to manipulate the data from the comand line in R, for example I could make a new variable from a column of the data loaded:
newVariable<-data$column1
But yet again, I couldn't use the gui anymore. Has anyone got any ideas or explainations as to why this is?
Thanks in advance,
Aran
Fundamentally, if REPL is not running, R is simply used via eval calls from your code. You have control at all times, except during the actual evaluation. That is the most common use, because you can do pretty much anything that way.
The moment you enable the event loop (REPL), you have to implement the callback methods that are used by the loop. By design R surrenders the control only by calling the rReadConsole callback which you have to implement. The example TextConsole works only as a demo, it uses blocking call (readLine()) to wait so you definitely don't want to use that in your GUI. You'll have to implement all callbacks correspondingly to react to your GUI's elements (wait in ReadConsole for your GUI to wake it up from a separate thread, dispatch WriteConsole to your elements etc.). You can have a look at JGR how it's done properly. Unless you are really building a general purpose R GUI, I wouldn't go into that trouble ...
(PS: please use stats-rosuda-devel mailing list for rJava/JRI questions - you get answers much faster)

Questions: controlling a Swing GUI from an external class and separating logic from user interface

UPDATE: I'm using Netbeans and Matise and it's possible that it could be Matise causing the problems I describe below.
UPDATE 2: Thanks to those who offered constructive suggestions. After rewriting the code without Matise's help, the answer offered by ignis worked as he described. I'm still not sure how the code the Netbeans code generator interfered.
Though I've been programming in Java for awhile I've never done any GUI programming until now. I would like to control a certain part of my program externally (updating a jTextArea field with output from an external source) without requiring any user action to trigger the display of this output in the jTextArea.
Specifically, I want this output to begin displaying on startup and to start and stop depending on external conditions that have nothing to do with the GUI or what the user is doing. From what I understand so far you can trigger such events through action listeners, but these action listeners assume they are listening for user activity. If I must use action listeners, is there a way to trick the GUI into thinking user interaction has happened or is there a more straightforward way to achieve what I want to do?
Also, I'd really like to know more about best practices for separating GUI code from the application logic. From the docs I've come across, it seems that GUI development demands more of a messy integration of logic and user interface than, say, a web application where one can achieve complete separation. I'd be very interested in any leads in this area.
There is no need to use listeners. GUI objects are just like any other objects in the program, so actually
you can use the listener pattern in any part of the program, even if it is unrelated to the GUI
you can invoke methods of objects of the GUI whenever you want during the program execution, even if you do not attach any listeners to the objects in the GUI.
The main "rule" you must follow is that every method invocation performed on objects of the GUI must be run on the AWT Event Dispatch Thread (yes, that's true for Swing also).
http://download.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html
So you must wrap code accessing the GUI objects, into either
javax.swing.SwingUtilities.invokeLater( new Runnable() { ... } )
or
javax.swing.SwingUtilities.invokeAndWait( new Runnable() { ... } )
http://download.oracle.com/javase/6/docs/api/javax/swing/SwingUtilities.html
About "separating GUI code from the application logic": google "MVC" or "model view controller". This is the "standard" way of separating these things. It consists in making the GUI code (the "view") just a "facade" for the contents (the "model"). Another part of the application (the "controller") creates and invokes the model and the view as needed (it "controls" program execution, or it should do that, so it is named "controller"), and connects them with each other.
http://download.oracle.com/javase/tutorial/uiswing/components/model.html
For example, a JFoo class in the javax.swing package, that defines a Swing component, acts as the view for one or more FooModel class or interface defined either under javax.swing or one of its subpackages. You program will be the "controller" which instantiates the view and an implementation of the model properly (which may be one of the default implementations found under those packages I mentioned, or a custom implementation defined among your custom packages in the program).
http://download.oracle.com/javase/1.4.2/docs/api/javax/swing/package-summary.html
That's a really good question, IMHO... one I asked a couple of years ago on Sun's Java Forums (now basically defunct, thanx to Oracle, the half-witted pack of febrile fiscal fascists).
On the front of bringing order to kaos that is your typical "first cut" of an GUI, Google for Swing MVC. The first article I read on the topic was JavaWorld's "MVC meets Swing". I got lucky, because it explains the PROBLEMS as well as proposes sane solutions (with examples). Read through it, and google yourself for "extended reading" and hit us with any specific questions arrising from that.
On the "simulated user activity" front you've got nothing to worry about really... you need only observe your external conditions, say you detect that a local-file has been updated (for instance) and in turn "raise" a notification to registered listener(s)... the only difference being that in this case you're implementing both the "talker" and the "listener". Swings Listener interface may be re-used for the messaging (or not, at your distretion). Nothing tricky here.
"Raising" an "event" is totally straight forward. Basically you'd just invoke the "EventHappened" method on each of the listeners which is currently registered. The only tricky bit is dealing with "multithreaded-ness" innate to all non-trivial Swing apps... otherwise they'd run like three-legged-dogs, coz the EDT (google it) is constantly off doing everything, instead of just painting and message brokering (i.e. what it was designed for). (As said earlier by Ignis) The SwingUtilies class exposes a couple of handy invoke methods for "raising events" on the EDT.
There's nothing really special about Swing apps... Swing just has a pretty steep learning curve, that's all, especially multithreading... a topic which I had previously avoided like the plague, as "too complicated for a humble brain like mine". Needless to say that turned out to be a baseless fear. Even an old idiot like myself can understand it... it just takes longer, that's all.
Cheers. Keith.
This doesn't exactly answer your question, but you might be interested in using Netbeans for Java GUI development. You can use GUI in Netbeans to do Java GUI development.
Here's a good place to get started -
http://netbeans.org/kb/trails/matisse.html

Categories