RE: Problem

RE: Problem (Full Version)

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

Message

noxious -> RE: Problem (2/19/2009 8:30:48 PM)
quote: What will be the default settings out of the box will be up for a poll or three held on the forums. 5 or 6 people do not make a majority. Glad to hear you say so, as I totally don't agree bomb range calculations should be optional : they're the realistic option and should be the default. It's about time that the inertia of hundreds of old scenarios stop being used as a reason not to change anything : a dangling, damocles sword always over the devs... A few people are confusing their personal investment of time and skills with what's better for the sim. If any scenario is so closely tied to a particular implementation, one might ask about the validity of the scenario in the first place (not saying that's the case, just raising a point. But, no doubt, I'll be shot down for that too: if you don't agree with Herman & co, or AGSI, you don't have a voice atm, or can't be heard for the surrounding noise) Having bombs behave as in reality is a plus for me, and it shouldn't be an issue. I truly hope this feature is properly developed further, with appropriate flags in the DB for high drag and other aerodynamic aspects, etc. so that bomb ranges not only vary with launch altitude, but also the flight envelope of its casing. Whining that it makes it possible to attack from outside the SAM defense coverage is not a bug : it's modelling reality in certain cases. Using this to underline a certain trend, or undercurrent that seem to prevail in all dealings between the community and AGSI. I'd venture to say that now is the time to break free from the past, and not wish for wholesale backwards compatibility : the good scenarios and DBs will find loving hands to take care of them. There is no absolute need for them to be all available in ANW from the get go, or automatically translated. It's totally unrealistic to wish for such backwards compatibility, as a lot of those classic scenarios include numerous workarounds of their own to overcome engine limits at the time, as well as mostly undocumented DB hacks (the fact that all a/c can land on carriers in PDB was only documented, fleetingly so, by Herman when I complained about it) Flame on if you have to. The only way to move forward, people seem to forget, is to let go and break stuff. There is no way around that, period. Yes, mistakes have been made, yes I'm also unhappy with the current state of ANW, but the vocal minority is taking up way too much space and polarizing the debate in a AGSI vs Them (not us) battle, where only their very personal interests are represented, not the common good as they like to think. The argument about the hundreds of scenarios that could be left behind because of changes is passe and dead stupid when we're talking about adding realism to a game/sim... (and yes I'm going to take a ton of flak from both people I don't know and my harpoon buddies, I bet on this one ;)) You guys clamoring for backwards compatibility to boot, already have legal copies of 3.6.3, so you can play those scenarios with AI intact as much as you want. The way it's going, you want 3.6.3 with MP. You've been told again and again, it's not going to happen. Get over it already and let's work on the future :) Special note to Herman : You know I like and respect you (went so far as to vote for your as Pooner of the year, remember ?), but I'm considering reducing my very limited involvement in ANW vs public forums to nothing. I'm tired of having to wade through litteral tons of your vicious ranting to find the elusive needle of good data in the haystack (hint, more often than not, NOT in your posts nowadays) You don't want to beta, fine, we know. Could you stop telling us that little fact and the countless others you're so keen on repeating ? For someone who refuses to beta-test, and thus be part of the solution, your attitude makes it hard for anyone else to have any pleasure in trying to move things forward. I know for a fact I'm not the only one who's disturbed by your incessant rantings and your co-opting if not outright derailing of most if not all threads where Russell, the only regular AGSI contact we have, shows himself around here. With 2 or 3 guys acting like that you know what happens ? Yes, you have it on the tip of your tongue : the old situation with AGSI and ANW, with multi tiered closed betas, and a closed content management group, whatever it was called. You want people to be responsible, in this case, show the example and start with yourself. Or please, STFU : I also paid for ANW, and I've had enough of you holding us hostage in your vendetta against AGSI. Sorry for using some strong words, but I've refrained myself long enough from addressing this (litterally months) You're not just "hurting" AGSI or Matrix with your demeanour, you're also affecting us, the community for which you so often posture as championing. [end of special note to Herman] Food for thought, I hope. Now, I crawl back in my hole :) (incidentally, my hole is in no way financed by AGSI or Matrix Games, I have no vested interest, financial or otherwise, in either company, beyond wishing they keep on doing what they do ;))

hermanhum -> Problem (2/19/2009 9:17:35 PM)
quote: ORIGINAL: noxious I totally don't agree bomb range calculations should be optional : they're the realistic option and should be the default. It's about time that the inertia of hundreds of old scenarios stop being used as a reason not to change anything : a dangling, damocles sword always over the devs... A few people are confusing their personal investment of time and skills with what's better for the sim. [snip] Having bombs behave as in reality is a plus for me, and it shouldn't be an issue. I truly hope this feature is properly developed further, with appropriate flags in the DB for high drag and other aerodynamic aspects, etc. so that bomb ranges not only vary with launch altitude, but also the flight envelope of its casing. Whining that it makes it possible to attack from outside the SAM defense coverage is not a bug : it's modelling reality in certain cases. Since you chosen this feature as an example of realism, allow me to fill in a few details that you obviously are unaware. With this new ballistic bomb drop calculation, you can have your aircraft cruise (500kts) towards the target, then instantaneously accelerate to Afterburner (1300kt) and flick-release your bombs towards the target from a distance of over 13nm. If you think that is realistic, that's certainly your choice. I don't know of any attack profile that allows for bombs to be delivered on afterburner, but I could be mistaken. Another fact that seems to have overlooked is that I never complained about it. I resigned myself to it as a new feature. It isn't listed as a bug anywhere because it was a deliberate implementation by AGSI. So, even though I may not have liked it, I did simply keep quiet and accepted it. The second issue is the claim that everything must work as H3 did. That's not quite true, either. This thread, alone, is evidence enough. The problem with "6.8.2 Weapons Free or Weapons Tight" comes from the game not doing what is explicitly claimed in the ANW eManual. It just happens to coincide with what actually worked in H3. Most of the complaints appear as though there is a desire to maintain status with H3 only because the H3 worked as opposed to the current situation in ANW. If ANW actually worked (even in its own way), those complaints would likely cease. Another example of this is the Navigator function. It works fairly well in H3, but is unable to execute some of the most basic calculations in ANW.

CV32 -> RE: Problem (2/19/2009 9:27:19 PM)
quote: ORIGINAL: hermanhum I don't know of any attack profile that allows for bombs to be delivered on afterburner, but I could be mistaken. Dropping bombs while using the afterburner wouldn't be the problem. Dropping them at supersonic speed might be, but even that's sometimes possible. The F-111 could (can, for our Aussie friends) do it. And I suspect you've heard that the F-22 did it fairly recently with an SDB dropped from the internal weapons bay. My contribution to the discussion, such as it is. [8D]

hermanhum -> Problem (2/19/2009 9:34:53 PM)
Looks like another *.opt file [:D] AussieF-111SupersonicBombDrop.opt

FreekS -> RE: Problem (2/19/2009 10:22:43 PM)
quote: ORIGINAL: noxious Having bombs behave as in reality is a plus for me, and it shouldn't be an issue. I truly hope this feature is properly developed further, with appropriate flags in the DB for high drag and other aerodynamic aspects, etc. so that bomb ranges not only vary with launch altitude, but also the flight envelope of its casing. Whining that it makes it possible to attack from outside the SAM defense coverage is not a bug : it's modelling reality in certain cases. Noxious, I have requested Russell to make the alternate bomb ranges optional and not default not because they break scens, but because they are unrealistic. Basically at vLow ans Low alt the bomb range should be 0nm (allowing point defense guns to bear on the attacking plane). Today they cannot be set lower than 2nm. Likewise at vHigh/burner they are 12nm which is way longer than ballistic and also does not give an immense penalty in Pk (as far as I know). If the feature is developed further to realistic ranges and Pks linked to altitude and speed as well then I'm fine with the feature. And anyway, you can still switch it on if you want to in 394. Tested drop ranges of bombs. >> Vulcan and 454kg bomb (nominally 2nm in DB) >> >> alt speed range >> ---------------------------------------- >> 31m 580 (cruise) 2nm >> 2001m 570 (cruise) 3nm. >> 7501m 560 (cruise) 5nm >> 19810m 543 (cruise) 8nm >> >> and these: >> F16 990knots (burner), vHigh alt: 12nm Note the RL Vulcan attack on Stanley was made from 10000ft (3000m) with 2nm forward drop of the bombs. Freek

hermanhum -> Problem (2/20/2009 12:01:11 AM)
quote: ORIGINAL: rsharp@advancedgamin 3.10, which has been in the works for a while, has a feature called mission parameters. This allows the user to edit several variables on a per-mission basis. The parameters control such things as airgroup size, standard submarine speed, EMCON, target priority, and other factors of doctrine. These parameters, once set, will be part of the mission data. When the scenario designer has set them they will stay set for sides played by the AI. My solution is to take this a bit farther and allow the user to edit mission defaults (and non-mission defaults). I can find the points in the game engine that collectively define the ROE. Then I can connect those points to the mission parameters and they will be user configurable. Now, what exactly will the user see? At the moment I'm thinking a new dialog with a list of Yes/No questions. Should a platform engage incoming missiles? Should a platform engage contacts intercepting craft on a mission they share? Etc. So a user that is happy with or does not care about the ROE can carry on without any new dialog in his way. They will see two options, Weapons Free and Weapons Tight. Those that want a different ROE behavior can edit those two ROEs. There seems to be a lot of interesting new ideas in this new mission parameter setup. It also share some of the limitations faced by the .opt arrangement. Overall, it is good to see that individual settings can be specific to each side and mission. Some concerns that come to mind with the issue of parameters are: The Map Pref window is a good dialogue example. Instead of a Yes/No question, a simple checkbox is sufficient. Once a parameter is set, it is good to see that is should stay set according to side and mission. This is, IMO, superior to the .opt arrangement which sets (or re-sets) a behaviour globally for an entire scenario. With all these new parameters, the user is probably going to need more information on his Map. For example, if planes can have both Weapons Free and Tight settings, he is going to need to quickly differentiate between them on his tactical display without the necessity of constantly calling up Preference menus. How are parameters to be determined when none are initially present? This problem will be common to all pre-3.10 scenarios. One possible solution is through the use of a file such as MissionDefaultWeaponsFree370.opt (included with the 394 patch). This file re-sets all sides to Weapons Free when the Battleset Re-build command is issued. The problem with this file is that it is indiscriminate and it overwrites some scenarios that might actually need to start with Weapons Tight. Also, a file such as this has no specific value setting that might need to be associated with future parameter (i.e. airgroup size). I think that this process could work so long as there is an initial check like, "Do not overwrite parameter if pre-existing parameter is present." Storage of scenario parameters A major concern voiced over the use of .opt files was that they are global in nature. With many users each having their own personal parameters multiplied by the potential for different specific parameters between individual scenarios, this is a daunting obstacle. I think that a mechanism already exists in the form of the Weapons Edit Export function. This function saves all the specific ammo loadouts for every scenario and is truly a powerful tool. Although it took two years to become fully functional with Patch 3.9.0, it serves its purpose admirably. If mission parameters could be viewed in the same manner as 'ammo loads' within a scenario, then this command could be used to export those settings to a file not unlike the current .sem files. In this way, all settings could be preserved as new patch versions are released without fear of any settings being lost. This ensures compatibility in the long-term. Once a setting is determined, it stays set until the author decides to change it. Also, instead of just having the various .opt files appearing in the message log when a scenario is loaded, the message could also display the parameters that the scenario was originally written under. This way, every user can know if he is playing it in the manner originally intended by the author. He can always ignore them (i.e. activate nukes in a scen meant for conventional arms), but at least he will see what the original settings were. This would sure satisfy all parties equally and allay any fears of mis-matched settings while continuing to respect individual player wishes. quote:* ORIGINAL: rsharp@advancedgamin What will be the default settings out of the box will be up for a poll or three held on the forums. 5 or 6 people do not make a majority. Unless they are called a CCC... [8\|]

rsharp@advancedgamin -> RE: Problem (2/20/2009 6:14:00 AM)
Current Implementation Currently the mission parameters will be edited, imported, and exported using ini format files. There a set number of mission profiles (a group of mission parameters) that define the default settings for the different sorts of missions you are familiar with. i.e. ASW Patrol, Ground Strike, Electronic Support, etc. The user will be able to make their own mission profiles and optionally inherit a default mission profile. This inheritance means the new profile uses all the default parameters and allows the editor to override which parameters she wants. Then, in the mission editor, they can select that new profile from a drop-down list. Backwards Compatibility The mission parameters available so far do not overlap with the mission options available in the mission editor. They do affect them however. For example, in ANW the focused strike flag changes the maximum airgroup size from 4 to 24. There is now a mission parameter to set both the normal airgroup size and the airgroup size for focused strike missions. To the heart of the backwards compatibility issue is how to apply this new feature to older scenarios. What I believe will solve it is to allow the editors to edit the actual mission default profiles for themselves. Then on import, the older missions will have these default profiles applied to them as normal. The mission parameters are saved with the mission data in the scenario file (.SCN) so once imported, it is there until the mission is deleted by the game or user. For ROE What I'm considering as well is exposing a limited number of these in a preference dialog. The limited number of exposed parameters would be the ones used to define what is Weapons Free and Weapons Tight. Since these are simple yes/no decisions (checkbox is pretty much standard for such), I feel any player (noob or vet) can handle them easily without digging through text files. These settings would apply to any craft on a human controlled side on any mission according to which of the two ROEs are set. But will it work? This feature is not only a scalpel, it is a chainsaw with laser beam teeth with shark teeth on the end of each laser tooth. I assure you houses will be burned and the wrong limbs amputated before your first try is complete. It will take at least a few iterations and possibly different implementations before we get it right. It will give the editors that dare access to inner workings of the missions. When this design is firm and tested I will provide examples of different mission profiles to demonstrate what they can do and provide some popular behaviors. The best case is a feature 95% of the users do not use but all enjoy. The worst case involves super Godzilla with that chainsaw knocking on your door in the early morning to sell you magazines.

rsharp@advancedgamin -> RE: Problem (2/20/2009 6:16:19 AM)
On the launch range behavior for bombs, I'll cover that in another thread. Thanks,

FreekS -> RE: Problem (2/20/2009 8:16:30 AM)
quote: ORIGINAL: CV32 Dropping bombs while using the afterburner wouldn't be the problem. Dropping them at supersonic speed might be, but even that's sometimes possible. The F-111 could (can, for our Aussie friends) do it. And I suspect you've heard that the F-22 did it fairly recently with an SDB dropped from the internal weapons bay. My contribution to the discussion, such as it is. [8D] Brad, In H3/ANW the SDB bomb, which is a guided bomb would be modelled (I believe) in the same way that the LGB precision munitions are. The drop distance of LGB in RC13 does not depend (I believe) on speed/altitude. Only Iron bombs have this optional functionality. Freek

hermanhum -> Problem (2/20/2009 8:39:04 AM)
quote: ORIGINAL: rsharp@advancedgamin Current Implementation Currently the mission parameters will be edited, imported, and exported using ini format files. There a set number of mission profiles (a group of mission parameters) that define the default settings for the different sorts of missions you are familiar with. i.e. ASW Patrol, Ground Strike, Electronic Support, etc. The user will be able to make their own mission profiles and optionally inherit a default mission profile. This inheritance means the new profile uses all the default parameters and allows the editor to override which parameters she wants. Then, in the mission editor, they can select that new profile from a drop-down list. [snip] To the heart of the backwards compatibility issue is how to apply this new feature to older scenarios. What I believe will solve it is to allow the editors to edit the actual mission default profiles for themselves. Then on import, the older missions will have these default profiles applied to them as normal. The mission parameters are saved with the mission data in the scenario file (.SCN) so once imported, it is there until the mission is deleted by the game or user. I want to know if I understand the situation correctly. I believe that if I, as the editor of the PlayersDB, load up the Scenario Editor, I will do so with my personal set of parameters since they are saved in my Harpoon.ini file. If I want to re-build all 300 scens made for the PlayersDB, I will then be setting all their parameters to match my personal settings. If we have 10 different authors with scenarios written for the Players DB, the only way to preserve the individual author settings for their groups of scenarios is to run the Re-build Battleset command 10 separate times and change the parameters in between runs. Is this how it would work or am I missing something? Secondly, would I physically need to load each scenario individually, set the mission parameters for it, then re-save that file before doing the next one or could this be handled with a Batch re-build function? This is because each scenario (or group of scenarios) might have their own particular mission settings.

rsharp@advancedgamin -> RE: Problem (2/20/2009 1:54:47 PM)
quote: I will do so with my personal set of parameters since they are saved in my Harpoon.ini file. No, little to do with the Harpoon3.ini file. Each mission profile is saved in an INI format file such as DefaultPatrol.mps or DefaultStrike.mps (One profile per standard mission type) in the Doctrine folder. The parameters in those files would be applied to missions in scenarios files from before 3.10. That's where the limitation would be. If different authors want different defaults applied to all their pre-3.10 scenarios then they will need special treatment. Scenarios created with and after 3.10 would maintain their existing mission parameters when rebuilding. A possible solution to the limitation would be to use the scenlist.ini to allow the editor to specify a Doctrine folder to be used for each mission or battleset. This would not be an feature available immediately and would be a nightmare to maintain. Given the nature of the default profiles, I would believe you would get all your contributors to agree on one set and apply those to everybody's scenarios created before 3.10. So to summarize: 1. The editor will be allowed to define the default mission parameters using one profile per standard mission type. i.e. DefaultGroundStrike.mps in the Doctrine folder. 2. Scenarios from before 3.10 that are being rebuilt with 3.10 would have the default mission profiles applied to them. 3. Scenarios built in 3.10 and after will maintain their current mission profiles saved in their scenario data when rebuilt. 4. A switch or Rebuild with Scenlist setting may be in order to override point #3 so the editor can apply new default profiles to 3.10 scenario missions. If the contributors do want to have their own set of defaults applied to their pre-3.10 scenarios then you can: 1. Set up a battleset for each of them. 2. Change the Doctrine folder option in the Harpoon3.ini to something like C:\Harpoon3\Doctrine_Ralf 3. Rebuild by Battleset. Somewhat like what you described but the change required is one setting in Harpoon3.ini and the mission profiles saved in individual files. This is an overabundance of configuration available to the user. However, if you are happy with the GE default missions then you won't have to touch them.

hermanhum -> Problem (2/20/2009 8:47:02 PM)
quote: ORIGINAL: rsharp@advancedgamin That's where the limitation would be. If different authors want different defaults applied to all their pre-3.10 scenarios then they will need special treatment. Scenarios created with and after 3.10 would maintain their existing mission parameters when rebuilding. A possible solution to the limitation would be to use the scenlist.ini to allow the editor to specify a Doctrine folder to be used for each mission or battleset. This would not be an feature available immediately and would be a nightmare to maintain. Given the nature of the default profiles, *I would believe you would get all your contributors to agree on one set and apply those to everybody's scenarios created before 3.10. So to summarize: 1. The editor will be allowed to define the default mission parameters using one profile per standard mission type. i.e. DefaultGroundStrike.mps in the Doctrine folder. 2. Scenarios from before 3.10 that are being rebuilt with 3.10 would have the default mission profiles applied to them. 3. Scenarios built in 3.10 and after will maintain their current mission profiles saved in their scenario data when rebuilt. 4. A switch or Rebuild with Scenlist setting may be in order to override point #3 so the editor can apply new default profiles to 3.10 scenario missions. If the contributors do want to have their own set of defaults applied to their pre-3.10 scenarios then you can: 1. Set up a battleset for each of them. 2. Change the Doctrine folder option in the Harpoon3.ini to something like C:\Harpoon3\Doctrine_Ralf 3. Rebuild by Battleset. Somewhat like what you described but the change required is one setting in Harpoon3.ini and the mission profiles saved in individual files. This is an overabundance of configuration available to the user. However, if you are happy with the GE default missions then you won't have to touch them. I think that you are making a very bad assumption on the number possibilities. From your description, you think that every author will use only 1 set of parameters. i.e. set them and forget about them. I think that this will definitely not be the case. While many probably will use a favourite profile, it is safer to assume that they will use different settings between battlesets and may even use different settings with different scenarios. Thus, 10 scenarios within a single battleset by a single author may have 10 different settings between them. The changes may be deliberate or simply 'accidental'. i.e. the author tinkers with his settings as he designs and doesn't realize that previous scenarios were written under different options. Therefore, the presumption that there is only going to be one "Doctrine_Ralf" is myopic. Failure to accommodate a user who just likes doing things "his own way" is not a good idea, IMO. Things should not be organized for the highest* common denominator but for the lowest. The feature has not even been officially released and some authors already appear to want different settings applied to their scenarios. For example, one thinks that the MissionPatrolRestrictedZone.opt should be applied while another does not. These are mutually exclusive choices. I do not use the ScenList.ini function because there is no documentation on its use. I only use the Re-build by Battleset function for all 300 and, currently, only have to do it once. Being forced to re-build each of our 40+ battlesets one battleset at a time kind of defeats the purpose.

rsharp@advancedgamin -> RE: Problem (2/20/2009 9:15:22 PM)
You missed the part where scenarios made prior to 3.10 will have the default mission profiles applied to their missions. Scenarios made before 3.10 can't have different mission profiles because they don't exist for scenarios until 3.10. Scenarios with mission profiles (made in 3.10 and after) will retain their set mission parameters that the authors designed them with. If the authors want different mission profiles applied to their scenarios from previous versions then, yes, that's something you'll have to deal with. Working for the lowest common denominator limits the feature to the point where I'm not willing to put my effort into it. I'm not really worried about constantly rebuilding 3.6 scenarios in bulk. I'm aiming for a one way upgrade path and will not work to retrofit 3.6 with mission parameters. However, I can give you tools to mitigate the trouble for such a case. For instance, I can make the editor rebuild by battleset on the command line. This would mean you could write a simple batch script (I'd be happy to start it for you) which would change doctrine folders between battleset rebuilds. So you would retain the fire and forget setup you have now. It might even be faster if the UI is not loaded. Thanks,

hermanhum -> Problem (2/20/2009 9:59:16 PM)
quote: ORIGINAL: rsharp@advancedgamin A possible solution to the limitation would be to use the scenlist.ini to allow the editor to specify a Doctrine folder to be used for each mission or battleset. Where's the documentation for this function? I'd like to see if it can mitigate the problem.

rsharp@advancedgamin -> RE: Problem (2/20/2009 10:27:16 PM)
There is no documentation for the Rebuild by Scenlist.ini function. I took a look at what it does though. It takes a list of any number of scenarios and rebuilds them. It also allows some configuration of EMCON state and aircraft basing per unit. I believe rebuilding by battleset on the command line would be more suited for a solution.

incredibletwo -> RE: Problem (3/14/2009 7:23:12 AM)
Hi

incredibletwo -> RE: Problem (4/4/2009 7:55:21 AM)
Hi, Playing 3.9.4. Just launched at max range. So far, so good [:)] [sm=Evil-210.gif]

rsharp@advancedgamin -> RE: Problem (4/6/2009 2:10:22 AM)
Howdy, First, thanks for the feedback. Second, I read the post but I assumed you had caught my answer in a separate thread. The issue of auto-defence is an issue of gameplay. I do not consider it a bug but it is a major issue to many users. So in 3.10 we are going to introduce an option to allow disabling automated defence. The second issue you reported, and thanks for posting about these issues, was a bug in that it was limiting the player issued attacks when it should have only applied to the AI. As you found, it was fixed. Thanks,

incredibletwo -> RE: Problem (4/6/2009 5:05:16 AM)
Sweet! Thanks for the clarification. [sm=Evil-210.gif]

Page: << < prev 1 [2]

Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

1.578003