MarkShot

That's good. I will think about SB4. The thought of blowing sh*t up is so naturally appealing. A day just doesn't seem complete without it.

Well, with SB1 you could save your plans. Even save multiple plans by playing games with files. SBPROPE lacked that, but I assume it got fixed. (It was real pain.) I sold my game at a 50% discount, because ... I liked the game, but was suffering repetitive strain injury. What would be different now? I am not sure, but I have hope ... great if there was demo for me to test with? In 2002, I got Ghost Recon 1 and loved it, but could not play for the same reasons. Hours of pressing things and contorted finger positions. In 2016, I completely redesigned Ghost Recon 1's UI with programming and a gaming keyboard. It is now totally ergonomic. I can play 3-5 hours 15 years older without any stress related injuries. Thus, SB might once again be a game for me. That's my thinking. Nils, will there be a demo? I don't need anything but a single mission which makes the entire in game UI available to test with. Then, I can check for strain, and what programming I can do to avoid it. Thanks.

I played SB1 and owned SB2 for a while before selling my dongle. Here is my question. I only do SP. What is there going to be available in the way of content to give me long term replayability? As I realize that many of the community are former armor or vets and mainly play online. But for me SP ... missions ... variable replay ... randomization are all what makes it a worthwhile investment. Thank you in advance for your response. PS: I have already watched the 7 YouTube video.

Can my codemeter stick/SBPPE license be sold/transferred? Thanks. PS: If you know anyone interested, I would be asking $50 USD for v2.4x which when the upgrade cost is added in is an effective savings of 50%.

This thread is like 80 pages and I admit to being too lazy to read through all of it. May I inquire if the "save plan" feature has been fixed in upcoming paid upgrade? I missed that quite a bit from SB1 and didn't really like having to go into the editor to work around that problem. Thanks.

Unzip and see the readme. Simply run the EXE while playing. It does not need to be placed in any specific location. It interacts with SBPPE at the process (meaning execution) level and not at the file level. I hope that helps.

Done.

He he he ... the AI didn't say "but that looks like a friendly"?! One of my favorite AI fracticide scenes is to pop your uboat's periscope up in the middle of a circle of escorts. They all open up with MGs and cannons while very often shooting the cr*p out of each other. (This is in broad day light on calm seas.) I suppose that's a video game.

Yep. Assuming it was ALT-C. Then instead of sending only "+" to the window, I would send "ALT-C" + "+". This would cause the map to center and zoom in. In fact, it would make it possible for the user to just rock the mouse wheel back and forth, if they only wanted to center the map. So, Nils, did you get to try the EXE yet? I've already written a number of AutoHotKey (www.autohotkey.com) scripts for various games. A most excellent free utility.

Tacbat, Nice concept, but you have to remember that this is a utility that stands alongside SBPPE and not a change to SBPPE itself. So, I am able to know from the window name that the mouse actions are happening within SBPPE. However, I am unable to know whether SBPPE is displaying the map or something else. Thus, any coding I do for the map is active throughout the entire game. Sending right clicks blindly into the game is going to cause all types off problems. This would have been doable if there was a keystroke combination which centers the map and was not overload with any other functionality in the game. Sorry. --- Glad you like it. Most likely you have the final build. I am waiting for a little more feedback and then I guess I will upload it the site. Thanks again for your help.

Well, see your email. I added the autocad support for your own private custom version. That's enough of this for today. Take care.

Forget it. I see your problem. (script in post #8) If you didn't edit your resolution from my script, it was hard coded to work for me at 1600x1200. PM me and you'll get the dynamic resolution EXE. Much more adaptible; you can even change res in the middle of playing and it continues to work.

My initial guess would be that there is something different about how Vista 64 is reporting the screen resolution and/or the mouse position. Top and left are both being tested against zero. Bottom and right are being tested against 1049 and 1679 respectively. You can display a variable while running the script by adding the following line: Msgbox %VariableName% Perhaps this might help you to figure out why the screen bounds testing is not working.

PM me an email address. You can try the latest compiled version and see if you have any better luck.

Nils, In honor of your interest I have added "mouse landing zones". This should be the final version. (see email for where to download for testing)

Did anyone try this with the script I made available above? Interest seems pretty underwhelming. If no one is interested, then I think I will skip the trouble of releasing an EXE only version with map zoom+scroll which dynamically handles any resolution and provides 1/2 screen landing zones on the top and bottom to avoid interference with other elements (menu/units) if the horizontal resolution is 1024 or better. Please advise if you are interested. Thanks.

There are some unintended consequences of using this due to the way it functions which are handy, in fact. (see my comments in the code) After using, I decided to create mouse landing zones at the top and bottom of the screen. This prevents quickly stabbing for the menu at the top or units at the bottom while playing from triggering scrolling. However, after making the above change. It makes it difficult to deliver a dynamic resolution version that is compiled and needs no tweaking by the player. Perhaps, I can simply disable the landing zones if the resolution is below a certain minimum. If it is above the required minimum, then I simply split the width and make the mouse landing zones the top right and the bottom left for scrolling. What do you think? (I'll include my non-dynamic version below for my personal use so that you can see what I mean.) There is also the issue of MP use. This allows the player to crank the turret much more conveniently by pushing the mouse to the edge than by stabbing the keyboard. Some might consider that a cheat. I am hesitant to be the source of "a cheat utility", since I know how MP communities are.

I took a look at it. Boy, did you put those BPs and routes close! I had to get out my electron microscope to analyze it! (One thing I learned from Nils is when you have two routes between the same waypoints to add an extra vertex in each so that you put some daylight between them.) A very clever solution. You effectively used the BPs to store state information. Thanks for sharing it.

I have taken it to yet another level. I now have a version that: (1) Does all the above. (2) Dynamically responds to whatever resolution is used. You change the resolution in the middle of running SBPPE. (3) The code is compiled. Just run a 200K EXE and you have mouse support in the map. I plan to release to the site downloads after I get some people to test it.

Yes, that was my intent.

ZOOM + SCROLL !!!!! Okay, working and tested. Very enhanced mouse support in the map. Note1: You'll have to modify your script to correspond to your playing resolution. Yes, I know there must be a function to check the screen resolution, but I am doing this for myself and just making it available to others as a courtesy. Note2: The code is not the most elegant. Clearly, I should have used an additional subroutine. But I am only started learning this utility/language yesterday.

Sorry to not take your request, but I am coding for ME! However, if just got the basic code structure working to scroll the map when you push the mouse to the screen edge. I have to go out, but I will finish it up later today and post after some more testing. The only issue I see is for people with a single processor and poor performance. This might eat into their FPS. I have four processors and I am running SBPPE and AutoHotKey on different processors. Later.

My next upgrade to mouse support will be to make the map scroll by pushing the cursor to the edge of the screen. This will push my scripting with this utility to the next level. OTW!

Here is a hot tip for everyone who wanted to use the mouse wheel in the map screen to zoom in and out. Yes, ESim it is almost 2010 and all G*d's children have mouse wheels these days. Download this free utility: http://www.autohotkey.com/ Create the following script file "MouseZoom.ahk": My formatting will probably be lost above, but it does not really matter. Now, before playing launch the script by double clicking on the file. (You can create a shortcut to the file if you like.) This will have no impact on any other programs as it only activates when you are SBPPE. When you are not playing, you can shot down the utility from the System Tray. It will be the green icon with an "H". Have fun!