A question for someone who knows a lot about computers:

[TorpX]

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]

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]

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. :06:

[JoeCorrado]

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]

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.

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.


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. :yep:



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]

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. :hmmm:


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.

[TorpX]

Another update:

I changed the turning radius variable from r to rp, and that seems to have fixed the problem. Do computers dislike short variable names? There are other variables with one letter and they are ok. Oh well.

The problem with the sketch window was unrealated. There is an auxiliary window that is used for different calculations. Some are related to the solution, some are entirely seperate. A couple of these functions used the Abg (angle, bearing) variable and would overwrite the value that the sketch function used. This would mess up the sketch when it was done after the aforementioned aux. functions. I renamed the variables to fix this.

After banging my head against the wall, I feel almost euphoric now. :yeah:

[JoeCorrado]

LOL - computers can be tough to communicate with sometimes. They always have to have things their own way for some reason. I am happy that you tamed the beast! :up:

When I was programming, I always used a naming convention for variable types to help me keep track of them all- something I learned way back when cutting my teeth using Q-Basic. Helps with debugging.

In my experience, single character variable names should be avoided, but hey- it's all just part of the fun!

[TorpX]

LOL - computers can be tough to communicate with sometimes. They always have to have things their own way for some reason. I am happy that you tamed the beast! :up:


So true. :yep:

[Pisces]

While I don't know anything about Liberty Basic, programing languages usually have a very similar syntax....

We might be of some better assistance if we can view the source code. Otherwise we're just shooting in the dark. And my magic orb is undergoing maintenance.

What JoeCorrado said: output every calculation step or variable change. Including your own input given to the program. Preferably saved into a log file for future reference.

[TorpX]

The problem with the changing value of the turning radius seems to be fixed now. Changing it from "r" to "rp" did the trick. I won't pretend to know why.

This app is 97% done now. I have only to make final display tweeks, write up the help file(s) and assemble a tutorial. I am anxious to get it done, as I have been having trouble with the operating system, off and on, for weeks, and want to do a complete system restore (only after this is finished).

I appreciate your help, and hope you will take it out for a test drive when it done. :salute:

[Webster]

The problem with the changing value of the turning radius seems to be fixed now. Changing it from "r" to "rp" did the trick. I won't pretend to know why.

This app is 97% done now. I have only to make final display tweeks, write up the help file(s) and assemble a tutorial. I am anxious to get it done, as I have been having trouble with the operating system, off and on, for weeks, and want to do a complete system restore (only after this is finished).

I appreciate your help, and hope you will take it out for a test drive when it done. :salute:

not to put clouds on a sunny day but I did similar and found issues with some of my mods I was working on because things changed so before you put too much work into it you might want to be sure the computers working correctly so you know your work is working correctly too.

[TorpX]

I get what you're saying, but the project is very nearly done now. In any case, it is not a mod of SH4 as such, but rather a math utility to calculate a torpedo firing solution. It doesn't receive inputs from the game, nor pass any information to the game directly. I have been using the game to "field test" the math.

I am a little concerned about whether it will work on other operating systems (I have Vista), but it should work on anything older than Vista ok. There is really only one way to know. If there are problems, I'll have to deal with them as they appear.

I want to get this thing done, because whenever I get distracted, or set it aside, I forget some of the details of what I was working on and it takes awhile to get back into it.

[TorpX]

Just to let everyone know, I finally finished this baby.

It is in the Subsim downloads section, under Utilities:

http://www.subsim.com/radioroom/downloads.php?do=file&id=4236



The main thread and tutorial is in the Silent Hunter 4 section "Algebraic Firing Solution", starting at post #45. Since all the math and screenshots are already there, I will post any updates or answers to questions in that thread.