"Error LNK2019 and LNK2001 : unresolved external symbol" By adding an already existing weapon code in a project.

[Ozkii]

So i found a weapon src code and wanted to mix it up with Portal...Everything worked fine until at the end of the Rebuilding appears these:

 2>physicsshadowclone.obj : error LNK2019: unresolved external symbol "class CGrabController * __cdecl GetGrabControllerForPlayer(class CBasePlayer *)" (?GetGrabControllerForPlayer@@YAPAVCGrabController@@PAVCBasePlayer@@@Z) referenced in function "void __cdecl FullSyncPhysicsObject(class IPhysicsObject *,class IPhysicsObject *,class VMatrix const *,bool)" (?FullSyncPhysicsObject@@YAXPAVIPhysicsObject@@0PBVVMatrix@@_N@Z) 

 2>portal_physics_collisionevent.obj : error LNK2001: unresolved external symbol "class CGrabController * __cdecl GetGrabControllerForPlayer(class CBasePlayer *)" (?GetGrabControllerForPlayer@@YAPAVCGrabController@@PAVCBasePlayer@@@Z) 

 2>physicsshadowclone.obj : error LNK2019: unresolved external symbol "class CGrabController * __cdecl GetGrabControllerForPhysCannon(class CBaseCombatWeapon *)" (?GetGrabControllerForPhysCannon@@YAPAVCGrabController@@PAVCBaseCombatWeapon@@@Z) referenced in function "void __cdecl FullSyncPhysicsObject(class IPhysicsObject *,class IPhysicsObject *,class VMatrix const *,bool)" (?FullSyncPhysicsObject@@YAXPAVIPhysicsObject@@0PBVVMatrix@@_N@Z) 

 2>portal_physics_collisionevent.obj : error LNK2001: unresolved external symbol "class CGrabController * __cdecl GetGrabControllerForPhysCannon(class CBaseCombatWeapon *)" (?GetGrabControllerForPhysCannon@@YAPAVCGrabController@@PAVCBaseCombatWeapon@@@Z) 

 2>physicsshadowclone.obj : error LNK2019: unresolved external symbol "void __cdecl GetSavedParamsForCarriedPhysObject(class CGrabController *,class IPhysicsObject *,float *,float *)" (?GetSavedParamsForCarriedPhysObject@@YAXPAVCGrabController@@PAVIPhysicsObject@@PAM2@Z) referenced in function "void __cdecl FullSyncPhysicsObject(class IPhysicsObject *,class IPhysicsObject *,class VMatrix const *,bool)" (?FullSyncPhysicsObject@@YAXPAVIPhysicsObject@@0PBVVMatrix@@_N@Z) 

 2>portal_physics_collisionevent.obj : error LNK2001: unresolved external symbol "void __cdecl GetSavedParamsForCarriedPhysObject(class CGrabController *,class IPhysicsObject *,float *,float *)" (?GetSavedParamsForCarriedPhysObject@@YAXPAVCGrabController@@PAVIPhysicsObject@@PAM2@Z) 

 2>portal_physics_collisionevent.obj : error LNK2019: unresolved external symbol "void __cdecl GrabController_SetPortalPenetratingEntity(class CGrabController *,class CBaseEntity *)" (?GrabController_SetPortalPenetratingEntity@@YAXPAVCGrabController@@PAVCBaseEntity@@@Z) referenced in function "public: virtual int __thiscall CPortal_CollisionEvent::ShouldSolvePenetration(class IPhysicsObject *,class IPhysicsObject *,void *,void *,float)" (?ShouldSolvePenetration@CPortal_CollisionEvent@@UAEHPAVIPhysicsObject@@0PAX1M@Z) 

 2>portal_player.obj : error LNK2019: unresolved external symbol "void __cdecl ShutdownPickupController(class CBaseEntity *)" (?ShutdownPickupController@@YAXPAVCBaseEntity@@@Z) referenced in function "public: virtual void __thiscall CPortal_Player::ShutdownUseEntity(void)" (?ShutdownUseEntity@CPortal_Player@@UAEXXZ) 

 2>prop_portal.obj : error LNK2019: unresolved external symbol "void __cdecl UpdateGrabControllerTargetPosition(class CBasePlayer *,class Vector *,class QAngle *)" (?UpdateGrabControllerTargetPosition@@YAXPAVCBasePlayer@@PAVVector@@PAVQAngle@@@Z) referenced in function "public: void __thiscall CProp_Portal::TeleportTouchingEntity(class CBaseEntity *)" (?TeleportTouchingEntity@CProp_Portal@@QAEXPAVCBaseEntity@@@Z) 

I don't evven know what those errors mean...As you can see YES i'm new to C++ with Source Engine, but i really need to know how to fix that up since it'll help me in the future and it'll let me have my compiled DLLs with all the stuffs i've worked so hard on...I can already tell that it's a BIG edit of the "weapon_physcannon". Oh, and they're all from "Server (Portal)" and i'm compiling with VS 2013 Community with Source 2013 SDK's Source Codes, but only compiling Portal stuffs, no HL2 Projects.

If there is anyone that know how to get rid of this error ...PLEASE...tell below in the replies / comments! If you've got any questions or you're not sure about something in this post TELL IT BELOW, so i can refer you since i'm not so good in English aswell...but atleast i know the bases :P

Thanks and Have a nice day ! ;)

[Spirrwell]

Alright, so it looks like you're trying to merge code from the Source 2007 leak that's on GitHub based on what I'm seeing here.

I don't know what exactly you're doing so I'm going off some guesses here, and I don't know exactly how Portal works, but I'll give it a go.

So what these errors are saying essentially is that they can't find a referenced function or object.

Taking a look at the last one in prop_portal.obj, this means that in prop_portal.cpp it's trying to call UpdateGrabControllerTargetPosition() but it doesn't exist in your project.

From what I can tell this is defined in weapon_physcannon.cpp. You need to make sure you have both weapon_physcannon.cpp and weapon_physcannon.h, and you will need to add at least weapon_physcannon.cpp to your actual project.

This seems to depend on other Portal code, so you will need to go through and check what it depends on as well.

Also, I wouldn't expect something like this to magically work, you will probably have to refactor some code in the end to get it working.

[Ozkii]

Originally posted by Spirrwell:

Alright, so it looks like you're trying to merge code from the Source 2007 leak that's on GitHub based on what I'm seeing here.

I don't know what exactly you're doing so I'm going off some guesses here, and I don't know exactly how Portal works, but I'll give it a go.

So what these errors are saying essentially is that they can't find a referenced function or object.

Taking a look at the last one in prop_portal.obj, this means that in prop_portal.cpp it's trying to call UpdateGrabControllerTargetPosition() but it doesn't exist in your project.

From what I can tell this is defined in weapon_physcannon.cpp. You need to make sure you have both weapon_physcannon.cpp and weapon_physcannon.h, and you will need to add at least weapon_physcannon.cpp to your actual project.

This seems to depend on other Portal code, so you will need to go through and check what it depends on as well.

Also, I wouldn't expect something like this to magically work, you will probably have to refactor some code in the end to get it working.

Well, the gun i'm trying to add is kinda a replacement of the original "weapon_physcannon.cpp". So, should i rename my current weapon name back to "weapon_physcannon.cpp" ? And those are the Portal Project Beta codes i'm currently using and the weapon i tried to add was an a BIG edit of the physcannon and its even telling at then top as a comment "// Note: Remove weapon_physcannon from the project before installing." So, thats what i did...But, seems isnt magic as you said...What i'm going to do is try to rename it back and see if i can define those in the other .CPPs.

[Ozkii]

Ok it's now working i've copied and pasted every missing called functions...Hyped to see how this new weapon works in game !

If you was curious about whats my mod i'm working on well here you go: http://www.moddb.com/mods/portal-last-hope

[Ozkii]

Originally posted by Greenyred:

Ok it's now working i've copied and pasted every missing called functions...Hyped to see how this new weapon works in game !

If you was curious about whats my mod i'm working on well here you go: http://www.moddb.com/mods/portal-last-hope

Welp...only one problem left now...but this one is in-game i cant load any maps...checked the console and it tells me this:

Missing RecvProp for 

DT_WeaponPhysCannonDT_WeaponPhysCannon/m_flTimeForceView

Host_EndGame: CL_ParseClassInfo_EndClasses: CreateDecoders failed.

Dropped Greenyred from server (Disconnected by user)

Do you know what can cause this error ?

[Adrián]

Remove a line similar like this in your physcannon edited file:

SendPropFloat( SENDINFO( m_flTimeForceView ) ),

[Ozkii]

Originally posted by Adrián:

Remove a line similar like this in your physcannon edited file:

SendPropFloat( SENDINFO( m_flTimeForceView ) ),

Maps are loading perfectly now! But, the final problem...i think...is once i type in the console:

give weapon_physcannon

The game crashes...But the portalgun, atleast, is working...

[Spirrwell]

When Source based games crash, they generate crash dumps making it easier to debug, but for future reference you may want to setup your debugger with instructions from here: https://developer.valvesoftware.com/wiki/Installing_and_Debugging_the_Source_Code This will let you debug on the fly.

Anyway, if you go into your Steam\dumps folder, you should see a .dmp file for each crash. It will be something like crash_hl2.exe_DATE_1.dmp. Open it with Visual Studio and click "Debug with Native Only"

It might complain about not being able to find symbols for hl2.exe or whatever, that's fine. The code for hl2.exe and whatnot isn't a part of the Source SDK.

In the lower right (normally) there should be something called the "Call Stack", hopefully if you look at the top-most part it will point you to where in your code it crashed. It should look something like this: http://i.imgur.com/HWYknbn.png

Stuff that is greyed out is typically something you don't have the source code for, but if it's not, you should be able to follow your code and find exactly where it crashed.

[Ozkii]

Originally posted by Spirrwell:

When Source based games crash, they generate crash dumps making it easier to debug, but for future reference you may want to setup your debugger with instructions from here: https://developer.valvesoftware.com/wiki/Installing_and_Debugging_the_Source_Code This will let you debug on the fly.

Anyway, if you go into your Steam\dumps folder, you should see a .dmp file for each crash. It will be something like crash_hl2.exe_DATE_1.dmp. Open it with Visual Studio and click "Debug with Native Only"

It might complain about not being able to find symbols for hl2.exe or whatever, that's fine. The code for hl2.exe and whatnot isn't a part of the Source SDK.

In the lower right (normally) there should be something called the "Call Stack", hopefully if you look at the top-most part it will point you to where in your code it crashed. It should look something like this: http://i.imgur.com/HWYknbn.png

Stuff that is greyed out is typically something you don't have the source code for, but if it's not, you should be able to follow your code and find exactly where it crashed.

Ok cool, it bring me to this line in my edited physcannon code:

c_physcannon_highlight->SetValue(0);

it was in a "bool" if you need the entire "bool" there it is:

bool CWeaponPhysCannon::Deploy( void )
{
	//CloseElements();
	ConVar *c_physcannon_highlight= cvar->FindVar( "c_physcannon_highlight" );
	c_physcannon_highlight->SetValue(0);
	DoEffect( EFFECT_NONE );

	// Unbloat our bounds
	m_flTimeNextObjectPurge = gpGlobals->curtime;

	return BaseClass::Deploy();
}

but the yellow arrow pointed the "c_physcannon_highlight->SetValue(0);" so i think it's this line which making the game to crash...Should i remove it ? Or is it the "bool" which miss something and make the game crash ?

[Adrián]

When debugging the crash "snapshot" on VS, look in a Window called Local Variables. First of all, "c_physcannon_highlight" variable is a pointer. If c_physcannon_highlight's value is NULL, then it means: 1. The related cvar is not defined in the code and 2. It occurred a "NULL pointer crash". To fix that, you then must delete (or comment) all operations on the c_physcannon_highlight pointer (e.g. "->"), because otherwise using these operations is equivalent to dereferencing a NULL pointer[stackoverflow.com], which leads to undefined behaviour, ~a crash.

[Ozkii]

Originally posted by Adrián:

When debugging the crash "snapshot" on VS, look in a Window called Local Variables. First of all, "c_physcannon_highlight" variable is a pointer. If c_physcannon_highlight's value is NULL, then it means: 1. The related cvar is not defined in the code and 2. It occurred a "NULL pointer crash". To fix that, you then must delete (or comment) all operations on the c_physcannon_highlight pointer (e.g. "->"), because otherwise using these operations is equivalent to dereferencing a NULL pointer[stackoverflow.com], which leads to undefined behaviour, ~a crash.

thats what i just did now, i deleted the "highlight" line and the the one on the top too so now i have this:

bool CWeaponPhysCannon::Deploy( void )
{
	//CloseElements();
	DoEffect( EFFECT_READY );

	// Unbloat our bounds
	m_flTimeNextObjectPurge = gpGlobals->curtime;

	return BaseClass::Deploy();
}

[Ozkii]

Still crashing...cant belive that my edited physcannon is causing that many problems...

Debugged again and now it gave me this file -> "spritemodel.cpp" at line 420 ... Here the entire "static unsigned int".

static unsigned int frameCache = 0;
IMaterial *CEngineSprite::GetMaterial( RenderMode_t nRenderMode, int nFrame ) 
{
	if ( nRenderMode == kRenderNone || nRenderMode == kRenderEnvironmental )
		return NULL;

	if ( IsVideo() )
	{
		m_VideoMaterial->SetFrame( nFrame );
	}
	
	
	IMaterial *pMaterial = m_material[nRenderMode];
 420  -> IMaterialVar* pFrameVar = pMaterial->FindVarFast("$frame", &frameCache); <- 
	if ( pFrameVar )
	{
		pFrameVar->SetIntValue( nFrame );
	}

	return pMaterial;
}

[Spirrwell]

In this instance, my guess is that pMaterial is a bogus pointer. I bet if you checked if pMaterial was NULL it wouldn't matter.

So take a look at your call stack and see if you can find where this CEngineSprite is that's calling GetMaterial(). Start from the top and work your way down. My only guess is that this has something to do with beams as I've been digging through the code. I would try messing with r_drawbeams and r_drawsprites to see if when they're off if it still crashes.

But yeah, look through the call stack and try to figure out where it's coming from.

It's also an IMaterial* not a static unsigned int. The static unsigned int is just a variable.

[Ozkii]

Originally posted by Spirrwell:

In this instance, my guess is that pMaterial is a bogus pointer. I bet if you checked if pMaterial was NULL it wouldn't matter.

So take a look at your call stack and see if you can find where this CEngineSprite is that's calling GetMaterial(). Start from the top and work your way down. My only guess is that this has something to do with beams as I've been digging through the code. I would try messing with r_drawbeams and r_drawsprites to see if when they're off if it still crashes.

But yeah, look through the call stack and try to figure out where it's coming from.

It's also an IMaterial* not a static unsigned int. The static unsigned int is just a variable.

Ok, on my side i set "pMaterial" to NULL and it did crashed again, but now when i debugged it's another file which causing the crash and this time it's "hud_quickinfo.cpp" at line 222 in the Portal Project Beta codes... Here take a look:

222  if (pPortalgun->IsOlderGun())

I don't really know why this line causing something, but yea...

[Spirrwell]

What? Just setting pMaterial to NULL is likely going to lead to more problems. You need to look at your call stack like I said. Just hacking away and doing things without understanding what's going on is going to cause you more problems.

It seems like you may not fully understand how pointers work. A pointer is not an object. A pointer POINTS to an object. If you set it to NULL, it's pointing to nothing. So if you try to access it when it's pointing to NULL, it will crash, because you're trying to access something that doesn't exist.

On the flipside, if you declare a pointer without setting it to anything, or set it to an object that goes out of scope or is deleted, it becomes a bogus pointer, pointing to some random spot in memory.

pPortalgun is a pointer as you can see it's accessed by an arrow ->. Also Valve typically names pointers by putting a lowercase 'p' at the beginning of the variable name.

This means that pPortalgun is either NULL or bogus. I don't have the full code in front of me, so I can't say.

Also, just in case you aren't, you should try doing builds in Debug mode. You might get warnings about asserts when starting the game, you can click "Ignore All Asserts" (Also you'll probably want to run in windowed mode as sometimes the fullscreen hides those messages and it may look like the game froze)

Running in debug mode will make debugging more accurate and it should be easier to see what is happening in your call stack. Your call stack is your friend, and if you want to get better at programming in C++, you will need to get more familiar with the debugging tools. I know it can be intimidating, but it's an important process.

[Ozkii]

Originally posted by Spirrwell:

What? Just setting pMaterial to NULL is likely going to lead to more problems. You need to look at your call stack like I said. Just hacking away and doing things without understanding what's going on is going to cause you more problems.

It seems like you may not fully understand how pointers work. A pointer is not an object. A pointer POINTS to an object. If you set it to NULL, it's pointing to nothing. So if you try to access it when it's pointing to NULL, it will crash, because you're trying to access something that doesn't exist.

On the flipside, if you declare a pointer without setting it to anything, or set it to an object that goes out of scope or is deleted, it becomes a bogus pointer, pointing to some random spot in memory.

pPortalgun is a pointer as you can see it's accessed by an arrow ->. Also Valve typically names pointers by putting a lowercase 'p' at the beginning of the variable name.

This means that pPortalgun is either NULL or bogus. I don't have the full code in front of me, so I can't say.

Also, just in case you aren't, you should try doing builds in Debug mode. You might get warnings about asserts when starting the game, you can click "Ignore All Asserts" (Also you'll probably want to run in windowed mode as sometimes the fullscreen hides those messages and it may look like the game froze)

Running in debug mode will make debugging more accurate and it should be easier to see what is happening in your call stack. Your call stack is your friend, and if you want to get better at programming in C++, you will need to get more familiar with the debugging tools. I know it can be intimidating, but it's an important process.

Don't worry...i'd like more feedbacks/comments/replies like this since those helps me alot in progression ! Now atleast i'll more carefull with those pointers and with debugging. You said you don't have the full code well it's the Portal Project Beta src codes if you want to take a look for help more here -> https://github.com/reepblue/project-beta <- Now i'm going to fix the "pMaterial" and retry with what you told me to do...