I am using a vtkResliceCursorWidget in a VTK app, and I want setup a useful behavior: when I move a side (axe), I want to being moved both axes.
See the images from below:
Actual behavior:
Desired behavior:
I have found inside of vtkResliceCursorWidget representation, a method that fit my needs:
SetManipulationMode(vtkResliceCursorRepresentation::RotateBothAxes)
but the issue is that though I have used, it simply do nothing:
vtkResliceCursorRepresentation* pRep = reinterpret_cast<vtkResliceCursorRepresentation*>(resliceCursorWidget[1]->GetRepresentation());
pRep->SetManipulationMode(vtkResliceCursorRepresentation::RotateBothAxes);
where resliceCursorWidget is a vtkResliceCursorWidget, taken from here:
Example
Somwhow I expect of this, because on SetManipulation method remark write quite clear: "INTERNAL - Do not use Set the manipulation mode. This is done by the widget", even this method is a "public" method.
Could you guide me in order to able to move both axes (of vtkResliceCursorWidget) on the same time ?
Thank you.
With the CTRL key as modifier, the behaviour will be as desired.
Related
To fix the Gruul script, I need to immobilize the boss in an already existing event and remove that flag in another.
However, I can't find a way to prevent Gruul from chasing his target.
I tried comparing it to permanently snared bosses like Ragnaros and C'thun without finding a flag which fits my intentions.
Any hint, how to temporarily prevent movement is appreciated.
I am working on https://github.com/azerothcore/azerothcore-wotlk/blob/master/src/server/scripts/Outland/GruulsLair/boss_gruul.cpp
I want to add code which immobilizes Gruul while casting "Ground Slam" until he casts "Shatter" to make it blizzlike.
In detail
https://github.com/azerothcore/azerothcore-wotlk/blob/389227e4f7ea75292549a36d4f288cc2467d1078/src/server/scripts/Outland/GruulsLair/boss_gruul.cpp#L119
this event needs to immobilize him and this one https://github.com/azerothcore/azerothcore-wotlk/blob/389227e4f7ea75292549a36d4f288cc2467d1078/src/server/scripts/Outland/GruulsLair/boss_gruul.cpp#L126
should make him move again.
I've been looking through the Wiki, trying various flags to no avail. Thankfully i got some replies on discord which suggested UNIT_FLAG_PACIFIED (which prevents attacks but does not immobilize from my tests) and UNIT_FLAG_STUNNED (which prevents the "Ground Slam" cast from being finished but does not prevent Gruuls movement either.
To achieve the above, i used this syntax, adding the 4 lines setting/removing flags:
case EVENT_GROUND_SLAM:
Talk(SAY_SLAM);
me->CastSpell(me, SPELL_GROUND_SLAM, false);
events.DelayEvents(8001);
events.ScheduleEvent(EVENT_GROUND_SLAM, 60000);
events.ScheduleEvent(EVENT_SHATTER, 8000);
me->SetFlag(UNIT_FIELD_FLAGS, UNIT_FLAG_PACIFIED);
me->SetFlag(UNIT_FIELD_FLAGS, UNIT_FLAG_STUNNED);
break;
case EVENT_SHATTER:
Talk(SAY_SHATTER);
me->RemoveFlag(UNIT_FIELD_FLAGS, UNIT_FLAG_PACIFIED);
me->RemoveFlag(UNIT_FIELD_FLAGS, UNIT_FLAG_STUNNED);
me->CastSpell(me, SPELL_SHATTER, false);
break;
This code makes the boss (here: Gruul) stay in place.
me->SetControlled(true, UNIT_STATE_ROOT);
Setting the first argument to false removes the root.
Thanks to Yehonal on discord for pointing this out.
Let me elaborate on the title:
I want to implement a system that would allow me to enable/disable/modify the general behavior of my program. Here are some examples:
I could switch off and on logging
I could change if my graphing program should use floating or pixel coordinates
I could change if my calculations should be based upon some method or some other method
I could enable/disable certain aspects like maybe a extension api
I could enable/disable some basic integrated profiler (if I had one)
These are some made-up examples.
Now I want to know what the most common solution for this sort of thing is.
I could imagine this working with some sort of singelton class that gets instanced globally or in some other globally available object. Another thing that would be possible would be just constexpr or other variables floating around in a namespace, again globally.
However doing something like that, globally, feels like bad practise.
second part of the question
This might sound like I cant decide what I want, but I want a way to modify all these switches/flags or whatever they are actually called in a single location, without tying any of my classes to it. I don't know if this is possible however.
Why don't I want to do that? Well I like to make my classes somewhat reusable and I don't like tying classes together, unless its required by the DRY principle and or inheritance. I basically couldn't get rid of the flags without modifying the possible hundreds of classes that used them.
What I have tried in the past
Having it all as compiler defines. This worked reasonably well, however I didnt like that I couldnt make it so if the flag file was gone there were some sort of default settings that would make the classes themselves still operational and changeable (through these default values)
Having it as a class and instancing it globally (system class). Worked ok, however I didnt like instancing anything globally. Also same problem as above
Instancing the system class locally and passing it to the classes on construction. This was kinda cool, since I could make multiple instruction sets. However at the same time that kinda ruined the point since it would lead to things that needed to have one flag set the same to have them set differently and therefore failing to properly work together. Also passing it on every construction was a pain.
A static class. This one worked ok for the longest time, however there is still the problem when there are missing dependencies.
Summary
Basically I am looking for a way to have a single "place" where I can mess with some values (bools, floats etc.) and that will change the behaviour of all classes using them for whatever, where said values either overwrite default values or get replaced by default values if said "place" isnt defined.
If a Singleton class does not work for you , maybe using a DI container may fit in your third approach? It may help with the construction and make the code more testable.
There are some DI frameworks for c++, like https://github.com/google/fruit/wiki or https://github.com/boost-experimental/di which you can use.
If you decide to use switch/flags, pay attention for "cyclometric complexity".
If you do not change the skeleton of your algorithm but only his behaviour according to the objets in parameter, have a look at "template design pattern". This method allow you to define a generic algorithm and specify particular step for a particular situation.
Here's an approach I found useful; I don't know if it's what you're looking for, but maybe it will give you some ideas.
First, I created a BehaviorFlags.h file that declares the following function:
// Returns true iff the given feature/behavior flag was specified for us to use
bool IsBehaviorFlagEnabled(const char * flagName);
The idea being that any code in any of your classes could call this function to find out if a particular behavior should be enabled or not. For example, you might put this code at the top of your ExtensionsAPI.cpp file:
#include "BehaviorFlags.h"
static const enableExtensionAPI = IsBehaviorFlagEnabled("enable_extensions_api");
[...]
void DoTheExtensionsAPIStuff()
{
if (enableExtensionsAPI == false) return;
[... otherwise do the extensions API stuff ...]
}
Note that the IsBehaviorFlagEnabled() call is only executed once at program startup, for best run-time efficiency; but you also have the option of calling IsBehaviorFlagEnabled() on every call to DoTheExtensionsAPIStuff(), if run-time efficiency is less important that being able to change your program's behavior without having to restart your program.
As far as how the IsBehaviorFlagEnabled() function itself is implemented, it looks something like this (simplified version for demonstration purposes):
bool IsBehaviorFlagEnabled(const char * fileName)
{
// Note: a real implementation would find the user's home directory
// using the proper API and not just rely on ~ to expand to the home-dir path
std::string filePath = "~/MyProgram_Settings/";
filePath += fileName;
FILE * fpIn = fopen(filePath.c_str(), "r"); // i.e. does the file exist?
bool ret = (fpIn != NULL);
fclose(fpIn);
return ret;
}
The idea being that if you want to change your program's behavior, you can do so by creating a file (or folder) in the ~/MyProgram_Settings directory with the appropriate name. E.g. if you want to enable your Extensions API, you could just do a
touch ~/MyProgram_Settings/enable_extensions_api
... and then re-start your program, and now IsBehaviorFlagEnabled("enable_extensions_api") returns true and so your Extensions API is enabled.
The benefits I see of doing it this way (as opposed to parsing a .ini file at startup or something like that) are:
There's no need to modify any "central header file" or "registry file" every time you add a new behavior-flag.
You don't have to put a ParseINIFile() function at the top of main() in order for your flags-functionality to work correctly.
You don't have to use a text editor or memorize a .ini syntax to change the program's behavior
In a pinch (e.g. no shell access) you can create/remove settings simply using the "New Folder" and "Delete" functionality of the desktop's window manager.
The settings are persistent across runs of the program (i.e. no need to specify the same command line arguments every time)
The settings are persistent across reboots of the computer
The flags can be easily modified by a script (via e.g. touch ~/MyProgram_Settings/blah or rm -f ~/MyProgram_Settings/blah) -- much easier than getting a shell script to correctly modify a .ini file
If you have code in multiple different .cpp files that needs to be controlled by the same flag-file, you can just call IsBehaviorFlagEnabled("that_file") from each of them; no need to have every call site refer to the same global boolean variable if you don't want them to.
Extra credit: If you're using a bug-tracker and therefore have bug/feature ticket numbers assigned to various issues, you can creep the elegance a little bit further by also adding a class like this one:
/** This class encapsulates a feature that can be selectively disabled/enabled by putting an
* "enable_behavior_xxxx" or "disable_behavior_xxxx" file into the ~/MyProgram_Settings folder.
*/
class ConditionalBehavior
{
public:
/** Constructor.
* #param bugNumber Bug-Tracker ID number associated with this bug/feature.
* #param defaultState If true, this beheavior will be enabled by default (i.e. if no corresponding
* file exists in ~/MyProgram_Settings). If false, it will be disabled by default.
* #param switchAtVersion If specified, this feature's default-enabled state will be inverted if
* GetMyProgramVersion() returns any version number greater than this.
*/
ConditionalBehavior(int bugNumber, bool defaultState, int switchAtVersion = -1)
{
if ((switchAtVersion >= 0)&&(GetMyProgramVersion() >= switchAtVersion)) _enabled = !_enabled;
std::string fn = defaultState ? "disable" : "enable";
fn += "_behavior_";
fn += to_string(bugNumber);
if ((IsBehaviorFlagEnabled(fn))
||(IsBehaviorFlagEnabled("enable_everything")))
{
_enabled = !_enabled;
printf("Note: %s Behavior #%i\n", _enabled?"Enabling":"Disabling", bugNumber);
}
}
/** Returns true iff this feature should be enabled. */
bool IsEnabled() const {return _enabled;}
private:
bool _enabled;
};
Then, in your ExtensionsAPI.cpp file, you might have something like this:
// Extensions API feature is tracker #4321; disabled by default for now
// but you can try it out via "touch ~/MyProgram_Settings/enable_feature_4321"
static const ConditionalBehavior _feature4321(4321, false);
// Also tracker #4222 is now enabled-by-default, but you can disable
// it manually via "touch ~/MyProgram_Settings/disable_feature_4222"
static const ConditionalBehavior _feature4222(4222, true);
[...]
void DoTheExtensionsAPIStuff()
{
if (_feature4321.IsEnabled() == false) return;
[... otherwise do the extensions API stuff ...]
}
... or if you know that you are planning to make your Extensions API enabled-by-default starting with version 4500 of your program, you can set it so that Extensions API will be enabled-by-default only if GetMyProgramVersion() returns 4500 or greater:
static ConditionalBehavior _feature4321(4321, false, 4500);
[...]
... also, if you wanted to get more elaborate, the API could be extended so that IsBehaviorFlagEnabled() can optionally return a string to the caller containing the contents of the file it found (if any), so that you could do shell commands like:
echo "opengl" > ~/MyProgram_Settings/graphics_renderer
... to tell your program to use OpenGL for its 3D graphics, or etc:
// In Renderer.cpp
std::string rendererType;
if (IsDebugFlagEnabled("graphics_renderer", &rendererType))
{
printf("The user wants me to use [%s] for rendering 3D graphics!\n", rendererType.c_str());
}
else printf("The user didn't specify what renderer to use.\n");
I am reading doc of cocos2dx on Actions (link: http://www.cocos2d-x.org/wiki/Actions). They mention reverse function on sequences and spawns at the bottom.
I am just a little confused what difference would reverse make on spawns, since according to what I understand spawns in cocos2d corporate actions together and make them happen at the same time? If this is true reverse would make almost no variations to spawns, at least visually? There is one (potential) line of explanation in the doc says "However it is not just
simply running in reverse. It is actually manipulating the properties of the original Sequence or Spawn in reverse too." Is it because of this "properties" that there is really some difference, probably somewhere in bottom level? Can someone explain this?
I don't think Spawn::reverse() is special. One thing I like Cocos2d-x is that I can see the source code by clicking F12.
Spawn* Spawn::reverse() const
{
return Spawn::createWithTwoActions(_one->reverse(), _two->reverse());
}
//Definition of Spawn
Spawn{
//...
protected:
//FiniteTimeAction is a derived class of Action
FiniteTimeAction *_one;
FiniteTimeAction *_two;
private:
CC_DISALLOW_COPY_AND_ASSIGN(Spawn);
};
Yes, the reverse will not make any visible visually as it will be reversing every action and there will be no movement.As I am giving an example of jumpBy and reversing the jumps of the sprite using a sequence.
auto jump = JumpBy::create(3,Vec2(100, 0),50,3);
auto jumpBack = jump->reverse();
sceneSprite->runAction(Sequence::create(jump,jumpBack, nullptr));
I am not sure how you are supposed to control a player character in Bullet. The methods that I read were to use the provided btKinematicCharacterController. I also saw methods that use btDynamicCharacterController from the demos. However, in the manual it is stated that kinematic controller has several outstanding issues. Is this still the preferred path? If so, are there any tutorials or documentations for this? All I found are snippets of code from the demo, and the usage of controllers with Ogre, which I do not use.
If this is not the path that should be tread, then someone point me to the correct solution. I am new to bullet and would like a straightforward, easy solution. What I currently have is hacked together bits of a btKinematicCharacterController.
This is the code I used to set up the controller:
playerShape = new btCapsuleShape(0.25, 1);
ghostObject= new btPairCachingGhostObject();
ghostObject->setWorldTransform(btTransform(btQuaternion(0,0,0,1),btVector3(0,20,0)));
physics.getWorld()->getPairCache()->setInternalGhostPairCallback(new btGhostPairCallback());
ghostObject->setCollisionShape(playerShape);
ghostObject->setCollisionFlags(btCollisionObject::CF_CHARACTER_OBJECT);
controller = new btKinematicCharacterController(ghostObject,playerShape,0.5);
physics.getWorld()->addCollisionObject(ghostObject,btBroadphaseProxy::CharacterFilter, btBroadphaseProxy::StaticFilter|btBroadphaseProxy::DefaultFilter);
physics.getWorld()->addAction(controller);
This is the code I use to access the controller's position:
trans = controller->getGhostObject()->getWorldTransform();
camPosition.z = trans.getOrigin().z();
camPosition.y = trans.getOrigin().y()+0.5;
camPosition.x = trans.getOrigin().x();
The way I control it is through setWalkDirection() and jump() (if canJump() is true).
The issue right now is that the character spazzes out a little, then drops through the static floor. Clearly this is not intended. Is this due to the lack of a rigid body? How does one integrate that?
Actually, now it just falls as it should, but then slowly sinks through the floor.
I have moved this line to be right after the dynamic world is created
physics.getWorld()->getPairCache()->setInternalGhostPairCallback(new btGhostPairCallback());
It is now this:
broadphase->getOverlappingPairCache()->setInternalGhostPairCallback(new btGhostPairCallback());
I am also using a .bullet file imported from blender, if that is relevant.
The issue was with the bullet file, which has since been fixed(the collision boxes weren't working). However, I still experience jitteryness, unable to step up occasionally, instant step down from to high a height, and other issues.
My answer to this question here tells you what worked well for me and apparently also for the person who asked.
Avoid ground collision with Bullet
The character controller implementations in bullet are very "basic" unfortunately.
To get good character controller, you'll need to invest this much.
I'm using a simple numeric text validator wxTextValidator along with a wxTextControl. I wonder what the 2nd parameter is good for:
wxTextValidator(long style = wxFILTER_NONE, wxString* valPtr = NULL)
I simply passed the reference to a member variable:
myTextControl_->SetValidator( wxTextValidator(wxFILTER_NUMERIC, &myValue_) );
I'm using wxWidgets 2.8.12, from the documentation I figured that the myValue_ variable would receive the validated content of the text control, but this does not happen in my application.
Am I doing something wrong or does the valPtr parameter not receive the content of the text control?
The myvalue_ variable should receive the value entered if you call wxValidator::Validate or wxValidator::TransferFromWindow. This happens automatically if you close the dialog with the default OnOK() handler. Otherwise you have to do it yourself.
Ravenspoint has already answered the initial question but I'd just like to add that wxValidator can be used either for validating or for data transfer -- or for both at once. In fact, some validators, such as wxGenericValidator are only used for data transfer (it doesn't make much sense to validate a check box or a radio button!). So the name of this class is somewhat misleading as it describes at most half, and probably less than that, of its uses.