Mouse Pick

#1 Search for "object selection" in the resources, or possibly just "selection".

It's also incredibly well done in the RTS Starter Kit.

#2 Thanks Stephen, didn't find too much and what I did find was dated 2002. Any newer info than that?

#3 Did you go down to the bottom of the notes and check the last date someone posted about it? The main reason there is so few other resources about it is because this is the one that 90% of the people that want something similar use. No need to write another one when that one works (with tweaking as appropriate for your project).

It's not going to be "plug and play", but then again, nothing really is that accomplishes a lot!

If it still doesn't help you out, I'd suggest the RTS SK--it does all that plus a lot more, and is well worth the price.

#4 Check out the click and pick resource. It does require you to hand patch it, but its quite easy to see what it does and make it work

#5 Yeah, I used the click and pick resource for my GID8 game. It took about 10 minutes to patch it and get it up and running. It still works with recent builds.

#6 Is there someplace that tells me what all the stuff in the patch file means? I dont mind the work just need to decrypt it a bit.

#7 + are lines that are added, - are lines that are removed, and then there are header lines that indicate where in the file each chunk is and how many lines are added/removed.

#8 I was thinking more on the lines of stuff like this

enumerate what?
enum


looks like it might refer to line numbers?
@@ -46,6 +52,9 @@

remove this 3 times then add it back in 3 times?
--- engine/console/simManager.cc 7 Apr 2003 14:09:10 -0000 1.2
+++ engine/console/simManager.cc 20 Apr 2003 14:47:41 -0000

#9 I have no idea what the first fragment is about.

The second indicates, yes, that some lines are added and removed.

The third indicates what file is currently being patched, with a relative path.

I posted a resource on this a while ago... www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=3014

#10 I went to the resource and followed the links you had there 2 are broke and one took me to a linux site that tells me all about making a patch, applying a patch, fixing patch etc but can't find any listings to say what is IN the patch so I can read it and merge things properly. Any links to that info?

#11 You need to work on your reading skills:

Quote:What does this gobbledygook mean? The first line shows me typing the command in; I told diff to compare rev0.c and rev1.c. Now a line by line analysis:

I give examples of the patch file format, and explain what sort of output you'll get in different circumstances.

#12 Actually to give Howard benefit of the doubt, what the resource gives is examples of the diff command, not patch output files. They are just a touch different in some cases---diff uses > and <, showing differences (duh!) between two files, while patch shows what specific things to do to a particular file.

@Howard: Here is a quick rundown since those links are broken:

Patch files are broken down into sections, which is loosely defined as:
File header
1 or more "hunks"
(possibly more file headers with their own hunks)

Here is a structured example:

File description header ( 2 lines): the source of the patch is indicated by "---" and the target indicated by "+++".
(Note: All that really matters to you is the file name itself, and where it is in your dir structure).
Example:

--- RTSKit/engine/terrain/terrData.cc	2004-11-26 10:45:59.120822000 -0500
+++ rts-engine/engine/terrain/terrData.cc	2004-11-26 11:16:08.821706632 -0500

a "locater" line, indicated by "@@", which is uses to find out roughly where the code to be changed by this hunk is:

@@ -54,20 +54,24 @@

NOTE: This locator is used by the automated patch application to find the general location of the code that is to be changed. While you can use it to get started, it can be very difficult to use in a long patch that is applied manually, since they are running line numbers that can change as each patch is applied. Most people that apply patches manually do not use this, or only use it very loosely.
For general knowledge, what you have is two points of information, one for the original file, and one for the target file. The first number in each point (the 54) indicates a location line number, and the second number (20 for the "-" datapoint, 24 for the "+" datapoint) is the +/- offset that the code can be found in. In other words, to find the code for this hunk:
in the source file ("-"): go to line 54, and look within +/- 20 lines (could be 10, or half the number, I honestly don't remember) to find it.
in the target file ("+"): go to line 54, and look within +/- 24 lines.

"Reference" code: These are actual lines of code from the file being changed, but do not have a "+" or "-" in front of them. They are used by the automated process to lock down the exact place to change the code, and should be used the same way in a manual patch application. Most of the time, you can use "search" on the entire line to find the right place to modify code, just sanity check it before blindly applying changes.

//--------------------------------------
 void TerrainBlock::setFile(Resource<TerrainFile> terr)
 {

"Change" lines: These are the actual changes to your code. They operate on an "entire line" basis, and have two types:
- : delete whatever line in your file is shown after the -
+ : add whatever line is shown in the patch file to your file.

-   mChunkMap = mFile->mChunkMap;
-   materialMap = mFile->mMaterialMap;
-   heightMap   = mFile->mHeightMap;
-   flagMap = mFile->mFlagMap;
+   mChunkMap        = mFile->mChunkMap;
+   materialMap      = mFile->mMaterialMap;
+   heightMap        = mFile->mHeightMap;
+   flagMap          = mFile->mFlagMap;

NOTE: In this particular example, if you analyze what's really changed, all you will see is that we add some whitespace between the variable name and the = sign. Due to the nature of automated patching, that requires you to delete the entire line, and then copy in the new line. A bit overkill in this particular case, but it's for automated processing of the patch.
(cont)

#13 NOTE: It can take a while to get used to this line by line concept, just hang with it. Things as simple as adding a space between two symbols on a line require you to delete the entire line (a "-"), and then add back in the entire line "+". To the human eye, you may not even -detect- a difference--and sometimes there isn't! In some cases, the diff/patch generation process needs you to delete and then add back in lines simply so it can keep track of itself. Just remember that patches are intended to be applied automatically, so this file is for that purpose, and if you are applying it manually, you have to work within that context.

Within a hunk, you may have many lines that get added/subtracted, interspersed with "reference lines". Manually applying a patch correctly requires attention to detail, so do it slowly. You can not simply cut/past an entire hunk directly into your file, remove the +/- signs at the front, and expect it to work.

Experienced developers (both in general, and also experienced with the code that is being patched) may be able to "optimize" their work by analyzing the changes being made as they go and simply making that change, but unless you are pretty experienced, I suggest following the process of "delete line if a -, add line if a +" blindly.

Disclaimer: Purists will note that the above description of the use and functionality of the sections of a patch are not "strict", but written to provide basic understanding of what is happening/is there.

#14 Thanks Stephen that helped alot!
I have a couple small "patch" files I'll try this out.

#15 Thanks, Stephen. You've spent a lot more time with patch files than I have recently, it would seem. :)

#16 @Ben: Heh...5,500+ lines of manual patch to try to get the old Terrain Manager/Terrain Tiling system up to 1.3, so yeah, I guess you could say I've had some recent experience ;)

#17 Ok, I got it all munged in, builds with no errors, got toggleMouseLook in and I get a mouse pointer in the game but nothing else, what exactly is it supposed to do?

I did modify this part, seems consoleInit() was not declared in the header file so I added it. and had to remove the snap toggle since is was declared as a function above this part.

void GameTSCtrl::consoleInit()
{
Con::addCommand("snapToggle", cSnapToggle, "snapToggle();", 1, 1);
+ Con::addCommand("GameTSCtrl", "getMouse3DVector", cGetMouse3DVector, "GameTSCtrl.getMouse3DVector();", 1, 1);
+ Con::addCommand("GameTSCtrl", "getMouse3DPosition", cGetMouse3DPosition, "GameTSCtrl.getMouse3DPosition();", 1, 1);
}


Is there supposed to be a script function that gets activated to set the masks and get the data?

#18 These Con::addCommand lines need to be converted to the new ConsoleMethod style,
I don't know enough about it to suggest how exactly that needs to be done.
I do know that if you don't use a ConsoleMethod that fits, these functions won't be
accessible from the script. I've run into this problem with several resources and I would
definitely be interested if anybody has a link to any resources that explain how to convert
the old Con::addCommand's into ConsoleMethod's...just a breakdown of how the arguments
to ConsoleMethod correspond to the variables in Con::addCommand would be terrific.

#19 They're the same arguments.

ConsoleMethod(GameTSCtrl, const char*, getMouse3DVector, 1, 1, "() - Get vector of the mouse in 3space.");

I might have the order slightly muddled. A few moments looking at another one should sort you out.