> This will cause some issues with the message length, as (including links), the SE chat can display a maximum of 500 characters. We will almost certainly need #38 implemented first for this to work correctly.
@Marc-Andre It's nice that you want to help in this project. What would you like to work on? There are a whole bunch of things that needs work, but what to work on depends a bit on where your main skills are, and what you want to work on :)
As it is now, it seems like @bazola is primarily responsible for JavaFX, @skiwi for project structure and integration with stuff (Travis mostly) and some refactoring, and me for Server and game 'core' model and game model implementations.
Or at least that ^^ is the areas that we have been working on
@bazola Please pull my changes to the JavaFX branch, I hope Netbeans won't complain about them. I did some POM structure changes that's necessary for Eclipse to work properly
I had noticed the problem of threads not closing since I have been having to frequently Force Quit the java client.. but I did not realize that was the reason. I suppose I should figure out how to solve it :)
Well yea, heard that an old classmate of mine (talking about at least 5 years ago) passed away, even though I didn't know him well, I kind of know friends of him
We've got to check up on the JavaFX client as well
I'd like to step in at some point to do some massive overhauling, but I still believe it is best to let @bazola work on it mostly, but I believe currently some things are not done in the correct way; which you can only learn by experience
Agreed. I have noticed that there are some things that can be made more extensible/flexible. But @bazola has done an amazing job with the JavaFX client overall.
> 01-Oct-2014 14:32:43.584 SEVERE [http-nio-80-exec-10] com.skiwi.githubhooksechatservice.mvc.controllers.GithubHookController.handleException exception java.lang.NullPointerException at com.skiwi.githubhooksechatservice.mvc.controllers.GithubHookController.issues(GithubHookController.java:207) at sun.reflect.GeneratedMethodAccessor1285.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at or...
g.springframework.web.method.support.InvocableHandlerMethod.invoke(InvocableHandlerMethod.java:215) at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:132)
@bazola I'm not sure why the changes to the client-server branch were not pulled correctly. Do you have the history of the commands you ran? (And possibly their outputs?)
@bazola When you do two pulls in a row, the second is always 'up-to-date'. The first pull was for POM changes because I had pushed them to the JavaFX branch
@bazola What I would have recommended to do is first git pull to ensure that your local javafx branch is up to date, and then git pull origin client-server to merge with the client-server branch
As it is now, you'd still need to do 'git pull origin client-server' because it doesn't seem like you have got the latest changes
Somehow my Netbeans is bugged and shows a lot of things in the cardshifter-fx as errors (it still builds fine via Maven), Saying that a lot of types of methods are erroneous
@SimonAndréForsberg What is this thing? I see the warning always popping up, but I ignore it
@SimonAndréForsberg cool I went ahead and did that command. I think i understand what went wrong, I need to remember that git pull origin "branch" command
@skiwi if you configure it to use 'simple', it will only push the branch that you are currently on. If you use 'matching', it will try to push all branches.
btw, I'd suggest you @skiwi and @bazola that you run git config --global -l so that we can compare our git configs. (You can strip out the github.token)
@SimonAndréForsberg A Maven submodule, I don't know exactly, but I figured that having com.cardshifter.ai inside cardshifter-core is incorrect, com.cardshifter.core.ai would be allowed though
public final class Mods {
private Mods() {
throw new UnsupportedOperationException();
}
public static Mod open(final Path bootFile) {
String filename = bootFile.getFileName().toString();
String[] splits = filename.split("\\.");
String extension = splits[splits.length - 1].toLowerCase(); //TODO add locale support?
//switch over this or use enum mapping to obtain correct mod
}
}
So the cardshifter-server will call Mods.open(), and receive his Mod back
So I'm wondering what there should be all in the Mod interface
public interface Mod {
Object startGame(final Object players);
}
What do I return, and what do I take as input?
@SimonAndréForsberg Hmm that's not what I was looking for, might need to dig further... I'm trying to figure out in what order Eclipse orders the Java imports, I figured out so far: java, javax, javafx, net, org, com, others
@skiwi You should return an ECSGame, as for input... that depends on how issue 30 is solved (Choose some things before the game)
@skiwi Oh, is that what you're looking for? That's probably some place in the Eclipse workspace settings. I know there's a SO question asking about it somewhere though
@skiwi Two players are always added to the game, their names is set inside the game as 'Player 1' and 'Player 2', whether or not a Player is an AI or not is decided outside of the game construction.
Actually I really urge you @SimonAndréForsberg and @bazola to create unit tests (starting with non-GUI code), it really helps to keep you sane about your method naming and class hierarchy
I've been thinking about tests a bit, and how would we test client/server stuff. Seems like the only way currently is to run a live game for a number of turns, and manually enter the commands, such as end turn? The problem is that it would actually take a while, since the AI's turn is artificially increased to 5 seconds in between moves
so maybe the server needs a special mode for when we are doing unit tests on GUI code?
The jars are just being sauce around the real methods to make them runnable, all you need for the server to run actually is to call something along the lines Server.run()
@SimonAndréForsberg one thing I don't like about the way that cards moving from the Deck to the Hand works, is that i have to duplicate the logic looking for cards to delete in both the ZoneChangeMessage method and the EntityRemoveMessage method. Once cards are moved to a discard pile instead of having EntityRemoveMessage, this won't matter as much. But right now I have to do this for EntityRemoveMessage:
if (this.opponentDeckEntityIds.values().contains(message.getEntity())) {
this.removeCardFromDeck(this.opponentDeckId, message.getEntity());
} else if (this.playerDeckEntityIds.values().contains(message.getEntity())) {
this.removeCardFromDeck(this.playerDeckId, message.getEntity());
}
I think it's perfectly fine to close that issue for now @skiwi. As long as it has been tested. (Isn't that really what 'quality assurance' is about btw?)
@SimonAndréForsberg Well, Quality Assurance might not be the best name for it... I intend that issues remain in that queue (currently called QA) until merged into master
unit testing the GUI is complicated... I used TestFX a little bit but writing tests there requires a lot of code.. testing GUIs is better done manually IMO
An outstander might look at the repo and find the issue he is experiencing (cards do not get discarded), he then opens the issue and finds that it is on status "waiting for next release"
@SimonAndréForsberg I'm trying to set up an EventHandler thing for when the window closes, but it says that there is a class with that name in the ecs branch and its picking the wrong type of EventHandler
You can also add EventHandler on Close Request:
primaryStage.setOnCloseRequest(new EventHandler<WindowEvent>() {
@Override
public void handle(WindowEvent t) {
Platform.exit();
System.exit(0);
}
});
@SimonAndréForsberg But then it would become kind of a reversed lookup... We register a bunch of files, say .class/.lua, either apply it on a single file or extract a zip/rar/jar, and check which files it contains?
@bazola Using lambdas I always do: stage.setOnCloseRequest(windowEvent -> { ...code });
You can also add EventHandler on Close Request:
primaryStage.setOnCloseRequest(new EventHandler<WindowEvent>() {
@Override
public void handle(WindowEvent t) {
Platform.exit();
System.exit(0);
}
});
