Is there any way to enable an object sleep mode in minko with the bullet plugin?
I'm building an static tower of cubes and I want to demolish it throwing balls.
Until now I just have a tower that falls every time it's build.
Somebody knows if there is a way to use bullet's constrains with minko?
All the code have is in the following git repository: https://github.com/fedemarino31/leaptower.git
AFAIK Bullet's constraints are not implemented. Feel free to provide a pull request.
Related
I'm scripting custom event where main requirement is to kill bosses in certain time and I need to prevent potential cheaters from using teleport hack inside of instance. Is there any way how I can add the trash mobs requirement in effective way ? I was thinking if there is any grouped identifier for those mobs which I can add into quest req.
Also I thought about invisible triggers which players would need to pass to progress in quest.
Another much simpler idea is just to add specific loot in trash loot and make player loot it but that is very inefficient and not comfy for players so that would be very last solution.
I also liked the idea of gathering souls like in shadowmourne quest line but there is a need to apply debuff from players to mobs so they trigger count on mob kill. It seems most advanced and would fit the idea perfectly but I'm not sure if it is doable in some effective way.
Thanks for any replies
Allright so after some trial-error I managed to modify mod-autobalance so I apply aura effect on NPC stats update.
Fairly simple and now it allows me to add this aura to any mob I want for quest completion. And as quest completion requirement is set this NPC.
Im very new to Tm1 and have to implement a new function in my code.
Is there any way to undo your last action?
For better understanding ill write an example:
I have 8 different cubes and i will upload one after one.
If one cube is not able to be uploaded all the others shouldnt be uploaded too.
Every cube which is already being uploaded should get a reset to the previous state.
Is there a way to implement it?
You have to inbriquate your 8 loading process in a master (others are slaves). If you have a condition that make one or your cube unuploadable you use the ProcessError function. In the master process, you fetch the result of the execution of each slave process. If one is in error, you use the processerror function (in the master). All the chain won't be commited.
The answer above from Wuzardor provides an approach using TI processes but your question seems to suggest you're using TM1py/Python to do the upload to TM1, either directly, or by triggering TI processes through the REST API.
In general, there's no easy way to roll back changes to cube data. However, it should be simple enough to structure your Python code such that the existence and validity of all the load files is established before you push anything to any of your cubes. It's difficult to suggest the best approach without more details about what you're trying to achieve and how.
Updated in response to OP comment:
OK, while it's not clear what IT isn't cooperating with, but if you are unable to verify the source prior to extracting it, you can always load it first to a staging cube, where the data can be checked, before copying anything to your main cubes. Depending on what issues you tend to face with the data, you might be able to automate this check or might need to rely on a human looking at it. Either way, just don´t overwrite your historic data until you've checked the new data.
Furthermore, you might want to think about your overall design. Might it make sense to retain a copy of the previous data in the cubes anyway? Why not build your cubes such that you can keep the history, rather than re-overwriting each time? Finding a sensible design really depends on the details of your application but you might benefit from looking at it with fresh eyes.
Cheers
Alex
How can I bind an issue to another issue, such that it will trigger the other issue to do something?
In the upper example, when "explicit device" issue is moved to "finished" column, I want the "error handling"(leftmost) issue to move to "in progress" column automatically. Because I may not remember which needs what and what was which, needing to check all issues whenever an issue is finished and would become tiring after some point.
Even better, building an issue tree, finishing from ground up without stopping by all issues for just finding the closest root of an issue, isn't an option?
Another example:
add method is written: "issue1" complete
multiply method is written: "issue2" complete
suddenly, a multiply-add method as "issue3" pops in the beginning column or if it is already there, it moves to right by 1 column.
The notion of project board presented in GitHub Universe 2016 is still lacking in term of fine-grained issue management.
That is why you have so many third-party integrations, including ZenHub (free for small teams and public account), which does have more features.
The point is: look for third-party integration (with a free offer) for your feature.
My first question =). I'm writing a video game with a user interface written in JavaFx. The behavior is correct, but I'm having performance problems. I'm trying to figure out how to figure out what is queuing up the refreshes which are slowing down the app.
I've got a relatively complex Scene Graph that represents a hexagonal map. It scales so that you could have 100 or a 1000 hexagons in the map. As the number of hexagons grow the responsiveness of the gui decreases. I've used YourKit (a Java Profiler) to trace these delays to major redraw operations.
I've spent most of the night trying to figure out how to do two things and understand one thing:
1) Cause a CustomNode to print something to the console whenever it is painted. This would help me identify exactly when these paints are being queued.
2) Identify when a CustomNode is put on the repaint queued.
If I answered 1 and 2, I might be able to figure out what it is that is binding all these different nodes together. Is it possible that JavaFX only works through global refreshes (doubtful)?
JavaFX script is a powerful UI language but certain practices will kill performance. Best performance generally boils down to:
keeping the Scene Graph small
keeping use of bind to a minimum (you can look at using triggers instead which are more performant)
This blog post by Jim Weaver expands these points.
I'm not sure as to the specific answers to your questions. If you examine the 1.2.1 docs you might be able to find a point in the Node documentation that you can override and add println statements but I'm not sure it can be done. You could try posting on forums.sun.com
This is a partial post. I expect to expand it after I've done some more work. I wanted to put in what I've done to date so I don't forget.
I realized that I'd need to get my IDE running with a full compliment of the JavaFx 1.2 source. This would allow me to put break points into the core code to figure out what is going on. I decided to do this configuration on Eclipse for remote debugging. I'm developing my FX in Netbeans but am more comfortable with Eclipse so that's what I want to debug in if I can.
To get this info into Eclipse, I first made a project with the Java source that my code uses. I then added external Jars to the project. On my Mac, the Jars I linked to were in /Library/Frameworks/JavaFX.framework/Versions/1.2
Then I went searching for the Source to link to these Jars. Unfortunately, it's not available. I could find some of it in /Library/Frameworks/JavaFX.framework/Versions/1.2/src.zip.
I did some research and found that the only available option left was to install a Java Decompilier. I used this one because it was easy to install into Eclipse 3.4: http colon_ //java dot decompiler _dot free.fr/ (<-- Please forgive the psudo link, I'm limited because I'm new)
This is where I am now. I can navigate into the Core FX classes and believe I'll be able to set break points and begin real analysis. I'll update this post as I progress.
I found a helpful benchmarking tool:
If you run with the JVM arg:
-Djava.util.logging.config.file=/path/to/logging/file/logging.properties
And you've put the following args into the file referenced by that arg:
handlers = java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level = ALL
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
com.sun.scenario.animation.fps.level = ALL
You'll get console output that includes your frame count per second. For FX 1.2 it wasn't working for me, but it appears to be working for 1.2.1 (which was released Sept. 9, 2009.) I don't have a Netbeans that runs 1.2.1 yet.
You may want to read this article.
http://fxexperience.com/2009/09/performance-improving-insertion-times/
Basically, insertions in to the scenegraph are slow and benefits can be seen by batching up inserts
Imagine you are implementing the user story containing various new features and adding complexity to the code base. The existing code is quite well covered and you have just decided upon interfaces. You are starting to implement the functionality starting with tests.
Now you have fairly complex test cases based on the requirements but the implementation is nowhere near the point when you are able to commit to the SCM fully working code and many test are failing (as they should).
There is an assumption that in continuous integration all builds should be green if possible and thus you shouldn't commit as you would break the build. But you also shouldn't "Go dark" and keep such amount of code for yourself...
What is the suggested procedure in such situation?
Do not decide on all interfaces beforehand. Develop incrementally in a typical TDD rhythm: write a test; make the test pass; refactor. That should keep everything in good shape, the bar will always be green and you can check code in without worrying that you will break the build.
It requires a different style of writing code, but you will get used to the rhythm eventually.
What about skipping those tests that you know won't pass because the functionality is currently missing?
Make it obvious that you are skipping the tests too! Really make it scream "like a stuck pig", as they say in Oz! (-:
As you add functionality, enable the associated tests and keep "your bar green!"
Here's another great article over at The Pragmatic Programmers that covers making broken windows obvious to others.
HTH
cheers,
Rob