Editing KeyComm
Jump to navigation
Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
− | |||
− | |||
From http://orbit.m6.net/Forum/default.aspx?g=posts&t=17569 | From http://orbit.m6.net/Forum/default.aspx?g=posts&t=17569 | ||
We needed a way for a ship (or the Targetting MFD we made) to communicate with turret to tell it to pick up a target, start firing, stop firing, etc. The initial plan was to obtain the vessel pointer, cast it to a Turret, and call a method specifically. However, this has several undesired properties, such as requiring the calling MFD or ship code to include the turret header, etc, and thus isn't very extensible. Additionally, if we attached something other than a Turret (say for a fighter-type craft, where you have a missile directly attached to the ship), the object wouldn't cast nicely to a Turret. | We needed a way for a ship (or the Targetting MFD we made) to communicate with turret to tell it to pick up a target, start firing, stop firing, etc. The initial plan was to obtain the vessel pointer, cast it to a Turret, and call a method specifically. However, this has several undesired properties, such as requiring the calling MFD or ship code to include the turret header, etc, and thus isn't very extensible. Additionally, if we attached something other than a Turret (say for a fighter-type craft, where you have a missile directly attached to the ship), the object wouldn't cast nicely to a Turret. | ||
− | Thus, we needed a function that's part of the normal | + | Thus, we needed a function that's part of the normal VESSEL or VESSEL2 class that we can overload to serve as our messaging function. clbkConsumeBufferedKey works very well for this purpose--it takes as parameters a DWORD, a boolean, and a char*, and returns an int. Normally, the DWORD parameter will not be greater than about 0xDF (the highest OAPI_KEY_xxx constant), and since there's 64 bits in a DWORD, that gives us about 18,446,744,073,709,551,000 possible messages we can send to this function that won't be misinterpreted as keyboard input. More concretely: |
The MFD and the turret both define a constant COMM_SET_TARGET to be some number greater than 0xFF. The MFD asks the user to input the name of the ship to target, obtains the turret's VESSEL pointer, casts it to a VESSEL2*, then calls | The MFD and the turret both define a constant COMM_SET_TARGET to be some number greater than 0xFF. The MFD asks the user to input the name of the ship to target, obtains the turret's VESSEL pointer, casts it to a VESSEL2*, then calls | ||
Line 11: | Line 9: | ||
where the boolean (here false) doesn't actually matter and name is the char * pointer that is the name of the ship to target. This function will return an int; <= 0 indicates failure and any other value indicates success. The turret has included a case for COMM_SET_TARGET in its clbkConsumeBufferedKey function which obtains the target vessel's handle from the name and initiates the target tracking process to point itself in the right direction. | where the boolean (here false) doesn't actually matter and name is the char * pointer that is the name of the ship to target. This function will return an int; <= 0 indicates failure and any other value indicates success. The turret has included a case for COMM_SET_TARGET in its clbkConsumeBufferedKey function which obtains the target vessel's handle from the name and initiates the target tracking process to point itself in the right direction. | ||
− | As long as the sender and receiver both know the message number, this will work, and it'll work well. For a ship that isn't expecting messages, nothing will happen, and since the constants chosen are high enough, you aren't limiting keys you can read. The only place it will fail is if the target ship is a VESSEL instead of a VESSEL2, and in that case you could check that and prevent the cast/call. | + | As long as the sender and receiver both know the message number, this will work, and it'll work well. For a ship that isn't expecting messages, nothing will happen, and since the constants chosen are high enough, you aren't limiting keys you can read. The only place it will fail is if the target ship is a VESSEL instead of a VESSEL2, and in that case you could check that and prevent the cast/call. |
Line 92: | Line 90: | ||
Note that there is still no prefix handled here, but this demonstrates how the "payload" can be used to return a value other than an int to the sending ship. | Note that there is still no prefix handled here, but this demonstrates how the "payload" can be used to return a value other than an int to the sending ship. | ||
− | |||
− | |||
− |