FGE (Flight Game Example) Port...

#1 Yeah I ported this a while back and ran into that VMPlayer problem. You might want to wait a little bit on a Torque 3D port.

#2 So I have finished all of the GUIs now and all the C++ code is in. The only outstanding issues now are as follows:

1. VMPlayer - Need to come up with another solution for this.[/li]
2. Static Bots - The bots don't fly around and just stand still.[/li]
3. LOD - All ships and bots (excluding repair ships) only appear at very far distances, as soon as you close in they disappear.[/li]
4. Sound Fixes - Some sounds are not playing.[/li]
5. Radar - The radar seems to be operational but needs some testing.[/li]

I am making solid progress and the end of the week still looks like it is on the cards.

Here are some of the screen shots of the work done so far:















If anyone has some ideas about the bugs that I have encountered ... feel free to send me the information. :P

#3 Interestingly enough ... the LOS issue goes away when I use the models from the Drone Pack. Very strange indeed.

Looks like this port might take a little longer then expected.

#4 I have run into the 'static bots' issue as well. I am seriously in need of a fix for this. I've been all over the source code and tried everything I can think of to get this to work but the AIFlyingVehicle::getAIMove() member function is not getting any value for mAimObject which is a data member within the AIFlyingVehicle class. I've tried public, private, and protected for both the member function and the data member. mAimObject is accessible from the getAimObject() member function but when called from getAIMove() it still returns nothing. Can anybody with more knowledge in C++ figure out why this is happening?

#5 I am in the same boat ... I have also tried everything.

I did run into a mention of the AIWheeledVehicle class that may be able to fix this problem ... but I am not convinced.

I however think that I have narrowed it down to the symptom ... which I think is the GhostID of the objects NOT being retrieved correctly.

If I set the default state of the bots to Move and hardcode them to fly to a specific position ... they all fly there and then give a SetMoveDestination callback error.

After further debugging I tracked it down to what looked like wrong GhostIDs ... unfortunately I could never resolve or verify that this was the issue. Hence the port is now in stasis ... :(

#6 It appears that AIFlyingVehicle::getAIMove() (And probably AIFlyingVehicle::processTick()) are only being called on the CLIENT. This is very obviously wrong but I don't know the preferred method of telling the server that it needs to call processTick() on the AIFlyingVehicle object.

#7 I too have the same problem. Like Quinton i too have come across the 'invalid' GhostID, and in a couple of the functions it is getting the wrong id all together.

For example if my bot id is 2446 alot of the script functions are recieving 2448. They are always recieving an ID number whose value is 2 higher than what it should be getting.

@Jesse

I think the issue with getAiMove falls back to invalid id numbers being passed to the functions.

--
I have been pouring threw the code for a few weeks now with no luck. My game project is like Quintons porting on complete hold until this is resolved.

@Quinton

Yeah i though that too about the AIWheeledVehicle so i implimented it and checked functions compairing them to AIFlyingVehicle but nothing got resolved. Problem still exists.

--

If we can solve this it would be great. I really need to get moving forward on my project but this issue is holding everything up.I also have a second project that requires the AIFlyingVehicle class but i have yet to implement the AI, mainly because of this issue.

If anyone here at GG has any ideas as to why please feel free to share them.

#8 Your bot is made of a GameConnection object and an AIFlyingVehicle object. The higher ID number is the AIFlyingVehicle (player), and the lower number is the GameConnection (client) object. This allows the AIFlyingVehicles to utilize the same spawn code that players use. I've been using this code in TGE successfully for a couple of years.

Using the same scripts to spawn these AIFlyingVehicles that I've been using in TGE, everything is happening as it should, except that if you check the engine code in this situation, AIFlyingVehicle::getAIMove() is never called when isServerObject() is true and the server is never calling processTick on the AIFlyingVehicle. When you hard code the mMoveDestination and mMoveState you are actually causing the movement to occur on the client.

You might have also noticed that when you open the mission editor in TGEA and select your motionless AIFlyingVehicle, you can drag it's bounding box around but the actual mesh remains stationary. This does not happen with FlyingVehicle objects that are controlled by players and it also does not happen with AIPlayer objects. In TGE, you can drag the AIFlyingVehicles around from within the mission editor.

I hope that I am wrong, but I believe that the problem is at a much lower level than merely passing the wrong object IDs around in script.

#9 @Jesse: I think you are actually on to something there. After further investigation and mulling over the "Multiplayer Gaming and Engine Coding" book ... I tend to agree with your evaluation.

The movement is definitely only on the client ... I ran a test by connecting a second client to the server which was running as a client as well.

I then did a tree view on all objects and found the IDs for only 1 bot that I spawned ... by manually calling the move method on the ID, the bot only moved on the on the client-server instance.

You will also notice that when you shoot at the stationary bots they never explode ... I only manage to kill them with a sidewinder. This is initially where I got hooked on the GhostID thing.

It is however refreshing to know that I am not the only one seeing this problem ... I thought I was going mental at one stage. :(

#10 My decision to begin using TGEA for Veks was primarily based on the much more advanced graphics and sound layers as well as the user interface, but I'm beginning to seriously question the decision. As far as Michael's suggestion some time back about waiting for a T3D port, the price of the engine is too big an obstacle at this point.

@Michael Hall: You said that you ported this a while back, did you ever get the bots to actually move, if so, how did you resolve the issue we're experiencing?

(Bump this thing to the top of the list, maybe somebody will take pity on us tortured souls =)

#11 Hah, damn. Actually I never used the bots in my port so I didn't know they weren't working.

My statement about waiting on Torque 3D had to do in regards with Quinton mentioning the problem with the music player and eventually porting to Torque 3D. Torque 3D has streaming 2d audio (music) now which more than solves the VM Player problem. At the time of his post it wasn't a known feature yet, but I knew it was coming -- I would have hated to see him waste his time of coming up with a solution when I knew one would be seen in just a few days when the next beta version was released.

I had wondered how the port was going, but now that I know about the bot problem I'll do some poking around in there too to see if I can help you guys out any.

#12 I too wanted to use this for my project Air Finitum and was going to use the SSAO and Blur shader as well as some of the other graphics eye-candy from TGEA.

I do have T3D ... but still wanted to finish my project on TGEA first.

@ Michael: I hope you can find something, I have spent way more time on this port then I initially wanted to. :(

@ Jesse: I unfortunately need to finish an urgent project this weekend, but I will look into this again A.S.A.P. :)

#13 Currently the AI is the only thing slowing down my development process. I do appreciate all the time you guys are putting into this. I've put approximately 36+ hours into trying debug this issue and I'm about ready to throw in the towel. One thing I noticed was that the AIPlayer actually works the way it's supposed to. I even tried re-integrating the existing AIPlayer code into a new AIFlyingVehicle class and ended up with the same problem. My suspicion is that somewhere along the Vehicle->FlyingVehicle->AIFlyingVehicle inheritance chain there is something that isn't being propagated to properly allow for the server to run processTick() on the AI.
I think this primarily because the AIPlayer which works has one less step in its inheritance between Player->AIPlayer.

#14 (It's 7 AM when I'm posting this, I've been kicking this thing for about eight hours now. So if the following doesn't work for you I apologize, but something I did has allowed me to blow up the AIFlyingVehicles)

I added the following to my AIFlyingVehicle.cpp and I can now cause damage by shooting them (they even explode now):

bool AIFlyingVehicle::onAdd()
{
	return Parent::onAdd();
}

You need this in the public: section of your AIFlyingVehicle.h:

bool onAdd();

So far so good? But they still don't move. After more digging I discovered by placing a break point on line 343 of gameProcess.cpp that numMoves is being set to 0 when getMoveList is being called on the AIConnection which is why the server never calls processTick() on the AIFlyingVehicles.
(Edit: Correction, gameProcess.cpp is calling
con->mMoveList.getMoveList(&movePtr, &numMoves)
which is where numMoves is being set to 0
Putting breakpoints in AIClient::getMoveList() and AIConnection::getMoveList() shows that neither one of these is being called at any point.)

#15 @Jesse: I can confirm that your changes did the trick for the damage bug against the bots. :)

Added exactly what you stated above and it worked first time.

Well done.

#16 Nice Job Jesse, I can also confirm that that works for destroying the AI. Although mine were destroyable intermitently before. but this fixed it for good.

Good One.

#17 Ok guys, i fixed the issue.

First, Open aiWheeledVehicle.cpp, and aiFlyingVehicle.cpp

From aiWheeledVehicle.cpp find it`s getAiMove function. Copy it and replace the aiFlyingVehicle`s getAiMove Function.

next step:

find and delete the following code block in the new aiFlyingVehicle::getAiMove, it should be near the top of the function. this check is not needed here:

// Orient towards our destination.
		if (mMoveState == ModeMove || mMoveState == ModeReverse) {      
				movePtr->yaw = getSteeringAngle();
		}

This got my Ai flying around. Let me know if this worked for you.

#18 Sorry i guess i shoulda posted the function. My bad.

so your new aiFlyingVehicle::getAiMove function should look like this:

bool AIFlyingVehicle::getAIMove(Move *movePtr)
{
   *movePtr = NullMove;

   if (!mDisableMove) {
		// Use the eye as the current position.
		MatrixF eye;
		getEyeTransform(&eye);
		Point3F location = getPosition(); 
		Point4F rotation;
		getTransform().getColumn(1, &rotation);
			
		// Move towards the destination
		if (mMoveState == ModeMove) {
			F32 xDiff = mMoveDestination.x - location.x;
			F32 yDiff = mMoveDestination.y - location.y;

			// Check if we should mMove, or if we are 'close enough'
			if (mFabs(xDiff) < mMoveTolerance && mFabs(yDiff) < mMoveTolerance) {
				mMoveState = ModeStop;
				throwCallback("onReachDestination");
			}
			else {
				// Build move direction in world space
				if (isZero(xDiff))
					movePtr->y = (location.y > mMoveDestination.y)? -1 : 1;
				else
					if (isZero(yDiff))
					movePtr->x = (location.x > mMoveDestination.x)? -1 : 1;
					else
					if (mFabs(xDiff) > mFabs(yDiff)) {
						F32 value = mFabs(yDiff / xDiff);
						movePtr->y = value; // (location.y > mMoveDestination.y)? -value : value;
						movePtr->x = (location.x > mMoveDestination.x)? -1 : 1;
					}
					else {
						F32 value = mFabs(xDiff / yDiff);
						movePtr->x = (location.x > mMoveDestination.x)? -value : value;
						movePtr->y = 1;  // (location.y > mMoveDestination.y)? -1 : 1;
					}

				// Rotate the move into object space (this really only needs
				// a 2D matrix)
				Point3F newMove;
				MatrixF moveMatrix;
				moveMatrix.set(EulerF(0, 0, -(rotation.z + movePtr->yaw)));
				moveMatrix.mulV( Point3F( movePtr->x, movePtr->y, 0 ), &newMove );
				movePtr->x = newMove.x;
				movePtr->y = newMove.y;

				// Set movement speed.  We'll slow down once we get close
				// to try and stop on the spot...
				if (mMoveSlowdown) {
					F32 speed = mMoveSpeed;
					F32 dist = mSqrt(xDiff*xDiff + yDiff*yDiff);
					F32 maxDist = 5;
					if (dist < maxDist)
					speed *= dist / maxDist;
					movePtr->x *= speed;
					movePtr->y *= speed;
				}
				else {
					movePtr->x *= mMoveSpeed;
					movePtr->y *= mMoveSpeed;
				}

				// We should check to see if we are stuck...
				if (location == mLastLocation) {
					throwCallback("onMoveStuck");
					mMoveState = ModeStop;
				}
			}
		}

		// Replicate the trigger state into the move so that
		// triggers can be controlled from scripts.

		for( int i = 0; i < MaxTriggerKeys; i++ )
			movePtr->trigger[i] = getImageTriggerState(i);

   } else {
	   mRigid.setAtRest();
   }

   return true;
}

#19 Doesn't work for me ... but then I don't have AIWheeledVehicle in my project ... guess I should add that first.

Which version of AIWheeledVehicle did you use Roland?

I will then put it in and give it another test.

#20 i did do other changes that may have had an effect.

I added the mAimOffset variable from AIPlayer as well as:

mTypeMask |= AIObjectType;

to the constructor function.

I also changed the consolemethod setAimObject to the one in AIPlayer as well.

not sure 100% if these played a factor. I added them before changing the getAiMove function. compiled, did not make a diff, then changed the getAiMove, compiled and it worked.