A question for someone who knows a lot about computers:

TorpX · 10-07-13, 12:32 AM

I have been finishing my application for computing a torpedo firing solution (allows one to manually compute a solution without the TDC). At least I hoped I was close to finishing it. When I recomputed the numbers for a particular set-up that seemed poor, I got a different answer. Going over and re-computing the whole thing over several days I found that I could not replicate the error. That is until I tried to recalculate with SH4 running.

I did 5 short missions. Out of the 5, every one had an error. This was only clear after I shut down the game and recalculated with the same data. In two of the cases, there was an error in the sketch that was easily noticed, but for the most part, the numbers while in error, were not random gibberish.

Anyway, this was a very unwelcome surprise to me. Is there anyone that can shed some light on this?

Nisgeis · 10-08-13, 12:56 PM

Are you saying that when you run your application, it works OK, but then starting SH4 and running it at the same time as the application, makes the application give erroneous information?

Is the error amount the same each time, or does it change if you restart SH4?

What language /engine are you making your application in?

TorpX · 10-09-13, 01:21 AM

Basically yes. I'm using Liberty Basic 4.04, and am running it through the editor, if that makes any difference. The operation system is Win Vista 32 bit, and I have 3 Gb RAM.

Normally, if I intend to do a field test, I will start the editor and run the program before I start SH4. (Most of the work I do with this has been done without running SH4, of course.)

This is what I've discovered so far:

Under the above conditions, I will get errors every time. This can only be confirmed by closing SH4 and recomputing with the same inputs.

If I have SH4, mission paused, and then start the program, it seems to work ok, but if I go back to the game, and want to use the program again, I must restart it again, to have it work properly. I can determine if it is working properly, by running a previously computed problem and checking to see if the results are valid.

If I try to run the calculations again for a particular problem, even the next day, I will get the same errors as before. That is to say, they are not random.

I haven't tried to shut down background applications, or use any special tweeks to free up memory yet.

I thought computers were better than this. I thought the worst that would happen would be one of both programs would slow down a little. Seems strange to me.

JoeCorrado · 10-10-13, 08:23 AM

You could add a few lines of code to output the values received by the program. That would at least tell you if the issue is within the programs functions/processes itself, or if the issue is an error in passing the values to the program. If the values being passed to the program are correct, I would then output the results of each calculation done internally at each step in an attempt to nail down exactly where the errors are being introduced. Does your program establish protected (reserved) memory space upon start up? Most languages will take care of this for you, but I am not familiar with Liberty Basic and it has been a while since I have played with code in any language for that matter. Debugging should be easy enough in any case. Solving the issue after you identify it specifically, well- that can be a whole new type of fun. LOL

TorpX · 10-10-13, 10:19 PM

Quote:

Originally Posted by JoeCorrado

Does your program establish protected (reserved) memory space upon start up?

I don't really know the details of how this works. I had assumed that this was done automatically by the program language itself. If it doesn't, or fails for some reason, I wouldn't know what to do about it.

Quote:

You could add a few lines of code to output the values received by the program. That would at least tell you if the issue is within the programs functions/processes itself, or if the issue is an error in passing the values to the program.

This is a good idea. I more or less assumed that it was one or more math steps that were going wrong.

I was thinking of putting in a feature where you could test it by having a sample problem run and the results checked, automatically. One can do the same thing manually, but this would save time and at least tell you if things are good to go.

Quote:

Solving the issue after you identify it specifically, well- that can be a whole new type of fun. LOL

Yeah, I know what you mean.

I don't feel as bad about it now. I made 7 more "test shots", being sure to start the program after SH4. All were successful, except one where the graphical sketch was wrong. (The numbers checked out ok. I'm not sure what happened on this one.)

Anyway, thanks for responding, Joe and Nisgeis.

TorpX · 10-11-13, 08:26 PM

Ok, I've played around with this some more and I believe I'm zeroing in on the problem(s).

I put in a number of additional lines of code, as per Joe's suggestion to see readouts of all the input variables. There is a text window I use for this sort of thing, so I just had to add the additional variables. Most of the variables are input to the program for each calculation cycle, but some are stored in a file since there is no need to change them most of the time.

There are half a dozen related to torpedo details, tube distance, torp reach, turning radius, etc. I found that when the program malfunctions, the value of r, the turning radius, changes from 310 to 1. These values are stored in a file, and shouldn't change in the program unless you deliberately change them. The others don't change, so why would r change? Beats me.

Even more interesting is that I found out, that it is not the game SH4 that is the cause, but the way I was handling the windows. Normally, when I start this program, I have the editor window, another program window (engine window?), the main window, a text window, and sometimes either a auxiliary window or graphical window. With this gaggle of windows, and SH4 going, I would minimize most or all of these, to reduce the clutter. This seems to be what is "breaking" the program. I can minimize all but the main window. When I do that, any further calculations using r, will be in error. Closing the program and restarting is required to fix it.

There seems to be a separate problem with the graphical window. It will work ok, unless I use the aux. window for a calculation first. Then the sketch will be messed up. I suspect one or more functions in the aux. calculations are overwriting some of the graphical variables. There are a larger number of these, so I will have to go through them and see.

Anyway, the principle problem is the minimizing of the main window. I didn't think this changed the way a computer program works, but apparently it does. I can open another window over it, but I can't minimize it without problems.

10-07-13, 12:32 AM	#1
TorpX Silent Hunter Join Date: Sep 2010 Posts: 3,975 Downloads: 153 Uploads: 11	Tracking Party 1.1 [REL] I have been finishing my application for computing a torpedo firing solution (allows one to manually compute a solution without the TDC). At least I hoped I was close to finishing it. When I recomputed the numbers for a particular set-up that seemed poor, I got a different answer. Going over and re-computing the whole thing over several days I found that I could not replicate the error. That is until I tried to recalculate with SH4 running. I did 5 short missions. Out of the 5, every one had an error. This was only clear after I shut down the game and recalculated with the same data. In two of the cases, there was an error in the sketch that was easily noticed, but for the most part, the numbers while in error, were not random gibberish. Anyway, this was a very unwelcome surprise to me. Is there anyone that can shed some light on this? Last edited by TorpX; 10-24-13 at 07:50 PM.

10-08-13, 12:56 PM	#2
Nisgeis Ocean Warrior Join Date: Jan 2008 Posts: 2,909 Downloads: 77 Uploads: 11	Are you saying that when you run your application, it works OK, but then starting SH4 and running it at the same time as the application, makes the application give erroneous information? Is the error amount the same each time, or does it change if you restart SH4? What language /engine are you making your application in? __________________ -------------------------------- This space left intentionally blank.

10-09-13, 01:21 AM	#3
TorpX Silent Hunter Join Date: Sep 2010 Posts: 3,975 Downloads: 153 Uploads: 11	Basically yes. I'm using Liberty Basic 4.04, and am running it through the editor, if that makes any difference. The operation system is Win Vista 32 bit, and I have 3 Gb RAM. Normally, if I intend to do a field test, I will start the editor and run the program before I start SH4. (Most of the work I do with this has been done without running SH4, of course.) This is what I've discovered so far: Under the above conditions, I will get errors every time. This can only be confirmed by closing SH4 and recomputing with the same inputs. If I have SH4, mission paused, and then start the program, it seems to work ok, but if I go back to the game, and want to use the program again, I must restart it again, to have it work properly. I can determine if it is working properly, by running a previously computed problem and checking to see if the results are valid. If I try to run the calculations again for a particular problem, even the next day, I will get the same errors as before. That is to say, they are not random. I haven't tried to shut down background applications, or use any special tweeks to free up memory yet. I thought computers were better than this. I thought the worst that would happen would be one of both programs would slow down a little. Seems strange to me.

10-10-13, 08:23 AM	#4
JoeCorrado Weps Join Date: Apr 2005 Location: Illinois Posts: 366 Downloads: 176 Uploads: 5	You could add a few lines of code to output the values received by the program. That would at least tell you if the issue is within the programs functions/processes itself, or if the issue is an error in passing the values to the program. If the values being passed to the program are correct, I would then output the results of each calculation done internally at each step in an attempt to nail down exactly where the errors are being introduced. Does your program establish protected (reserved) memory space upon start up? Most languages will take care of this for you, but I am not familiar with Liberty Basic and it has been a while since I have played with code in any language for that matter. Debugging should be easy enough in any case. Solving the issue after you identify it specifically, well- that can be a whole new type of fun. LOL __________________ ============= My Game starts with GFO - Keepin' it real as it needs to be!

10-11-13, 08:26 PM	#6
TorpX Silent Hunter Join Date: Sep 2010 Posts: 3,975 Downloads: 153 Uploads: 11	Ok, I've played around with this some more and I believe I'm zeroing in on the problem(s). I put in a number of additional lines of code, as per Joe's suggestion to see readouts of all the input variables. There is a text window I use for this sort of thing, so I just had to add the additional variables. Most of the variables are input to the program for each calculation cycle, but some are stored in a file since there is no need to change them most of the time. There are half a dozen related to torpedo details, tube distance, torp reach, turning radius, etc. I found that when the program malfunctions, the value of r, the turning radius, changes from 310 to 1. These values are stored in a file, and shouldn't change in the program unless you deliberately change them. The others don't change, so why would r change? Beats me. Even more interesting is that I found out, that it is not the game SH4 that is the cause, but the way I was handling the windows. Normally, when I start this program, I have the editor window, another program window (engine window?), the main window, a text window, and sometimes either a auxiliary window or graphical window. With this gaggle of windows, and SH4 going, I would minimize most or all of these, to reduce the clutter. This seems to be what is "breaking" the program. I can minimize all but the main window. When I do that, any further calculations using r, will be in error. Closing the program and restarting is required to fix it. There seems to be a separate problem with the graphical window. It will work ok, unless I use the aux. window for a calculation first. Then the sketch will be messed up. I suspect one or more functions in the aux. calculations are overwriting some of the graphical variables. There are a larger number of these, so I will have to go through them and see. Anyway, the principle problem is the minimizing of the main window. I didn't think this changed the way a computer program works, but apparently it does. I can open another window over it, but I can't minimize it without problems.