_orm_

Members
  • Content count

    159
  • Joined

  • Last visited

Community Reputation

112 Neutral

About _orm_

  • Rank
    Member
  1. Monday morning code...

    nullptr is a C++11 keyword that is guaranteed to be null.
  2. The wrong object was an asIScriptObject, yes. It was just the wrong asIScriptObject. It's a bit hard to explain without studying my system, but I have been refactoring CollisionObjects to have their own core script objects to perform event callbacks on, where before they would obtain the callback object and call OnCollision on the core object of an Actor thwy would be attached to.
  3.    I believe I have figured out the problem. When I was setting the object while preparing to call, I was setting the wrong object, which given the design of my collision detection system is easy enough to do. I need to learn to keep my objects straight. This could lead to a bit of an enhancement. I find it odd that the program decided to crash there and not let me know "This object doesn't have that function stupid." 
  4. Just updated my code to the latest SVN of the library and it is crashing in the same spot. I'll try to get more info.
  5. I'll let the stacktrace speak for itself, but this is a pretty odd bug. I am using an outdated version of Angelscript, so I will see if using the latest SVN ffixes it, but here: [code]Program received signal SIGSEGV, Segmentation fault. 0x6523ecc3 in asCContext::ExecuteNext (this=0xbbd0fd8) at C:\mengin\src\deps\angelscript\as_context.cpp:1292 1292 switch( *(asBYTE*)l_bc ) (gdb) bt fuull No symbol "fuull" in current context. (gdb) bt full #0 0x6523ecc3 in asCContext::ExecuteNext (this=0xbbd0fd8) at C:\mengin\src\deps\angelscript\as_context.cpp:1292 l_bc = 0x0 l_sp = 0xbb2ba54 l_fp = 0xbb2ba54 #1 0x6523e424 in asCContext::Execute (this=0xbbd0fd8) at C:\mengin\src\deps\angelscript\as_context.cpp:985 No locals. #2 0x651289b7 in _fu121___ZSt4cout (this=0xbbbc6e8, act=0xba73608, collider=0xbbbc6e8) at C:\mengin\src\core\CollisionObject.cpp:346 r = 0 info = 0xc14d440 #3 0x651283e9 in Irre::CollisionObject::RunCollisionDetection (this=0xbbbc6e8) at C:\mengin\src\core\CollisionObject.cpp:308 pt = @0xb580d90 p = 0 manifold = 0xb580d8c objA = 0xbb29050 cooA = 0xbb28ab8 other_object = 0xbb28ab8 objB = 0xbbbc8c0 cooB = 0xbbbc6e8 directionSign = 1 j = 0 pair = @0x8b6e270 collisionPair = 0xbbf3b60 i = 0 manifoldArray = {m_allocator = {<No data fields>}, m_size = 1, m_capacity = 1, m_data = 0x8b7fc40, m_ownsMemory = true} pairArray = @0xbba58f4 numPairs = 4 #4 0x651136a8 in Irre::ObjectManager::PropagateOnCollide (this=0xbb23f48, a1=0x0, co1=0x0, a2=0x0, co2=0x0) at C:\mengin\src\core\ObjectManager.cpp:446 obj = 0xbbbc6e8 i = {<boost::iterator<std::forward_iterator_tag, std::pair<int const, Irre::Object*>, int, std::pair<int const, Irre::Object*>*, std::pair<int const, Irre::Object*>&>> = {<boost::detail::iterator_base<std::forward_iterator_tag, std::pair<int const, Irre::Object*>, int, std::pair<int const, Irre::Object*>*, std::pair<int const, Irre::Object*>&>> = {<std::iterator<std::forward_iterator_tag, std::pair<int const, Irre::Object*>, int, std::pair<int const, Irre::Object*>*, std::pair<int const, Irre::Object*>&>> = {<No data fields>}, <No data fields>}, <No data fields>}, base_ = {bucket_ = 0xba83b3c, node_ = 0xbbd5008}} #5 0x65123fcf in Irre::WorldTickCallback (world=0x8b5aed0, timestep=0.00416666688) at C:\mengin\src\physics\World.cpp:478 No locals. #6 0x651fcb9f in btDiscreteDynamicsWorld::internalSingleStepSimulation (this=0x8b5aed0, timeStep=0.00416666688) at C:\mengin\src\deps\bullet\BulletDynamics\Dynamics\btDiscreteDynamicsWorld.cpp:355 __profile = {<No data fields>} dispatchInfo = @0x8b5aeec #7 0x651fc9b1 in btDiscreteDynamicsWorld::stepSimulation (this=0x8b5aed0, timeStep=62, maxSubSteps=15, fixedTimeStep=0.00416666688) at C:\mengin\src\deps\bullet\BulletDynamics\Dynamics\btDiscreteDynamicsWorld.cpp:290 i = 0 clampedSimulationSteps = 15 __profile = {<No data fields>} numSimulationSubSteps = 14880 #8 0x651252ab in Irre::World::Update (this=0x8b4f478, delta=46) at C:\mengin\src\physics\World.cpp:566 elapsed = 62 substeps = 15 timestep = 0.0620000027 #9 0x651320a2 in Irre::Stage::Update (this=0x8aeacd0, time_delta=46) at C:\mengin\src\core\stage\StageAngel.cpp:409 No locals. #10 0x6510eb3b in Irre::LogicThread::SingleThreadRun (this=0x8aefd50) at C:\mengin\src\core\LogicThread.cpp:86 time_delta = 46 #11 0x651067cc in Irre::Engine::Run (this=0x4d9808) at C:\mengin\src\core\Engine.cpp:105 tid = 0 #12 0x65106980 in Irre::Run () at C:\mengin\src\core\Engine.cpp:165 No locals. #13 0x004013e5 in main (ac=1, av=0x4d44f0) at C:\mengin\src\runner\main.cpp:11 No locals.[/code] More on this as I find out.
  6. exceptions in agelscript

    [quote name='WitchLord' timestamp='1318382514' post='4871686'] [quote name='randomguy12345' timestamp='1318294706' post='4871283'] @ _orm_ : i am sorry if i asked many questions in a single day and that was inconvenient to you or anybody else. [/quote] I'm sure _orm_ was just joking. Feel free to post as much as you like. [/quote] Yep, just joking. Maybe I should have thrown in one of these? ->
  7. It actually seems to be a problem with handles being held in a value type. When I register the telegram as a reference type, the data remains intact.
  8. support for closure

    Looking at the links you provided, it does not seem like Angelscript supports closures natively. However, you could probably implement them yourself somehow. The language already supports function handles, which behave in a similar manner to C function pointers, but only for global functions at this time. Remember that whatever the language does not have you could always implement yourself without having to delve into the guts of the language yourself.
  9. ExecuteString in Object?

    Lol double posts. You could call a function by a string by going through the usual routine C++ side using the string you pass, but this could prove to be very slow when done in real time. If your C++ object holds a pointer to the angelscript object, then it is trivial to get the object pointer. Regardless, looking at the API it seems that you have to know the object pointer ahead of time.
  10. support for mixin

    Angelscript supports interfaces, which may provide the functionality you are looking for.
  11. exceptions in agelscript

    you know you could give yourself a hernia making threads this fast? You can, on the C++ side, set exceptions in the asIScriptContext and it will halt execution for you.
  12. [quote name='WitchLord' timestamp='1318171397' post='4870811'] Having random behaviour due to uninitialized memory is definitely bad. I'll see what I can do about this. However, I will not guarantee that uninitialized variables will always be cleared to 0 by default. This would require extensive changes and impact the performance quite a bit. Especially with loops, where the VM would have to repeatedly clear all memory on the stack for each iteration. [/quote] Loops aren't as much of a problem as much as member and global variables are, because those are the ones we actually work with the most. And if it would take too much time only to have performance take a hit, then I guess we could actually take what we learn from C and initialize our variables in the first place.
  13. Are the there any examples of this? I wanted to use it as a vehicle for user data for my messaging system, but the problem is that after it's gone between Angelscript to the C++ side, casting it back to toe required type in Angelscript results in a null pointer. Here is a basic overview of the system. [code] #pragma once #ifndef IR_MESSAGE_DISPATCHER_H #define IR_MESSAGE_DISPATCHER_H #include <set> #include "Object.h" #include "../script/angel/scripthandle.h" #undef DispatchMessage namespace Irre { struct Telegram { Telegram( double delay, asIScriptObject* sender, asIScriptObject* receiver, int message, CScriptHandle& data ) : Sender( sender ), Receiver( receiver ), Message( message ), DispatchTime( delay ), Data( data ) { Sender->AddRef(); Receiver->AddRef(); } ~Telegram() { Sender->Release(); Receiver->Release(); } asIScriptObject* Sender; asIScriptObject* Receiver; int Message; double DispatchTime; CScriptHandle Data; bool operator<=( const Telegram& other ) { return DispatchTime <= other.DispatchTime; } bool operator==( const Telegram& other ) { return DispatchTime == other.DispatchTime; } }; class MessageDispatcher { public: void TransmitMessage( double delay, Object* sender, Object* receiver, int msg, CScriptHandle& data ); void DispatchDelayedMessages(); private: void Discharge(Object* receiver,const Telegram& message); std::set<Telegram> m_DelayedTelegrams; }; } #endif #include "MessageDispatcher.h" #include "../shared/Global.h" #include "../script/angel/ScriptFunctions.h" #include "Stage.h" #include "ObjectManager.h" #include "Engine.h" namespace Irre { void MessageDispatcher::TransmitMessage( double delay, Object* sender, Object* receiver, int msg, CScriptHandle& data) { float current_time = IR_GetTick(); Telegram message(0,sender->m_Core,receiver->m_Core,msg,data ); if( delay == 0 ) Discharge( receiver, message ); } void MessageDispatcher::Discharge( Object* receiver,const Telegram& message ) { receiver->ReceiveMessage( message ); } void MessageDispatcher::DispatchDelayedMessages() { // Not implemented yet. } } [/code] [code] void RegisterDispatchMessage( asIScripeEngine* e ) { // Registering the global function. r=e->RegisterGlobalFunction("void IR_DispatchMessage(double,int,int,int,ref&in)", asFUNCTION(IR_DispatchMessage), asCALL_CDECL); AS_CHECK(r); } /* Dummy */ void TelegramDummy( Telegram* self ) { } void TelegramDestructor( Telegram* self ) { ((Telegram*)self)->~Telegram(); } void RegisterTelegram( asIScriptEngine* e ) { r=e->RegisterObjectType("Telegram",sizeof(Telegram),asOBJ_VALUE | asOBJ_POD | asOBJ_APP_CLASS_CD );AS_CHECK(r); r=e->RegisterObjectBehaviour("Telegram",asBEHAVE_CONSTRUCT,"void f()",asFUNCTION(TelegramDummy),asCALL_CDECL_OBJLAST);AS_CHECK(r); r=e->RegisterObjectBehaviour("Telegram",asBEHAVE_DESTRUCT,"void f()",asFUNCTION(TelegramDestructor),asCALL_CDECL_OBJLAST);AS_CHECK(r); r=e->RegisterObjectProperty("Telegram","IObject@ Sender",offsetof(Telegram,Sender)); r=e->RegisterObjectProperty("Telegram","IObject@ Receiver",offsetof(Telegram,Receiver)); r=e->RegisterObjectProperty("Telegram","int Message",offsetof(Telegram,Message)); r=e->RegisterObjectProperty("Telegram","double DispatchTime",offsetof(Telegram,DispatchTime)); r=e->RegisterObjectProperty("Telegram","ref@ Data",offsetof(Telegram,Data)); } [/code] [code] void OnMessageReceived( const Telegram&in message ) { switch( message.Message ) { case TA_Messages::BODY_WITHIN_RADAR_RANGE: { TA_Body@ sensed_body = cast<TA_Body@>(message.Data); // The data is null when it gets passed to IsFriendly. if( sensed_body is null ) Println("The sensed body was null for whatever reason."); if( !IsFriendly(sensed_body) && !IsDead ) { m_SensoryMemory.SaveMemoryEntry( TA_MemoryRecord(sensed_body.TA_Mind,sensed_body.Position) ); } } break; case TA_Messages::AGENT_ORDER_DROP_EVERYTHING: case TA_Messages::AGENT_ORDER_PATROL: case TA_Messages::AGENT_ORDER_WEAPONS_FREE: case TA_Messages::AGENT_ORDER_DEFEND: case TA_Messages::AGENT_ORDER_SEEK_AND_DESTROY: { DispatchMessage( 0,m_ThinkGoal,message.Message,message.Data ); } break; } [/code] By the way, I know for a fact that the data that gets passed to the telegram in the first place is guaranteed to not be null. And yes, I am well aware of interfaces and such, but I find messaging to be much more convenient than using interfaces for everything. I have also tried using a pointer to the CScriptHandle, but that eventually leads to either a segfault or an assertion.
  14. This behavior of Angelscript just bit me yet again, only this time it caused Bullet to crap itself. I have a double as a member variable that determines how much thrust is applied to an entity. However, because I left this value uninitialized in the base class, at random times I received the "Overflow in AABB" error, with no way to consistently reproduce the problem. It was actually a complete fluke that I discovered the source of the issue. These sorts of problems are one of the reasons that we use scripting languages. Therefore, I would like to recommend that primitive datatypes in Angelscript be initialized with a default value of 0 to mitigate these issues.
  15. True Variant Datatype

    I can't really think of anything, and I actually realized that variants are actually pretty silly and unnecessary in the scheme of things.