SpudFiles

I get the same behavior with changing the barrel length causing the chamber length to change as well. Went into the configuration panel and toggled the "Chamber volume defined by" variable between "chamber lenght" and "CB", didn't make any difference.

The "some of the numbers being entered backwards" is really wierd. Never seen that before in a GUI.

jimmy101 wrote:I get the same behavior with changing the barrel length causing the chamber length to change as well. Went into the configuration panel and toggled the "Chamber volume defined by" variable between "chamber lenght" and "CB", didn't make any difference.

The "some of the numbers being entered backwards" is really wierd. Never seen that before in a GUI.

I can't reproduce the "numbers entered backwards thing." Not denying it, just saying I can't reproduce... Which usually means that I'm not quite following what ya'll are saying.

That said, I think I've got the first error you mention (barrel bore/length causing other stuff to change) fixed. Had something outside of an if statement that should have been inside it. New executable file has been uploaded although the zipped package hasn't been changed (so just update the executable).

The barrel/chamber causing other things to change is fixed.

To replicate the backward number entry: Go into "chamber is defined by chamber volume" mode. Place the mouse cursor in the chamber volume field and delete all the characters there. Try to type 3 different numbers there...the cursor always bounces out in front of the number just typed so the final number appears backwards.

*blink*

I type "123" and I get "123."

Hummm not sure, maybe your development environment is affecting what you're seeing...I'm on a solid dual core 2 gb mem, XP pro laptop here. It's possible there may be some screen size issues...mine's 1280 x 800.

Here's the field zero'd out with the delete key.



Now simply typing 234 in that order, the following appears:



Weird I know...maybe a clue will make itself known...

I'm getting the same problem. Except it doesn't always enter them backwards. Sometimes it will enter them right, sometimes backwards, and sometimes a combination of the two. For example, I can enter 234 and it will show 423.

The funky number problem

1. Started HGDT v0.4.1
2. clicked calculate without changing anything.
3. Click on chamber length and highlight the number, entered 15
4. calculate
5. changed barrel length to 20
6. calculate
7. clicked on the barrel length box, highlighted the number, type 21, 12 is displayed.
8. calculate
9. Chamber length in box says 12.
10. Select barrel length box, highlight number, type 46. Chamber length now displays 12.01 (Chamber length shouldn't have changed just because I changed the barrel length.)
11. Change the barrel length to 25. Chamber length now says 12. So, the chamber length has been changed by the program from 12.01 to 12.
12 calulate
13. select chamber length, highlight number type 97. Box displays 97.01.

It looks like the new code that links barrel length to chamber dimensions via the CB ratio or chamber volume is doing things when it shouldn't be.

Configuration settings
--------------------------
Temperature: checked
Pressure: unchecked
linear dimensions: unchecked
Projectile mass: ounces
Chamber volume defined by: chamber length
altitude: 0

jimmy101 wrote:The funky number problem

1. Started HGDT v0.4.1

You're a version behind.

That's the one I have and the latest one that's still available on your site. I noticed you didn't increment the version number on your last update.


Edit: OK I think I found the problem. The full package on your site is still at 0.4.1. Your executable however is up to date at 0.4.2.

I've always just jumped on the full package. I assume that's the issue with others as well.

I just checked 0.4.2 and it doesn't have the backward number problem!!

2nd Edit: Opps spoke too quickly. Typing the number worked for a few tries then reverted to the backwards mixed up thing again. This is with 0.4.2.

D_Hall wrote:

jimmy101 wrote:The funky number problem

1. Started HGDT v0.4.1

You're a version behind.

Ah, version control confusion.

I downloaded the version I am using two days ago (Wednesday, April 30).

EDIT: Downloaded 0.4.2 Now I can't get the funky changing numbers.

jimmy101 wrote:

D_Hall wrote:

jimmy101 wrote:The funky number problem

1. Started HGDT v0.4.1

You're a version behind.

Ah, version control confusion.

I downloaded the version I am using two days ago (Wednesday, April 30).

EDIT: Downloaded 0.4.2 Now I can't get the funky changing numbers.

It still happens in 0.4.2. Fiddle with it some, delete the characters with the delete key...sort of comes and goes. I don't get backwards numbers as much as the zero becoming the least significant digit of the number, effectively multiplying the whole number by 10.

OK, a new version online: 0.4.3 both in executable and zip formats. French language pack included.

A few bugs nobody has mentioned fixed.

I believe I've also fixed the "backwards numbers" thing as well.

Looks great!! Everything I've tried has entered and calculated correctly or apparently so.

HGDT is a most excellent tool. It could very well single handedly aid in raising the state-of-the-art for combustion/hybrid design.

starman wrote:Looks great!! Everything I've tried has entered and calculated correctly or apparently so.

HGDT is a most excellent tool. It could very well single handedly aid in raising the state-of-the-art for combustion/hybrid design.

Of course, it sure would be nice to actually have some data to validate it with.

I think it still has some problems with trying to model a 1X gun (burst disk pressure is the ammo's static friction).

I think it still has some heat loss issues. If you model a grossly oversized chamber on a barrel it gives results similar to a pneumatic. That is, it doesn't show the "mine sized" chamber afffect. Of course, I don't think there is any actual data supporting the "mine sized" chamber affect.

jimmy101 wrote:Of course, it sure would be nice to actually have some data to validate it with.

Thus why we're in beta.

I think it still has some problems with trying to model a 1X gun (burst disk pressure is the ammo's static friction).

Can you elaborate? Not arguing, just asking for clarification.

I think it still has some heat loss issues. If you model a grossly oversized chamber on a barrel it gives results similar to a pneumatic. That is, it doesn't show the "mine sized" chamber afffect. Of course, I don't think there is any actual data supporting the "mine sized" chamber affect.

Ditto.

I'm not sure what "mine sized" means, but if it means "very very large, like the size of a mine shaft" then heat loss WILL be negligable and the gun WILL act very much like a pnuematic. That's just a consequence of the square/cube law. The larger the volume, the lower the surface area / volume ratio. The lower the surface area / volume ratio, the slower the temperature decay (since thermal loss is a function of surface area while thermal inertia is a function of system volume). The slower the temperature decay, the more it'll act like a pneumatic.