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.
Related
This is my first question ever posted, so please let me know if there is anything that needs changes in my post :)
I am currently working on a dialog that is supposed to let the user change the background-color for some signal plotting. The "wxColourPickerCtrl" seems to do exactly what I need. Since there are multiple plots/pictures to be manipulated, the ColourPickerCtrls are initialized in a loop with the chosen background color as the default value:
for (const auto& [signalName, signalProperties] : properties)
{
wxColourPickerCtrl* selectBackgroundColor = new wxColourPickerCtrl(this, signalProperties.first, signalProperties.second.backgroundColor, wxDefaultPosition, wxDefaultSize);
}
"this" is an object of type SignalPropertiesDialog, which is directly inherited from wxDialog.
I have left out all the necessary sizer stuff, since it's not relevant for the problem (at least imo). "properties" is structured as follows:
std::map<std::string, std::pair<int, GraphPicture::Properties>> signalProperties_;
where GraphPicture::Properties contains the properties I want to manipulate:
struct Properties
{
wxColour backgroundColor{ *wxWHITE };
wxColour lineColor{ *wxBLACK };
int linewidth_px{ 1 };
bool isShown{ true };
};
The application successfully builds but immediately crashes on startup while generating those color picker objects.
wxIshiko has uploaded multiple tutorials and code snippets as examples for various wxWidgets controls, including the wxColourPickerCtrl. So I downloaded the sample code and tried to run it. Surprisingly, it worked.
While running through the code step by step I noticed the following difference:
The wxColourPickerCtrl is based on wxPickerBase. The wxPickerBase is created by calling the constructor of wxColourPickerCtrl (what I am actually doing in my code). During the construction of the wxPickerBase, the desired color is called by the name wxColourDataBase::FindName(const wxColour& color) const where the wxColourBase itself is instantiated. This is where the difference is:
When running the code snippet by wxIshiko, wxColourDataBase is instantiated correctly including the member m_map of type wxStringToColourHashMap* which is set to be NULL.
When running the code written by myself, wxColourDataBase is not correctly instantiated, and thus the member m_map is not set to be NULL, which leads to to the crash.
I have the feeling that there is nothing wrong with the way I set up the wxColourPickerCtrls. I somehow think there is a difference in the solution properties of the projects. I checked those but was not able to find any relevant differences.
I would really appreciate any hint or help since I am completely stuck on that problem.
Thank you very much in advance and have a good one,
Alex
EDIT:
I attached a screeny of the call stack.
Call stack
When does this code run exactly? If it is done after the library initialization (which would be the case, for example, for any code executed in your overridden wxApp::OnInit()), then wxTheColourDatabase really should be already initialized and what you observe should be impossible, i.e. if it happens it means that something is seriously wrong with your library build (e.g. it doesn't match the compiler options used when compiling your applications).
As always with such "impossible" bugs, starting with a known working code and doing bisection by copying parts of your code into the working version until it stops working will usually end up by finding a bug in your code.
This is my code in order to get the name of the item which has been selected in my CListViewCtrl:
LVITEM item = { LVIF_PARAM };
CString itemText;
clistViewCtrl.GetSelectedItem(&item);
clistViewCtrl.GetItemText(item.iItem, item.iSubItem, itemText);
Note that this code is working. I recently did another project, where I grabbed the name in exactly this way, however, I had no problems there with any assertion fails.
When I execute this with my current project, I always get a debug assertion:
"File: ... atlctrls.h"
Line: 3242
Expression: (GetStyle() & 0x0004) != 0
Even though the expression already states it pretty much, here is the line causing the failure:
ATLASSERT((GetStyle() & LVS_SINGLESEL) != 0);
I have barely any idea what the problem is. As I said, the exact same code worked on my other project, and I just went through both, trying to find any differences which could cause this behaviour, but nothing caught my eye.
Honestly, I don't even know if this is related to my code at all, considering the two compared elements seem to be predefined.
My first guess would have been that this part is being called before the items are created, but all items in the listview are created at the point I try to call this code passage.
Can anyone point me to a solution?
Your control is not created with style flag LVS_SINGLESEL. So calling GetSelectedItem is causing an assert. In case of multi selection use GetFirstSelectedItem and GetNextSelectedItem instead of GetSelectedItem. For single selection you can continue useing GetSelectedItem, but you have to add LVS_SINGLESEL style flag to your control.
Why is this test causing the following failure and error?
expected 'NO. ONE' to equal 'ITEM TWO'
<unknown> at /swiper-slider/test/basic-test.html:59
Object.Fake.downAt at /polymer-gestures/test/js/fake.js:98
Object.Fake.downOnNode at /polymer-gestures/test/js/fake.js:89
Context.<anonymous> at /swiper-slider/test/basic-test.html:56
polymer-gestures/test/js/fake.js is failing to find the target in this method, called from this method but I can't narrow down the exact culprit.
My hunch is that it has something to do with the div.swiper-button-next element being appended as a child on the fly and use of document.querySelector('swiper-slider /deep/ div.swiper-button-next') in the test.
I have a hunch that one of a few things is happening.
the div.swiper-button-next isn't in the DOM by the time you make the call. Either work a callback into your system to fire when everything is done (then check the value inside that callback), or (just to test if this is actually the problem) put a manual setTimeout to delay the query selector and assertion for a bit.
Polymer's targetAt function uses elementFromPoint() internally. Double check to make sure you don't have any overlays (core-overlay tends to crap all over my window sometimes...) and that the element you really want to tap is actually the element being found. Don't be afraid to put some debugging/console.log statements into the actual polymer source code to see what it is finding there.
I haven't spent too much time looking over the test, but your slideEls[1] could possibly have changed since you queried for it. querySelectorAll returns a "non-live" nodelist, so changes to the DOM don't update your selection.
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.
So I'm trying to make use of a GtkSourceView in C++ using GtkSourceViewmm, whose documentation and level of support give me the impression that it hasn't been very carefully looked at in a long time. But I'm always an optimist :)
I'm trying to add a SourceView using some code similar to the following:
Glib::RefPtr<gtksourceview::SourceLanguageManager> source_language_manager = gtksourceview::SourceLanguageManager::create();
Glib::RefPtr<gtksourceview::SourceLanguage> source_language = Glib::wrap(gtk_source_language_manager_guess_language(source_language_manager->gobj(), file, NULL));
Glib::RefPtr<gtksourceview::SourceBuffer> source_buffer = gtksourceview::SourceBuffer::create(source_language);
gtksourceview::SourceView* = m_source_view = new gtksourceview::SourceView(source_buffer);
m_vbox.pack_start(*m_source_view);
Unfortunately, it spits out the warning
(algoviz:4992): glibmm-WARNING **:
Failed to wrap object of type
'GtkSourceLanguage'. Hint: this error
is commonly caused by failing to call
a library init() function.
and when I look at it in a debugger, indeed the second line above (the one with the Glib::wrap()) is returning NULL. I have no idea why this is, but I tried to heed the warning by adding Glib::init() to the begining of the program, but that didn't seem to help at all either.
I've tried Google'ing around, but have been unsuccessful. Does anyone know what Glib wants me to init in order to be able to make that wrap call? Or, even better, does anyone know of any working sample code that uses GtkSourceViewmm (not just regular GtkSourceView)? I haven't been able to find any actual sample code, not even on Google Code Search.
Thanks!
It turns out, perhaps not surprisingly, that what I needed to init was:
gtksourceview::init();
After this, I ran into another problem with one of the parameter to gtksourceview::SourceLanguageManager, but this was caused by a genuine bug which I subsequently reported and was promptly fixed. So everything's working great now!
I use gtkmm. Typically you have to initialize things with something like :
_GTKMain = new Gtk::Main(0, 0, false);
Of course do not forget :
delete _GTKMain;
Check here for details :
http://library.gnome.org/devel/gtkmm/2.19/classGtk_1_1Main.html
(Sorry but the link option does not work ...)