Noob Question

#1 Why don't you just have your database send a new type of Net/SimEvent to the simulation itself containing the move information, and then have that Event handed to the processTick of the appropriate object, letting the sim handle it from there?

Alternatively, have the db spit out move information to a separate table that can be queried directly by the simulation on a timed basis, and generate move events from there, simulating how the engine (again) does things already?

Much easier than trying to add on an entire new polling/processing structure at the lowest level of the engine. Both of these approaches require work, but I would suggest that they require much less work than adding in another processing layer from scratch. Both the Event Manager and the Move Manager do a ton of work for you already, so it would be to your benefit to use them as unchanged as possible.

#2 Thanks. I'll try that out. But how do I create new instances of units programatically?

#3 Tried googling for the info? We have a very nice google mini search system on the site. :)

Search for 'make simobject in c++'

#4 Looks like the search engine doesn't work too well :( It fills all the results with class="hilite"> all over the place. It makes the threads pretty unreadable... :(

#5 That wasnt to yourself. :)

#6 Dina - works great for me... Are you using an older web browser?

#7 Heh,
actually there is something funny going on.
the page of search results is fine,
but when i follow the first link,
the resulting GG forum page has all the letter "C"s highlighted.

tinypic.com/al6976.gif

.. but, strangely, not when i copy-n-paste the link into a new browser page.

weird.. but fairly minor.

maybe it's something to do with the "C++" ?

i'm in firefox 1.0.6, winXP.

#8 Hah... Wild. I've mentioned it to Rick.

#9 I hacked together this chunk of code, but nothing is showing up. One problem is obviously the fact that I haven't moved the unit to anywhere useful.... I'm guessing I have to use the setTransform to move the unit to a specific location? Does anyone know an easy way to tell the unit to move north, or south, or whatever through the matrix.... I'm not sure exactly where 0,0,0 is in the game world.... Also, any comments on other stuff I'm missing would be cool. TIA

MatrixF imat(1);
RTSUnit *fyv = new RTSUnit();
fyv->setDataField("scale","scale","1 1 1");
fyv->setDataField("shapeFile","shapeFile","~/data/shapes/warsparrow/warsparrow.dts");
fyv->setTransform(imat);
fyv->registerObject();
fyv->addToScene();

#10 Call iMat.setPosition and pass it a position you want. A safe bet is something way up in the air (Z is up), say a thousand units. If you look around you ought to be able to spot it. :)

#11 How high is "way up in the air" I have no idea what units are being used here... I tried using both 500, 1000 and 10000, but nothing shows up. Also, where is 0,0,0 located, is it located at the bottom left corner? What are the normal extents of the map region? I used 50,50,500. Would 50, 50 be somewhere in the south west quadrant of the map, or should I be using normalized cordinants?

Also, do I need to make any special calls to register objects in the mini-map?

Also, is there any documentation on this stuff anywhere? I can't seem to find any real documentation on this site.... All the "official" documentation is is a bunch of function headers without even field descriptions...

#12 MatrixF imat(1);
Point3F pos;
pos.x = -30;
pos.y = -35;
pos.z = 300;
imat.setPosition(pos);
RTSUnit *fyv = new RTSUnit();
fyv->setDataField("scale","scale","1 1 1");
fyv->setDataField("dataBlock","dataBlock","botBlock");
fyv->setDataField("shapeFile","shapeFile","~/data/shapes/warsparrow/warsparrow.dts");
fyv->setDataField("path","path","");
fyv->setTransform(imat);
fyv->registerObject();
fyv->addToScene();
fyv->setTeam(0);

Seems like if I create an object in the middle of the map using the editor, its positioned at -30 -35 250, so these seem like reasonable values, but nothing is showing up still.... What am I missing here?

#13 Way up in the air is a thousand units, like I said in my post. :)

In Torque, units can typically be thought of as meters.

What are you trying to do here - get the warsparrow to show up in the minimap as a rendered item, or as a blip? If a blip, height doesn't matter. As far as extents go, I believe the minimap goes off of the mission bounds - but a quick look at the code would confirm that.

The best documentation for how things work is the code itself. Beyond that, you have with the RTS kit all the docs we wrote as part of the development process.

#14 Well the code isn't really commented at all, so thats not a very good source of documentation... Where are the docs you wrote as part of the development process...? I can't find anything in the RTS kit. Do you know what directory they are in?

I'm actually trying to create units in the game based off of positions in a database. I want to create both a 3D unit (warsparrow for now), as well as a blip on the minimap.

#15 Reading code is a great way to understand how things work. It's always up to date, and it won't fill your head with preconceptions about how things ought to work - just how things do work. Knuth's notion of Literate Programming has a lot of application here.

Don't think that I've got a big trove of documentation that I'm holding out on you with because I think you should be "doing things the hard way." I, and everyone at GG, practices what we preach. If we need to figure out how something works, we look at the code - more often than not, the person who wrote it is long gone, and we don't have time to reimplement it from scratch.

You _have_ all of the documentation from our development process. We didn't write very much. It wasn't really needed.

I haven't touched the RTS code in many months. Let me illustrate how I might go about finding how it renders things, and what points are going to be considered for rendering in it:

Looking at the code for GuiMapHud, which is responsible for rendering objects, I find it calls projectPoint to get from worldspace positions to locations on the map GUI.

#16 The code for projectPoint:

bool GuiMapHud::projectPoint(Point2F pt, Point2F* screenPos)
{
   const RectI missionArea = MissionArea::smMissionArea;
   Point2I point(pt.x, pt.y);

   pt.x -= missionArea.point.x;
   pt.y -= missionArea.point.y;
   Point2F pct(pt.x / missionArea.extent.x, pt.y / missionArea.extent.y);

   Point2I gutter(0,0);
   if (missionArea.extent.x < missionArea.extent.y)
      gutter.x = (1 - ((F32)missionArea.extent.x / missionArea.extent.y)) / 2 * mBounds.extent.x;
   else if (missionArea.extent.y < missionArea.extent.x)
      gutter.y = (1 - ((F32)missionArea.extent.y / missionArea.extent.x)) / 2 * mBounds.extent.y;

   screenPos->x = pct.x * (mBounds.extent.x - 2*gutter.x) + gutter.x;
   screenPos->y = (1-pct.y) * (mBounds.extent.y - 2*gutter.y) + gutter.y;

   if (!MissionArea::smMissionArea.pointInRect(point))
      return false;
   else
      return true;
}

I first look over the code in bulk. It seems to be grouped into five chunks. "Ah ha," I say to myself, noting these chunks. "Perhaps they mean something, or reflect the structure of the code here!" I add, still to myself, "Perhaps if I figure out what each chunk does, I will be able to figure out how general 3d points are mapped to graphics on the map hud, which is a 2d space in a rectangle."

So, sitting back in my chair and eating some Yoplait, I think upon these mystical incantations:

const RectI missionArea = MissionArea::smMissionArea;
   Point2I point(pt.x, pt.y);

Inspiration strikes. "My god. Banana chunks in my yogurt. And they're grey. What does this mean?" I also note that I'm storing a local copy of the mission area, which is a 2d rectangle as indicated by its type, and the point which is being considered for projection (ie, conversion from 3space to 2space). That done, I consider the next chunk:

pt.x -= missionArea.point.x;
   pt.y -= missionArea.point.y;
   Point2F pct(pt.x / missionArea.extent.x, pt.y / missionArea.extent.y);

"Hmm. It seems," I say to myself, "that they have tried to make this yogurt more interesting by putting preserved fruit chunks in it. Terrifying." Looking back up at the code, I realize that they're moving the point into a square defined by the extents of the rectangle. First they subtract, so the input point is relative to the location of "point", and then they scale, so it ranges from 0 to 1 if it's inside the extent of the rectangle. So, (0,0) must be the top left of the mission bounds, and (1,1) the bottom right of the mission bounds. Or NW and SE if you like that nomenclature better.

I pause to scoop those finicky bits from the bottom of the yogurt container out. Why can't they design a container that's shaped more like a spoon so I can get that stuff out without a lot of trouble?

#17 The next chunk! It haunts me, temporarily sated by cheap dairy products as I am.

Point2I gutter(0,0);
   if (missionArea.extent.x < missionArea.extent.y)
      gutter.x = (1 - ((F32)missionArea.extent.x / missionArea.extent.y)) / 2 * mBounds.extent.x;
   else if (missionArea.extent.y < missionArea.extent.x)
      gutter.y = (1 - ((F32)missionArea.extent.y / missionArea.extent.x)) / 2 * mBounds.extent.y;

'Yeek. That looks hard." I focus on getting the yogurt out of the top of the container with my tongue, since my spoon can't reach there. "Next chunk!"

screenPos->x = pct.x * (mBounds.extent.x - 2*gutter.x) + gutter.x;
   screenPos->y = (1-pct.y) * (mBounds.extent.y - 2*gutter.y) + gutter.y;

"Whoa." My tongue hurts from the sharp plastic container. Also, I notice this is the first time anything is written into the screenPos variable, which points to a Point2F which presumably holds a projected 2d result point. "Hmm. Maybe I need more yogurt." I notice it's taking the values in pct - which probably range from 0 to 1 - and scales them up by the extents of the control, taking into account some gutter stuff. Gutters, as we all know, exist to catch leaves. Also, sometimes they are the blank spaces around text documents and GUI controls. So all that junk is probably just there so that if you have blank spots it'll work out properly.

I take a break to get another thing of yogurt from the fridge. "I love yogurt," I say to myself firmly, not tolerating any dissent.

Besides, it's good to take breaks at 80%. Gives you a chance to reflect on your thought processes. Or at least get more yogurt. "Mmm. Yogurt." I get some strawbeery cheesecake. "99% fat free! But it tastes so good..."

#18 "Ok, Ben. Focus. The last chunk - what can it possibly be about?"

if (!MissionArea::smMissionArea.pointInRect(point))
      return false;
   else
      return true;

"Wow." There are little bits of strawberry in this yogurt. And it tastes like cheesecake crust! Man, now I really want some cheesecake. But the bakery is closed. "No! This sucks. I have no choice but to finish this code reading, I guess."

"Well," I say, shovelling yogurt into my mouth with the spoon, "it seems no matter what, this code returns either true or false. So it's definitely not executing past this point." I glance down at the next chunk, only to realize there isn't any. Gripped by a sudden emptiness, I gulp more yogurt, hoping to fill the void inside. This is it. The end.

"What's that conditional? It seems to be checking if point is in the mission area. I guess if the point isn't in the mission area, there's no point rendering it." And sure enough, when I flip back to the render code, it doesn't draw anything if projectPoint returns false.

A thought suddenly strikes me. "Maybe Dairy Mart has cheese cake!" Then I remember how skeezy that place is, and decide I can survive till morning and get some at the bakery by work. I also consider if Z has any effect on what's drawn or not. After some inspection of the code chunks, I decided that the Z values are discarded entirely.

So, to summarize: Yogurt is awesome, the function takes a 3d point and turns it into a 2d point disregarding Z, and if the point is outside the mission area, it'll return false, causing the object not to be rendered.

But wait - then why might an object not get rendered? Well, it can't be due to position, if it's inside the mission bounds, at least insofar as that function is concerned.

So maybe the reason the object isn't getting rendered is elsewhere. I should probably read over the rendering code.

Luckily, just before I finish off my next thing of yogurt, I find the loop that renders blips on the GUI (surprisingly, it's only a few lines above the aforementioned call to projectPoint!), around line 34 of guiMapHudRender.cc. It looks like it does some filtering on the objects it finds. Hmm. That might explain why some objects don't get rendered.

I ask myself what that filtering looks like, because that's what I like to do:

Here's the chunk of code I'm considering:

//render the units
   glPointSize(2.0f);
   glColor3f(0.0, 0.0, 1.0);
   glBegin(GL_POINTS);
   static char buff[18];
   dSprintf(buff, 18, "$Server::TeamInfo0");
   for (SimSetIterator itr(mConnection); *itr; ++itr)
   {
      if ((*itr)->getType() & PlayerObjectType)
      {
         if (RTSUnit* unit = dynamic_cast<RTSUnit*>(*itr))
         {
            if (!conn->isUnitVisible(unit))
               continue;

            Point2F screenPos;
            if (projectPoint(unit->getPosition(), &screenPos))
            {
               S32 team = unit->getTeam();
               buff[17] = '0' + team;
               const char* pref = Con::getVariable(buff);
               ColorF teamColor;
               dSscanf(pref, "%f %f %f", &teamColor.red, &teamColor.green, &teamColor.blue);
               glColor3f(teamColor.red, teamColor.green, teamColor.blue);
               glVertex2f(offset.x + screenPos.x, offset.y + screenPos.y);
            }
         }
      }
   }
   glEnd();
   glPointSize(1.0f);

I decide it'll be easier to think about if I just ignore all the parts that don't seem to directly relate to deciding what is drawn or not. So I know all the GL code can go, since OpenGL is just for rendering.

#19

//render the units
   static char buff[18];
   dSprintf(buff, 18, "$Server::TeamInfo0");
   for (SimSetIterator itr(mConnection); *itr; ++itr)
   {
      if ((*itr)->getType() & PlayerObjectType)
      {
         if (RTSUnit* unit = dynamic_cast<RTSUnit*>(*itr))
         {
            if (!conn->isUnitVisible(unit))
               continue;

            Point2F screenPos;
            if (projectPoint(unit->getPosition(), &screenPos))
            {
               S32 team = unit->getTeam();
               buff[17] = '0' + team;
               const char* pref = Con::getVariable(buff);
               ColorF teamColor;
               dSscanf(pref, "%f %f %f", &teamColor.red, &teamColor.green, &teamColor.blue);
            }
         }
      }
   }

I can also get rid of the color stuff - it'll probably show a color just fine, but it's not showing anything at all, so color probably isn't the issue. (I could also notice that no blending is occuring, meaning that even if no color was specified, I'd still see a blotch of some sort, since transparency wasn't an option, that being what blending does.)

//render the units
   for (SimSetIterator itr(mConnection); *itr; ++itr)
   {
      if ((*itr)->getType() & PlayerObjectType)
      {
         if (RTSUnit* unit = dynamic_cast<RTSUnit*>(*itr))
         {
            if (!conn->isUnitVisible(unit))
               continue;

            Point2F screenPos;
            if (projectPoint(unit->getPosition(), &screenPos))
            {
               S32 team = unit->getTeam();
            }
         }
      }
   }

Ok, so now I just have a loop. Let's assume it's going over all the possible objects; that means I can ignore the loop and just focus on what it contains. The less stuff I have to think about, the better - I have a lot of yogurt to eat!

if ((*itr)->getType() & PlayerObjectType)
      {
         if (RTSUnit* unit = dynamic_cast<RTSUnit*>(*itr))
         {
            if (!conn->isUnitVisible(unit))
               continue;

            Point2F screenPos;
            if (projectPoint(unit->getPosition(), &screenPos))
            {
               S32 team = unit->getTeam();
            }
         }
      }

So looking over that code, I see four filtering operations happen. If any fail, then the blip isn't drawn. They are:

if ((*itr)->getType() & PlayerObjectType)
if (RTSUnit* unit = dynamic_cast<RTSUnit*>(*itr))
if (!conn->isUnitVisible(unit))
if (projectPoint(unit->getPosition(), &screenPos))

Hmm. All of these seem to be succeeding, or at least, should be. Guess the problem lies elsewhere. I'd definitely break open the debugger and make sure that the object was being considered here. If it wasn't the problem might lie elsewhere from the map hud entirely.

One thing I would notice if I traced through the code run when registerObject is called is that the onAdd for RTSUnit or one of its parents calls addToScene, making my additional call suspect. I might also wonder if perhaps I needed to compile in debug mode - that seems like it might be the sort of thing that an assert would trigger on (ie, adding an object to a scene twice). I'd also take the opportunity to make sure that my onAdd was succeeding - it might be failing on some relatively trivial thing, rendering this whole exercise moot.

Hope this clarifies what I'm getting at.

#20 You're apparently better at looking a 1000s of files, and finding the relavant pieces of code, so I applaud you. Ok. So now I've started to read your first post, and my first question is "Where is GuiMapHud". I can't find it in the project. Not really sure how you managed to find it yourself, but apparently its easy for someone who isn't as stupid as me.