[[Cardshifter/Cardshifter](null)] build #690 for commit [40ff1932](null/commit/40ff1932cae8557c0212c1c76382fdc310f3a79d) on branch [gdx](null/tree/gdx) passed
@Duga ah, you lose that information when the commit is the day before, and the travis result on the day after
@Phrancis I think there is more integration than that though, you are currently in the git repository view, open the project layout view (or whatever it is called)
> The above functionality has been implemented. Closing this issue, as essentially - it works. Adding new features is not too hard either (at least not for me who knows how the ECS stuff works)
> Names has been added and showing properly, descriptions are not showing correctly yet though. (Neither flavortext, nor actual descriptions about what the effects are)
> JavaFX can show effect descriptions (but not at the same time as name) currently. Additionally, the text for some of the cards with long names go outside the card itself, as shown in screenshot.
Also, effect descriptions should be improved to actually show something that makes sense
We noticed you recently created a branch in GitHub. Did you know that we’ll move an issue to ‘in progress’ and assign it to you if you reference it in the branch name? Just put the issue number at the beginning of the branch name with a '-' or '_' behind it or anywhere else in the branch name with a '#' in front of it.
Here are some example branch names:
123-fix-bug
bug-fix#123
bug-fix-username/repo#123 (issue in another repo)
This prevents us from moving issues based off other numbers sometimes used in branch names.
> Currently, we're not supporting gwt - which means we can't export as HTML5 application. If we make the following changes, we could:
- Remove log4j dependency in cardshifter-api, or possibly try http://log4j-gwt.sourceforge.net/ - Remove jackson dependency in cardshifter-api, use jackson mixins instead, or possibly write the code in such a way that jackson annotations are not required
> I'm thinking that in the "Make your own mod" section, these things could be stated, that the events are the main way mods interact with the game when it is being run. Then follows a list of all the events with a description of when they're being executed.
> Changed Command calling: removed case-sensitivity - also slightly simplified the filter by moving the extraction of the command-name to outside of the stream
> Implemented message reply functionality, fixes #17 - PrintUtils now can "format" text as a reply given a String and a ChatMessage - DefaultBot now replies to processed messages
> We used to have that architecture... but it was abolished because of the redundancy to reprocess stuff to match the predicate anyways. Commands can now be written to return an error message instead of silently failing when they don't match the Predicate
> incorrect. You cannot use a method reference when processing data from outside the stream. We're Streaming CommandHandles here and the last map is matching a Consumer<? extends ChatMessage> and not Consumer<? extends CommandHandle>
> the alternative is to bind it in calling code. but the calling code gets cluttered by that. the reference is contained in the CoreBotCommands and will be used for lambdas so... it's kinda escaping anyways
> How about using a factory method and making the constructor private? Construct first, then call new CoreBotCommands. This is the recommended approach in both Effective Java and in Java Concurrency In Practice.
public static create(ChatInterface interface) { DefaultBot bot = new DefaultBot(interface); new CoreBotCommands(chatInterface, this).allCommands().forEach(bot::subscribe); }
Posting the answer that is discussed in the comments section of the question.
This solution worked for me! Thanks Andrew Logvinov
cleanupDaemonThreads = false
Something like this in the configuration tag
<configuration>
<mainClass>com.test.Startup</mainClass>
<cleanupDaemonTh...
> Injected TestingChatInterface to JavaBot's Program, fixes #14 - TestProgram is no more needed - Main now has the responsibilities, that used to be excess in TestProgram - Reconfigured Maven to not try and clean daemon threads to allow proper execution over maven exec-plugin - Made Gui shut down the JavaFX-thread when getting the PoisonPill
> Cleaned Up Program, removed System.exit(), see #34
- Main now also uses spaces for padding - Main is now responsible for wiring commands to the bot. - Any bot extending AbstractBot can now be shut down by enqueuing a Poison-Pill to them - Default Bot logger made static - Made Program less brittle on startup for JavaDocAccessor - Allowed Injecting ChatInterface to Program via Constructor - Moved shutdown Command to CoreBotCommands - Exposed querying thread ExecutorService from Program - Pro...
gram also holds the Poison-Pill - Removed System.exit from shutdown command - Exposed Bot instance from Program
> Added proper shutdown mechanisms for classes extending AbstractBot, see #39 - Removed executor shutdowns in #finalize() - Added protected #shutdown() method to AbstractBot that allows extending classes to clean up threads they introduce themselves
> Message Querying Thread now is a daemon thread, see #39 - Main is now responsible for firing up a Thread responsible for querying - Removed executor from Program - Added Logger to Main - Removed superfluous shutdown call in createShutdownCommand()
> Removed logging in from Program's responsibility - Extracted "safe" message querying to it's own method - Made use of ChatInterface's AutoCloseable to handle resources - Added clarifying javadoc to what assumptions are made about the chatInterface's state when it's passed to Program
> Wait, just discovered a problem. Considering that we're using .replace() method which replaces all occurrences of a literal sequence, wouldn't this tear away parts of the message if it includes the trigger as well? !!h!!i -> hi - I think we need replaceFirst.
> @mangstadt Yeah but you're still using .replaceAll, it's that bit simpler to use .replaceFirst, as it tells the regex engine to just replace first and not to keep trying (which always fails for the second attempt).
I did talk to Jay about some of the new things we've been working on. He said he has some great ideas he'd like to see, gameplay-wise... so I told him "Then get in the freaking chatroom and talk about it dude!"
3
During the day he's usually busy playing Call of Duty watching the kids
He works at night and when he's around nobody else really is
He's into YGO so he's used to really unusual and complex gameplay mechanics
Card combos and conditionals and things like that... "To play this card you must already have card X and card Y in play. When you play this card, if opponent has card Z in play then steal it."
Don't know if I want to get that complex, personally ;D
Awesome. We'll have to spend some time playing around with the new cards with effects to see how the gameplay changes, and what kind of spells and other effects/cards could make things interesting!
@Phrancis yes, I hope that although implementing new features is extremely hard for you, I think you should be able to make slight modifications to the existing features, such as adding ranged to a creature, or adding changing a spell's damage effect from 1 to 2, etc.
I'm sure that will be the case @SimonAndréForsberg after I get through this book I'm hoping I can actually contribute to the code base and not just the website :)
I'll say, it's both a good and a bad thing that I've been so busy with music lately. As much as I like doing it, I would like to have time to really dig into code and become a real programmer
