CATIA-CAA CATKeyboardEvent - c++

I know there are only a few CAA Programmers in the world but I try it anyway...
I can't get keyboard events to work. I found this code which looks reasonable but the Notification doesn't fire.
AddAnalyseNotificationCB(CATFrmLayout::GetCurrentLayout()->GetCurrentWindow()->GetViewer(),
CATKeyboardEvent::ClassName(),
(CATCommandMethod)&PROTrvTreeView::OnKeyboardEvent, NULL);
void PROTrvTreeView::OnKeyboardEvent(CATCommand * ipCmd, CATNotification * ipEvt, CATCommandClientData iobjData) {
cout<< "KeyboardEvent" <<endl;
}
Anyone any idea?

There is a much denser group of developers for CAA at:
http://www.3ds.com/alliances/c-java-developers/forum/
The same question came up, with several people mentioning that this API was unauthorized, and therefore you can't rely on it, even if it works.
The other samples there are essentially the same code as yours, but the only one that purports to work doesn't use CATKeyboardEvent::ClassName, but instead uses CATKeybdEvent. Might be worth a try.

Related

How to immobilize a mob in a script?

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.

Alternative of CreateVideoSource() in webrtc

Hi all I had seen one webrtc old source code which has this method called CreateVideoSource() for adding streams after an CreateAudioTrack() call.
rtc::scoped_refptr<webrtc::VideoTrackSourceInterface> video_source =
peer_connection_factory_->CreateVideoSource(std::unique_ptr<cricket::VideoCapturer>(
media_source->GetVideoCapturer()),
NULL);
What's happening is whenever I try to build it gives an error for the above CreateVideoSource() that it is undefined. And the reason behind that is the latest webrtc-checkout has deprecated this.
So my question is, I wanted to know the alternative which they have introduced after deprecating this method. So can anyone tell me what the alternate approach is.
Okay, Finally I was able to come up with an alternative(i.e the current implementation of libwebrtc) after looking into bundle examples and tests.
Line 71 is a good point to start

How do you control a player character in Bullet Physics?

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.

Unit testing - log and then fail?

I am used to test drive my code. Now that I am new to Go I am trying to get it right as fast as possible. I am using the testing package in the standard library which seem to be good enough. (I also like that it is not yet another external dependency. We are currently at 2 dependencies overall - compared to any Java- or Ruby project.....) Anyways - it looks like an assert in golang looks like this:
func TestSomething(t *testing.T) {
something := false
if something {
t.Log("Oh noes - something is false")
t.Fail()
}
}
I find this verbose and would like to do it on one line instead:
Assert( something, "Oh noes - something is false" )
or something like that. I hope that I have missed something obvious here. What is the best/idiomatic way to do it in go?
UPDATE: just to clarify. If I was to do something like this:
func AssertTrue(t *testing.T, value bool, message string) {
if value {
t.Log(message)
t.Fail()
}
}
and then write my test like this
func TestSomething(t *testing.T) {
something := false
AssertTrue(t, something, "Oh noes - something is false")
}
then it would not be the go way to do it?
There are external packages that can be integrated with the stock testing framework.
One of them I wrote long ago, gocheck, was intended to sort that kind of use case.
With it, the test case looks like this, for example:
func (s *Suite) TestFoo(c *gocheck.C) {
// If this succeeds the world is doomed.
c.Assert("line 1\nline 2", gocheck.Equals, "line 3")
}
You'd run that as usual, with go test, and the failure in that check would be reported as:
----------------------------------------------------------------------
FAIL: foo_test.go:34: Suite.TestFoo
all_test.go:34:
// If this succeeds the world is doomed.
c.Assert("line 1\nline 2", gocheck.Equals, "line 3")
... obtained string = "" +
... "line 1\n" +
... "line 2"
... expected string = "line 3"
Note how the comment right above the code was included in the reported failure.
There are also a number of other usual features, such as suite and test-specific set up and tear down routines, and so on. Please check out the web page for more details.
It's well maintained as I and other people use it in a number of active projects, so feel free to join on board, or follow up and check out the other similar projects that suit your taste more appropriately.
For examples of gocheck use, please have a look at packages such as mgo, goyaml, goamz, pipe, vclock, juju (massive code base), lpad, gozk, goetveld, tomb, etc. Also gocheck, manages to test itself. It was quite fun to bootstrap that.
But when You try write test like Uncle Martin, with one assert in test and long function names, then simple assert library, like http://github.com/stretchr/testify/assert can make it much faster and easier
I discourage writing test in the way you seem to have desire for. It's not by chance that the whole stdlib uses the, as you call it, "verbose" way.
It is undeniably more lines, but there are several advantages to this approach.
If you read Why does Go not have assertions? and s/error handling/test failure reporting/g you can get a picture of why the several "assert" packages for Go testing are not a good idea to use,
Once again, the proof is the huge code base of the stdlib.
The idiomatic way is the way you have above. Also, you don't have to log any message if you don't desire.
As defined by the GO FAQ:
Why does Go not have assertions?
Go doesn't provide assertions. They are undeniably convenient, but our
experience has been that programmers use them as a crutch to avoid
thinking about proper error handling and reporting. Proper error
handling means that servers continue operation after non-fatal errors
instead of crashing. Proper error reporting means that errors are
direct and to the point, saving the programmer from interpreting a
large crash trace. Precise errors are particularly important when the
programmer seeing the errors is not familiar with the code.
We understand that this is a point of contention. There are many
things in the Go language and libraries that differ from modern
practices, simply because we feel it's sometimes worth trying a
different approach.
UPDATE
Based on your update, that is not idiomatic Go. What you are doing is in essence designing a test extension framework to mirror what you get in the XUnit frameworks. While there is nothing fundamentally wrong, from an engineering perspective, it does raise questions as to the value + cost of maintaining this extension library. Additionally, you are creating an in-house standard that will potentially ruffle feathers. The biggest thing about Go is it is not C or Java or C++ or Python and things should be done the way the language is constructed.

Why using "SND_SYNC" in a "QueueUserWorkItem" bad?

Larry Osterman writes about a real error found in Microsoft's code, the offending code is
static DWORD WINAPI _PlayBeep(__in void* pv)
{
UNREFERENCED_PARAMETER(pv);
PlaySound(L".Default"NULL, SND_SYNC | SND_ALIAS);
return 0;
}
LRESULT WndProc(...)
{
:
:
case WM_KEYDOWN:
if (!_AcceptInputKeys(wParam, lParam))
{
QueueUserWorkItem(_PlayBeep, NULL, 0);
}
break;
}
and Larry asks:
Given the simplicity of the code
above, to get the answer right, it’s
not enough to say what’s wrong with
the code (the problem should be
blindingly obvious). You also need to
be able to explain why this is so bad
(in other words, what breaks when you
do this).
The best answer is terse in the comments is not enough,
David's VERY close to what's going
wrong - now think about the context of
the application.
Can someone please explain fully what's happening when this code runs?
Read the answer page, it's got a very detailed explanation
http://blogs.msdn.com/b/larryosterman/archive/2009/06/29/what-s-wrong-with-this-code-part-26-the-answer.aspx
Basically, don't use QueueUserWorkItem for long-running work items because this can cause thread exhaustion in your process, or even deadlock in a very hard to debug way if you wait for work items to complete on a (necessarily) finite-sized thread pool. Same goes for the .Net equivalent of this API ThreadPool.QueueUserWorkItem btw.
In this specific case, the workitem trigger ("press the down key") and the resulting thread workitem ("sound a sync beep") are very unbalanced, so that if user holds down or repeatedly hits his/her down key, the process will quickly hit fatal issues.