Not a Known ANW Issue #01 or How to build AIP Submarines (Full Version)

All Forums >> [Current Games From Matrix.] >> [Modern] >> Harpoon 3 - Advanced Naval Warfare



Message

Bucks -> Not a Known ANW Issue #01 or How to build AIP Submarines (6/6/2009 7:41:31 AM)

This is a response to one of Herman's "Known ANW Issues" - It has been "introduced" since the release of the ANW 3.9.4 update...

quote:

7. AIP endurance shows 4%

Unit display shows endurance at 4% even though it should be at 100%


Well maybe, and maybe it might be related to all AIP capable submarines included in the PDB and the way they are constructed. I've downloaded the [PDb] AIP endurance shows 4% (3.9.4).scn file and immediately noticed that there was an issue with the Sub's unit display.

The U 31 Type 212 DE 05 SSK is only displaying two types of fuel values, Fuel: and AIP Time:. The issue here is that the submarine is still a conventional Diesel/Electric boat, with the added capability of recharging its batteries while submerged through the use of the AIP system. Ufortunately every PDB AIP capable submarine is missing the electric/battery components of this relatively new system.

The screen capture below shows the lack of an electric propulsion system and associated battery fuel. I will then show the submarine's DB profile from the RE along with a set of screen captures illustrating the correct configuration for AIP submarines.

Cheers

Darren



[image]local://upfiles/21733/E5417E38957B4010B6D3DDFD26AED7A1.jpg[/image]



Bucks -> RE: Not a Known ANW Issue #01 (6/6/2009 7:45:17 AM)

Ok the RE shows why the report is incorrect (not a game engine issue) as the real problem is the propulsion configuration of Players DB AIP subs.

I've made notes on this screen capture and will then add more from the HUD3 displaying the correct propulsion configuration for AIP Subs.

Cheers

Darren



[image]local://upfiles/21733/8FB08177D751408D81A6362632A66D65.jpg[/image]



Bucks -> RE: Not a Known ANW Issue #01 (6/6/2009 7:47:16 AM)

PDB AIP Sub Fuel loads:



[image]local://upfiles/21733/E9FAF7E5E15549B8BCE42B52DAA5B3A6.jpg[/image]



Bucks -> RE: Not a Known ANW Issue #01 (6/6/2009 7:49:02 AM)

Now here are two examples of AIP subs using the HUD3. Infact these are the only two AIP subs I've added so far.



[image]local://upfiles/21733/4BA807DF39BC4EFB8A8E4E79A4999904.jpg[/image]



Bucks -> RE: Not a Known ANW Issue #01 (6/6/2009 7:50:55 AM)

And example Two showing the same configuration and differing AIP times.



[image]local://upfiles/21733/E35F193CE1524DA58A87FB4BD4AD59E7.jpg[/image]



Bucks -> RE: Not a Known ANW Issue #01 (6/6/2009 7:54:22 AM)

Here's the relevant details from the RE showing how AIP subs should be constructed as well as the correct AIP fuel units to use. Set of two screens follow.

Cheers

Darren

I hope we can see this issue closed as I don't believe it has anything to do with the Game Engine or coding but is a database configuration issue.



[image]local://upfiles/21733/A91AA3B45FE24B90B68398C728AD8D35.jpg[/image]



Bucks -> RE: Not a Known ANW Issue #01 (6/6/2009 7:55:26 AM)

Screen Two

[image]local://upfiles/21733/DC747CE4C86444C8A216B3A2F8620695.jpg[/image]



hermanhum -> Undocumented Feature (6/6/2009 7:30:31 PM)

quote:

ORIGINAL: Bucks

The U 31 Type 212 DE 05 SSK is only displaying two types of fuel values, Fuel: and AIP Time:. The issue here is that the submarine is still a conventional Diesel/Electric boat, with the added capability of recharging its batteries while submerged through the use of the AIP system. Ufortunately every PDB AIP capable submarine is missing the electric/battery components of this relatively new system.

The new changes will be implemented in the next PlayersDB release. Thanks for the explanation.

I concur that this isn't a Game Engine issue. It's a Game Documentation issue. This is (at least) the third instance of Undocumented Features causing end-user misunderstandings. I've looked in the:

a) AGSI wiki,
b) Release notes, and
c) eManual

There doesn't seem to be any public way to find out about these changes. Am I looking in the wrong places?

In fact, after the explanation, three problems have been taken off the List of Known Issues:

  • AIP Endurance same at Full and Flank speed

    Full speed has 343:20hrs, and Flank speed has 343:20hrs, too

  • AIP endurance shows 4%

    Unit display shows endurance at 4% even though it should be at 100%

  • Unable to switch off AIP

    Sub has a diesel engine and fuel, but is unable to utilize either when run at Periscope depth after AIP fuel is exhausted
    •



    Bucks -> RE: Undocumented Feature (6/7/2009 2:47:12 AM)

    quote:

    ORIGINAL: hermanhum

    The new changes will be implemented in the next PlayersDB release. Thanks for the explanation.

    I concur that this isn't a Game Engine issue. It's a Game Documentation issue. This is (at least) the third instance of Undocumented Features causing end-user misunderstandings. I've looked in the:

    a) AGSI wiki,
    b) Release notes, and
    c) eManual

    There doesn't seem to be any public way to find out about these changes. Am I looking in the wrong places?


    You're correct, there's no documentation to be found, I even went back to the Harpoon 2 manual to find what I could:

    quote:

    Air Independent
    This propulsion is used primarily on submarines. Air Independent functions as a diesel engine at Periscope and Surface depths, and burns stored oxygen at lower depths. The unit upon which this propulsion is placed must rise to Periscope and Surface depths to recharge its oxygen supply. Air Independent propulsion uses Diesel and Air Independent fuel types.


    Maybe you had looked this over as well, seeing as you had the PDB Submarines configured this way. In effect the two fuel types listed are simply those the AIP system can actually utilise, not the only two the Submarine should carry. A little further on the H2 manual points to the following fuel capacity guidelines and useage which is basically where I began researching this subject:

    quote:

    Some Capacity Guidelines

    The following list should give some indication of the amounts to use for the Capacity field.

    Batteries - capacity represents seconds of operation at 5 knots.

    Fuel Oil, Aviation Fuel, Gas Fuel, Diesel Fuel (on ships) - capacity represents tons of fuel.

    Air Independent - capacity represents stored oxidizer sufficient to use 1 ton of Diesel Fuel.


    Then I found the fuel consumption figures to base my initial calculations on after some quick research into the RL systems readily available on Wikipedia. Sometimes the best way to get things working is to simply "give it a go" and adjust your figures to take account of observed behaviour. A little like hunting bugs in the code, you apply a process and observe THEN arrive at conclusions based on the known facts and your observed behaviour:

    quote:

    Fuel Type: Diesel and Air-Independent (simultaneously)
    Fuel Consumption
    Cruise: Consumes fuel at rate of 100 * (tons fuel/Endurance)
    Endurance= range (nm) /speed [6 -10] kts
    Tons Fuel = the total fuel capacity of the unit.
    Boost: same as Cruise.

    - Diesel
    A propulsion type for use in both submarines and ships. A combustion engine using diesel fuel. Must be within 20 meters of the surface to snorkel air for the combustion process.

    Fuel Type: Diesel Fuel
    Fuel Consumption
    Cruise: Consumes fuel at rate of 100 * (tons fuel/Endurance)
    Endurance= range (nm) /speed [6-10] kts
    Tons Fuel = the total fuel capacity of the unit.
    Boost: Same as Cruise.


    I've also checked the ANW Database manual and it will need some work to have a correct and relevant explanation of the process of constructing AIP submarines. If you follow it as you may have Herman, you'd simply be back to square one (no electric motor).

    quote:

    5. For submarines using Air Independent propulsion, you need just the AI engine and two fuel loads. One load of diesel as calculated using the same equations as for ships, and one load of air independent fuel of the same amount as diesel. - HP3-DatabaseManual-rev1.2.pdf


    I can see the need for rev 1.3 already. I will at some point in the future set about a corrected version of a DB editing manual shortly. There are many features not covered in the present version of the manual and also stuff relevant to getting the most from the HUD3.

    Cheers

    Darren





    th3flyboy -> RE: Undocumented Feature (6/9/2009 3:18:10 AM)

    Judging by what I see in this thread so far, it's possible that new documentation could take more bugs off that list than already stated by HH. It's possible that out of date docs could be causing more misunderstandings about how things are working, and as such, are causing errors at the DB level, where people think they are at the Engine level.



    Bucks -> RE: Undocumented Feature (6/9/2009 6:45:08 AM)

    quote:

    ORIGINAL: th3flyboy

    Judging by what I see in this thread so far, it's possible that new documentation could take more bugs off that list than already stated by HH. It's possible that out of date docs could be causing more misunderstandings about how things are working, and as such, are causing errors at the DB level, where people think they are at the Engine level.


    You know you might just you be right th3flyboy.

    Although only some people think it's the GE. AGSI did take the forward thinking step of stating there is a DB compliance framework and to avoid these issues following those guidelines might just make a lot of the list disappear and a lot of sense at that.

    Although I doubt that it's "out of date" docs. I found most of the information for the correct construction of AIP subs from the original "in game" Harpoon 2 documentation from the late 90's. It's more a case of assembling the correct documentation and I have started to correct and bring the H2 docs up to ANW spec which I hope to gain Mr Gilman's permission to publish on the HUD3 website in the near future. In fact I have already used quite a few sections of the original manual to track down portions of coding that were not implemented in H2 or H3 but are now functioning parts of the ANW game.

    I've already found at least 2 more "issues" that are based on the values contained in the PDB and will start another thread pointing out where the Editor has "gone wrong" and has incorrect values causing more issues that have been heaped upon the game engine rather than the Editor taking a hard look at his figures. It is of the upmost importance that the compliance guidelines are followed and implemented if these simple issues are to be fixed and the list reduced. I have even had the excuse fired at me that it shouldn't matter what values are used...

    Unfortunately with the limited coding and testing resources available to AGSI, it becomes a question of time and I really don't see my job as correcting the PDB's mistakes. I have myself, had to correct or generate new systems to calculate values as now required for the HUD3 in relation to the DB compliance situation and the changes in the game's performance.

    A perfect example are numerous ECM systems in the PDB that have negative values for their Search Output data and the only interaction this value has in game terms is for ECM detection, i.e. the range at which the ECM system will be counter detected by ESM systems. A negative value in this case has to my knowledge UNKNOWN effects on the GE's resolution and interpretation of this situation. The value should always be positive and is translated to detection range in the same way emitting radar systems are.

    Of course those dealing with this section of game mechanics should have already understood this and looked at their own data before aportioning blame to the game's code. This is of course the reason we have a set of compliance guidelines and why there are at present only two DB's that are officially used for testing and development purposes (the PDB is not one of them).

    Cheers

    Darren




    hermanhum -> Undocumented Feature (6/9/2009 6:54:48 AM)

    quote:

    ORIGINAL: Bucks
    there are at present only two DB's that are officially used for testing and development purposes (the PDB is not one of them).

    Which, of course, explains why no problems involving actual game situations are ever reported for anything except the PlayersDB, since it's pretty much the only one that gets any play due to it's stability and the fact that the scenarios built with it seem to be the only ones actually tested. If AGSI actually had player input instead of just theoretical wish lists, the game would not be in its current state.



    Bucks -> RE: Undocumented Feature (6/9/2009 7:17:49 AM)

    quote:

    ORIGINAL: hermanhum
    Which, of course, explains why no problems involving actual game situations are ever reported for anything except the PlayersDB, since it's pretty much the only one that gets any play due to it's stability and the fact that the scenarios built with it seem to be the only ones actually tested. If AGSI actually had player input instead of just theoretical wish lists, the game would not be in its current state.


    Of course the logical end point might just be that the reason the PDB is the only DB reporting errors is that it might be the one DB full of errors or not adhering to the compliance guidelines. Every DB is stable, I have to wonder if your English comprehension is up to speed. Or maybe Herman you're just one of those people who never makes a mistake, good comeback by the way [:D]

    Catch ya on the flipside...

    Darren



    hermanhum -> Undocumented Feature (6/9/2009 9:49:51 AM)

    quote:

    ORIGINAL: Bucks

    Of course the logical end point might just be that the reason the PDB is the only DB reporting errors is that it might be the one DB full of errors or not adhering to the compliance guidelines. Every DB is stable, I have to wonder if your English comprehension is up to speed. Or maybe Herman you're just one of those people who never makes a mistake, good comeback by the way

    Well, that's the funny part. Although the PlayersDB is used as the basis to report most of the bugs, those bugs are replicable in other DBs, too. In fact, of the 212 bugs currently listed on the Known List of ANW Issues, about 150 are verified with files from the PlayersDB. That still means 60 problems found with other databases. Even in the highly unlikely event that the PlayersDB was as buggy as the HUD3 and responsible for all 150 issues, that would still mean a mountain of problems.

    The one logical conclusion is that ANW is a bug-infested mess. However, only folks who actually test would know that. Anyone who truly has a clue as to the state of the game would never utter,

    quote:

    ORIGINAL: Bucks

    Every DB is stable...



    hermanhum -> Undocumented Feature (6/9/2009 6:29:58 PM)

    quote:

    ORIGINAL: Bucks

    A perfect example are numerous ECM systems in the PDB that have negative values for their Search Output data and the only interaction this value has in game terms is for ECM detection, i.e. the range at which the ECM system will be counter detected by ESM systems. A negative value in this case has to my knowledge UNKNOWN effects on the GE's resolution and interpretation of this situation. The value should always be positive and is translated to detection range in the same way emitting radar systems are.

    Yes, this is the perfect example.

    The thread Attention DB Designers: Important ECM Changes is quite clear:

    quote:

    ORIGINAL: VCDH

    I haven't tried negative values yet (which would be useful against less capable phased array radars)

    I did try them and found them much more useful than the positive values. Looks like this is just another case of "Those who do not follow the HUD3 must be wrong" mentality. At least this one had documentation.

    Reading the fine print can save you from future embarassment.[:D]



    Bucks -> RE: Undocumented Feature (6/9/2009 9:12:23 PM)

    But has anyone tested these values aginst visual sensors? I've looked at one of your listed problems; to me there seems a real relationship between some DB values and your "report".

    Just because an experiment proves your point once, does not mean it becomes the truth. I've got some past experience in that so trust me.

    Dale said he had not tried them, you can't see my name on the thread can you? Don't try to blame AGSI for poor documentation then what blame me for not reading it? Get serious Herman. You did try negative numbers... Although the new ESM system is limited by horizon range and the two values used are Search Output for counter detection and Track Output for self protection combat resolution modification. The only other characteristic taken into account is the "phased array" rafar flag that applies a modifed jamming effect to radars so flagged

    Exactly how are the negative numbers more effective, please explain yourself? What did they produce and where did you document your findings? The number (search output) is used to determine the range at which the emitting jammer can be detected. Not the range at which the system jams. You and Dale can work that one out, I'll stick with what I know works. Personally it kinda sounds like that's a fairy tale or you need to add another "bug" to your list.

    Sorry have 3.10 work to do, this and you become tiresome.

    quote:

    Looks like this is just another case of "Those who do not follow the HUD3 must be wrong" mentality. At least this one had documentation.

    Reading the fine print can save you from future embarassment.


    Where did I say I had that mentality, the discussion was in regard to how the system works, not which DB it was implemented in. I have documentation, and since I know my jammers work, how could I be embarassed? Herman be careful I don't take a microscope to that PDB of yours, might want to rethink the advice, take care out there now.


    Cheers

    Darren [8D]





    hermanhum -> Undocumented Feature (6/9/2009 9:19:54 PM)

    quote:

    ORIGINAL: Bucks

    Just because an experiment proves your point once, does not mean it becomes the truth. I've got some past experience in that so trust me.

    Dale said he had not tried them, you can't see my name on the thread can you? Don't try to blame AGSI for poor documentation then what blame me for not reading it? Get serious Herman. You did try negative numbers...

    And therein lies the crux of the matter. You are not the determinant of what goes into a database. No one cares about your approval, agreement, or doing things your way. I used the numbers that I liked and they are different from yours. Seems as though the only problem is that no one wants to listen to you or do things your way. Thanks for your input, but I'll continue to use the values I think are best for the PlayersDB.



    Bucks -> RE: Undocumented Feature (6/9/2009 10:20:07 PM)

    Herman if your values don't fit the guidelines of the values the coding handles, pull your list down and go away, thanks for the admission you have no idea what your doing.

    Seach output - Used by ESM systems to detect active radars or ECM systems. This is a positive number as it represents the output power of either a radar system or ECM system.

    Here's the basis for my model:

    Radar Search Signal/ECM Output is expressed as a log of the peak output power in watts.

    To calculate the number for this field use the following formula: 100*LOG10 (Peak output in watts). If peak output in watts is not available, use twice the average output. I use an identical system so jammers fit the ESM detection modeling.

    I'll pick the PDB Caiman OECM Sensor #756
    SEARCH OUTPUT = -250

    Since we're using a Logarithmic scale how do you arrive at a negative value?

    100 * LOG10( X ) = -250

    What value is X

    LOG10(-1) = ERROR

    Anyway back to work...

    Thanks

    Darren



    hermanhum -> Undocumented Feature (6/9/2009 10:30:10 PM)

    quote:

    ORIGINAL: Bucks

    Herman if your values don't fit the guidelines of the values the coding handles, pull your list down and go away, thanks for the admission you have no idea what your doing.

    Rubbish.

    You the ECM value should have absolutely no effect on any visual sensor. The Visual Light bandwidth isn't even selected for any of the ECM systems. If they are somehow exerting an effect on the Visual sensors, you've got some majorly bad things going on. It would be like saying Radar has some effect on Sonar.

    Utter rubbish.



    Bucks -> RE: Undocumented Feature (6/9/2009 11:16:57 PM)

    HERE IT IS AGAIN - NOTE VISUAL SENSORS ARE NOT MENTIONED IN MY PREVIOUS POST

    I'm trying to explain how it works, it's not a popularity contest and there is a lot of "under the hood" stuff here. I wanted to ask how you arrived at your values and if they do work, exactly how they are being interpreted by the Game Engine. Ok it's outside my model and the expected values for use by the GE. If they do work fine but how do these negatives interact with your ESM systems? Don't they have issues detecting a negative output in the case of your ECM as compared to your positive radar output values?

    See previous reply from Herman

    Herman if your values don't fit the guidelines of the values the coding handles, pull your list down and go away, thanks for the admission you have no idea what your doing.

    Seach output - Used by ESM systems to detect active radars or ECM systems. This is a positive number as it represents the output power of either a radar system or ECM system.

    Here's the basis for my model:

    Radar Search Signal/ECM Output is expressed as a log of the peak output power in watts.

    To calculate the number for this field use the following formula: 100*LOG10 (Peak output in watts). If peak output in watts is not available, use twice the average output. I use an identical system so jammers fit the ESM detection modeling.

    I'll pick the PDB Caiman OECM Sensor #756
    SEARCH OUTPUT = -250

    Since we're using a Logarithmic scale how do you arrive at a negative value?

    100 * LOG10( X ) = -250

    What value is X

    LOG10(-1) = ERROR

    Anyway back to work...

    Thanks

    Darren



    FransKoenz -> RE: Undocumented Feature (6/9/2009 11:17:03 PM)

    Just 2 little children who are fighting for a ...........
    PDB [sm=sign0066.gif]

    HUD [sm=sign0066.gif]

    Does anyone understand this whole discussion? It is not about the game, it is about persons.

    The PDB contains all the units I like to put in my scenarios, but I'm not sure about the integrity of this DB
    I'm sure that Darren's DB is well build up with decent calculations, but imho I can't design scenarios with the units available in the HUD.

    I suggest that AGSI [finally] shows up with a DB that satisfies everyone, after all it's their product.

    Now it is a yes-no battle between two grown up persons who fight like little children for a lolly [:(]

    Ciao,
    Frans [aka Taitennek].









    Bucks -> RE: Undocumented Feature (6/9/2009 11:31:29 PM)

    quote:

    ORIGINAL: hermanhum

    Rubbish.

    You the ECM value should have absolutely no effect on any visual sensor. The Visual Light bandwidth isn't even selected for any of the ECM systems. If they are somehow exerting an effect on the Visual sensors, you've got some majorly bad things going on. It would be like saying Radar has some effect on Sonar.

    Utter rubbish.


    No Herman it's not rubbish.

    You have an issue listed that reports a visual sensor being jammed by ECM, I looked at the issue and the DB and I saw the negative values. I immediately had to ask myself exactly what effect a negative output value might have on any sensor, not just visual. The figure in question (search output) is representing transmitted power, and you are representing that negatively.

    I've not tested your issue in depth, time limitations. I'm simply raising a point based on the same questions I apply to all of these problems and my testing. If there are unusual values, we need to establish their effects. This may be important for current development of FCR (Fire Control Radar) handling and yeah you'll moan about yet another change and yes there's work involved, but it makes the simulation even closer to reality. Not only that, if you want to use these values, and they do cause issues if they are able to be worked into the code in the hope of reducing the issues list I'm sure Russell will attempt to achieve that if possible.

    Cheers

    Darren Buckley



    hermanhum -> Undocumented Feature (6/9/2009 11:40:26 PM)

    quote:

    ORIGINAL: Bucks

    HERE IT IS AGAIN - NOTE VISUAL SENSORS ARE NOT MENTIONED IN MY PREVIOUS POST

    Uh, sure they are. It's hard to hide from your own words. Right here:

    quote:

    ORIGINAL: Bucks

    A perfect example are numerous ECM systems in the PDB that have negative values for their Search Output data and the only interaction this value has in game terms is for ECM detection, i.e. the range at which the ECM system will be counter detected by ESM systems. A negative value in this case has to my knowledge UNKNOWN effects on the GE's resolution and interpretation of this situation. The value should always be positive and is translated to detection range in the same way emitting radar systems are


    quote:

    ORIGINAL: Bucks

    I'm trying to explain how it works, it's not a popularity contest and there is a lot of "under the hood" stuff here. I wanted to ask how you arrived at your values and if they do work, exactly how they are being interpreted by the Game Engine. Ok it's outside my model and the expected values for use by the GE. If they do work fine but how do these negatives interact with your ESM systems? Don't they have issues detecting a negative output in the case of your ECM as compared to your positive radar output values?

    See previous reply from Herman

    Herman if your values don't fit the guidelines of the values the coding handles, pull your list down and go away, thanks for the admission you have no idea what your doing.

    Better still, thanks for showing everyone that you have no idea what works and what doesn't.

    I've even made up a little test file with the vaunted HUD3.
    http://www.matrixgames.com/forums/tm.asp?m=1904270&mpage=1&key=&#

    As you can see, even with positive ECM values, the Visual Sensors are able to detect ECM. Now, the only question remaining is whether you are man enough to admit that you have no idea what is going on.

    quote:

    ORIGINAL: Bucks

    Anyway back to work...

    And thanks for clarifying exactly who is responsible for the current horrendous behaviour in ANW.

    [image]local://upfiles/18146/2EF2FD470F534B458975226348923202.gif[/image]



    Bucks -> RE: Undocumented Feature (6/9/2009 11:41:01 PM)


    quote:

    ORIGINAL: Taitennek

    Just 2 little children who are fighting for a ...........
    PDB [sm=sign0066.gif]

    HUD [sm=sign0066.gif]

    Does anyone understand this whole discussion? It is not about the game, it is about persons.

    The PDB contains all the units I like to put in my scenarios, but I'm not sure about the integrity of this DB
    I'm sure that Darren's DB is well build up with decent calculations, but imho I can't design scenarios with the units available in the HUD.

    I suggest that AGSI [finally] shows up with a DB that satisfies everyone, after all it's their product.

    Now it is a yes-no battle between two grown up persons who fight like little children for a lolly [:(]

    Ciao,
    Frans [aka Taitennek].



    Frans you're wrong.

    It's not about Herman or me or the DBs, it's about the game and making sure we minimise the possibility of issues being reported that may easily be rectified by sticking to some common rules for DB Editors. If we all do that we can have 50 DBs and minimise the reports of bugs DB Editors should be responible for having ensured aren't a result of their actions.

    I have to laugh about your comment about not being able to build scens with the HUD3, no I don't have Wonder Woman's famous invisible plane, yet... Freek is on my case to add it, the Golden Lasso weapon's going to be harder to model tho' [;)]

    I'm not sure Freek understood the joke, but I'm sure the US based members of the audience will.

    Take it easy

    Darren




    Bucks -> RE: Undocumented Feature (6/9/2009 11:48:30 PM)

    Congrats Herman, you're learning how to really look for explanations.

    You get how we look at everything now?. You're playing by the rules now, we've established there's an issue independent of search output value. Must be something with the GUI and the ECM active notations being activated regardless of Output and Sensor type.

    Your report was so limited and showed half the issue, you see something pass it on and expect me and Russell to dig for answers, thanks for the help we're getting now. It's starting to work... [8D]

    Cheers

    Darren



    hermanhum -> Undocumented Feature (6/10/2009 12:10:40 AM)

    If you want help or clarification, ask for it.  Arriving with pre-determined conclusions is not productive.  [8D]



    th3flyboy -> RE: Undocumented Feature (6/10/2009 2:19:23 AM)

    meanwhile that song from that video i had to watch in 7th grade comes to mind the one where they sing about the scientific method...

    Anyway, I suggest experimenting with the PDB a little rather than just saying it can't be the db... It's obvious that your overcome with feelings right now, and anyone who has coded C++ or any major programming language can tell you, if you ignore the syntax, bad things happen... It might be a good idea just to test the theories by complying with the actual DB syntax rather than just saying "I'm right you're wrong..."



    hermanhum -> Undocumented Feature (6/10/2009 3:52:05 AM)

    quote:

    ORIGINAL: th3flyboy

    It might be a good idea just to test the theories by complying with the actual DB syntax rather than just saying "I'm right you're wrong..."

    That's exactly what happened... [:D]



    Ron Belcher -> RE: Undocumented Feature (6/11/2009 5:24:21 AM)

    Interesting... [;)]



    Page: [1]

    Valid CSS!




    Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
    3.609375