Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

  • Medals

Everything posted by Rydygier

  1. Unfortunately. I had somewhere above described problems with creation of necessary files. What's more, addon is not at all designed for MP for this reason, that I know too little about how to design scripts to work in MP. In general, I have zero experience with MP gameplay and it is unlikely to change, so even if once I find out more info about scripts for MP, I will not have opportunity to test them (creating such kind of scripts without frequent testing is a very bad idea). If someone wants and can do, may freely to improve or to modify this addon according to own needs. If possible, I will provide willingly needed for this purpose info about those scripts (how it works, which is what, and so on).
  2. Thanks for idea, hcpookie. What you suggest probably can be done, but I can also achieve dynamic improvement of accuracy without changing battery skills, but by adding directly related to the "knowsAbout" factor into the formula that calculates dispersion. In the same way I can directly add to the formula another random factor (do not know if it is necessary, formulas already include a random factor). I do not know whether it is justified growth of accuracy following the increase of knowledge about target, since its location and vector is anyway equally well known. Chances for accurate hit, I think, do not depend on detailed knowledge about target, but mostly on the knowledge of where it is and in which direction and how fast it moves. ---------- Post added at 07:06 PM ---------- Previous post was at 06:14 PM ---------- @Rydlock I did a little test with GRAD on Arma 2 1.10. Everything looks fine (although it may, however, GRAD shoot too accurately). Thus it may be, unfortunately, the problem between script, and CO, and maybe it's about something else. There is a buffer zone of safety. Artillery does not aim at the position located too close to allied units. Radius of this zone is widest for GRAD, is equal 3.5 * 200 * (1 + "overcast") ("overcast" = 0 is the best weather, 1 is the worst). This radius can be changed by typing in the init field of any unit lower value, for example for 5 meters radius will be equal (3.5*5* (1 + "overcast")): RydART_Safe = 5; It is worth checking if this will help.
  3. Script is not directly referenced in any way to UAVs, but relies on what allied units know about enemy. So if allied unit examines the area by using UAVs, and if in this way can be increased their knowledge about enemy units (if in that case is rising value, that is corresponding to command "knowsAbout"... I do not know this, not yet experimented with UAV module), in this way, indirectly, UAVs contributes to shelling enemy which is detected that way.
  4. @Rydlock I'll look at this carefully. I've found another bug (script, when choosing coordinates to bombard, does not take corrections for allied units positions in FO mode), so probably soon will appear new version, but not today, nor tomorrow. After the gale I was two days without electricity and I have a lot of ... social arrears. Thanks for your bug report. EDIT: While I do not have CO. Only Arma 2 1.10. If this problem doesn't lies in script itself, but in its cooperation with CO, not much I can do.
  5. @Gerwazy (witam :)) Just tested on Arma 2 1.10 + ACE + ACEX for m252 and M119. It works. AndroidSpawn also seys so. Otherwise from the beginning I experience strange behavior of this script independently of presence of addon. Sometimes only one battery fires, sometimes none, sometimes battery cease to pinpoint targets after the first salvos. Don't see any regularity here. I set batteries commanders as "playable" and looking, what is happening there. Strange things happen. Howitzers did not shoot, though are full of ammunition (10 mags), mortars, in turn, sometimes have ammunition cleared (0). I read somewhere in thread about "ECHO fire director" that artillery module has its own reload system, so batteries, that are synchronized with modul have inexhaustible supply of ammunition. In theory, because in practice, supposedly this system is messy and you can't always rely on him. Problem is, that I don't now how turn this crap off. Maybe it's beacuse of this? Another possibility is that one of the addons, or CO itself replaces the artillery classnames (uses another classnames for given artillery pieces), so the unit would not be in that case recognized by the script. If so, to correct that kind of problem I will need to know, what this new classes are, but this is only theory and so called "longshot". Of course, we assume that batteries are not placed too close nor too far from target and that some allied unit see and recognizes enemy units as possible targets plus other conditions, that are presented at the beginning of this thread.
  6. @maturin Well. In fact, now everyone can easily adjust the size of dispersion to their own preferences with included variables, actually also salvos accuracy increases both, in the case of the "test shot - the main salvo" firing system, as and when battery retargeting same target as before. Mainly I worry whether the increase of radius of dispersion with increasing shooting distances is sufficient. Formula takes into account both the geometrical factor (vertical and horizontal angles between optimal and real shooting vector), depending on the distance to the target, as well as other factors such as atmospheric conditions, whose influence in turn depends on what is the trajectory and how long projectile flies. The question is whether the role of the geometrical factor is not too small. Therefore I am looking for knowledge, to compare with the results of real weapons circle error probably (or similar) tests.
  7. @Demakre Now the case is clear. Purpose of this addon is to make AI artillery fired on targets perceived by allied units without any intervention from player, except possibly of the personal searching for targets by simply observing the enemy positions, preferably with binoculars. Absolutely there is no need for the observer was in the same group as the battery, addon does not provide the manual issuing orders to battery. Battery will to shoot at automatically selected target itself. ---------- Post added at 07:34 PM ---------- Previous post was at 07:11 PM ---------- To resolve any doubts... Here is my private training ground. Prepared everything needed: ---------- Post added at 07:49 PM ---------- Previous post was at 07:34 PM ---------- I still wondering, how should I improve (make its results more realistic) way of calculating shells dispersion. Could use a little reliable information. Has anyone may link to sites where you can find this kind of specs? Something as tables containing parameter CEP for m252, M119, and the rest, or something like that? Looking blindly, using Google for a few hours, so far without any specific results. I will continue searching, but maybe someone has this kind of data at hand and save me trouble?
  8. This shouldn't be difficult, I will try to take this into account in the next version. @AndroidSpawn You're right about the folder. I'm talking about script version, and yet throw the code from addon version, with "\ RYD_FAW \" before the name of the script to execute (if you want to use these scripts must be "\ RYD_FAW \" removed in three places. Next thing to do in the next version. And thanks for advice on coop compatibility.'ll try this. I just never dealt with MP, and the more with scripts for MP and I have no idea what is needed to script was adapted for use in MP. I have heard only that it should be signed, I had trouble with it now while working on a previous addon: http://forums.bistudio.com/showpost.php?p=2046183&postcount=138
  9. In response to valuable snoops_213's comments prepared above a small update that contains implementations of his suggestions, and a handful of other ideas.
  10. This message isn't from my script. I guess, it's from Artillery Module. It seems that one of batteries trying to shoot at target that is too distant or too close. This is unexpected because script does not allow to chose batteries such targets. Unless that using my addon simultaneously you try manually direct artillery in some way? It all should work automatically... Hard to tell, need more info. It happens all the time, or only sometimes? You play Arma 2 or for example OA? Addon was tested only on Arma 2 1.10 and I heard, that artillery works a little differently in OA. Message appears for mortars, howitzers, rockets, or for all? What is at that time distance between battery and the target? What ammunition is used? You're using default settings or you changed it with "RydART_" variables? Whether, despite this message battery shooting at target? Do you maybe use any other addons or mods? Its your own mission , maked in editor, or maybe you trying to play with this addon mission previously prepared by someone else?
  11. Technically absolutely biggest possible (but extremely improbable) distance between target and impact (with default addon variables, for GRAD rocket artillery, moving vector for target at speed 29 km/h + maximal drift + maximal possible dispersion (battery leader nearly dead and just complete ignorant, gun nearly destroyed, stormy weather and maximum distance (10 km))) may reach... 483 m (vector) + 2774 m (! dispersion) + 1194 m (salvo drift) = about 4 km. Hmm. I am able to imagine that half-dead, totally incompetent idiot commanding battery will send a salvo so far from the target, it is certainly in the next version will limit possible spread a bit:). Have you used markers? If so, whether it was the distance between the target and explosions, or between the target and the black dot? What was the distance of the shot, what type of artillery, the weather, what skills and health of the commander? It's probably possible, but can be quite complex. Currently aiming adjustment takes into account in such a way that re-firing the same target by the battery will be charged reduced by half drift. I'll think about it, but here I promise nothing. Yes, I suppose. I wanted to do this and do not know why I did not... It's good idea, so... in the next version, I think. Still highest value does not guarantee becoming a target, only probability of that will grow up... Thanks for your testing!
  12. Yep, it's because every battery choose their targets indepedently. I will think about way to customize this behaviour. Thanks.
  13. Rydygier

    Female Soldier (beta wip)

    It's strange. I also use Arma 2 1.10 and this great addon - all, except for the lack of women's voices, is all right. OA maybe isn't so expensive but for some people still is too expensive. Sad, but true.
  14. Rydygier

    Enemy Waves?

    Some time ago I prepared myself something called "Automatic War". Idea is simple. Two scripts, one per side, forming a randomly selected groups of soldiers of a certain "value" activated respectively by two repeatable triggers, while each of the groups receives a waypoint in the center (plus some randomization) of the trigger of the opposing party. This gives you possibility to easily play some meeting engagement. If to remove a waypoint one of the groups, and for that will appoint defensive positions in buildings, with static weapons, sets auto patrols, etc. We have, in turn, attack-defense mission. Triggers conditions looks like this: ((east countSide allUnits) < 20) and (EST < 4); and ((west countSide allUnits) < 20) and (WST < 4); (with EST = 0;WST = 0; inside init field any unit) and its activation fields: [] exec "EAS.sqs"; EST = EST + 1 [] exec "WAS.sqs";WST = WST + 1 Triggers also has 30-40 sec. countdown. Without that they could generate all waves at once with such conditions (because groups of a given wave are spawned with some short interval, so condidtion may be considered true few times before number of units rises above the threshold (20)). As you can see there are set four waves per side. Do not show scripts, because they are messy SQS, which would not explain anything, I afraid.
  15. Here is code with some diag_log "checks": _PosX = 0; _Posy = 0; _Ashells = []; _i = 0; _start = false; OnMapSingleClick ' diag_log "check1"; if not (_start) then { diag_log "checkA"; _start = true; _PosX = _pos select 0; _PosY = _pos select 1; _i = createMarker ["rangemark",[_posX,_posY]]; _i setMarkerColor "ColorKhaki"; _i setMarkerShape "ELLIPSE"; _i setMarkerSize [1000,1000]; _i setMarkerBrush "Border"; }; diag_log "check2"; if ((_start) and (_alt)) then { diag_log "checkB"; _start = false; { deleteMarker ("shell" + str (_x)) } foreach _Ashells; deleteMarker _i }; diag_log "check3" '; On click RPT shows checks 1,2 and 3, but not A or B, not to mention about marker, which I try to create when clicking on map. On the other hand, in the following case, without "if-then" condition: _PosX = 0; _Posy = 0; _Ashells = []; _i = 0; _start = false; OnMapSingleClick ' diag_log "check1"; //if not (_start) then //{ diag_log "checkA"; _start = true; _PosX = _pos select 0; _PosY = _pos select 1; _i = createMarker ["rangemark",[_posX,_posY]]; _i setMarkerColor "ColorKhaki"; _i setMarkerShape "ELLIPSE"; _i setMarkerSize [1000,1000]; _i setMarkerBrush "Border"; //}; diag_log "check2"; /*if ((_start) and (_alt)) then { diag_log "checkB"; _start = false; { deleteMarker ("shell" + str (_x)) } foreach _Ashells; deleteMarker _i };*/ diag_log "check3" '; "CheckA" in RPT and marker on map shows on click... Why? Seems, that code inside curled braces is ignored for some reason when it's in quotes? Perhaps these brackets should be replaced with something in this case? Or maybe something else is wrong, maybe I'm simply blind and do not see something obvious?
  16. So that's it... Well, so will globaliz'em. Thanks. It is good to learn something new in the morning.
  17. Thanks. Again. "_start = false;" is now inside OnSingleMapClick's quotes and it's works (of course can't stay there, will think about that. Tommorow). Hmm. It seemed to me that defining of this variable at the beginning does the trick with "scopes", apparently I was wrong. Something is still not understand (but hey, less than hour to midnight here...), and I do not want to repeat this kind of error in the future. Why is this variable had to be defined inside OnSingleMapClick, and not outside, and why only this and others used inside "if-then" do not? Is said: If a local variable is initialized within a Control Structures (i.e. if, for, switch, while) its scope will stay within this structure but "_start" wasn't initialized inside CS where is used, but before, similar to the second example from Biki.
  18. Think I succeeded somewhat overcome problems with "Towards Enemy System". This time used waypoints dynamically placed about 6 meters from vehicle towards enemy. As waypoints are assigned to the group, system works good for ungrouped tanks. For missions with tanks grouped eg. in platoons recommended first version, without "TES". It does not replace waypoints designated by the AI, so if AI chooses to relocate tank, it will not rotate towards enemy until fills this order, so can still happen that a sensitive sides or back will be under fire. Also removed some minor problems from main file. It contains debug and no-debug versions. Here are two versions of addon in one package: NBT_TDS TDS differs from TDS2 only that is not equipped with "Towards Enemy System". It is, I think, final version of Nice_Boat's TDS, unless show up any new bug reports, comments or ideas. Was tested on Arma 2 1.10. Addon requires CBA. Thanks for help and testing. Have a nice tanking.
  19. This part of sqf file executed with EH "handledamage": _gcheck = _target getvariable [_gname,0]; (_target is an object, _gname is a string and 0 is 0). causing an RPT error: Error position: <getvariable [_gname,0] Error getvariable: array type, string needed It seems, that it doesn't recognize alternative getvariable syntax. Why?
  20. Well. If so, I have to find another way. If there is any. Thanks for help.
  21. Yes, _gname is a string for sure. Tried with other strings too. I tried code similar to your in sqf activated by trigger: gname = "myVariable"; what = sold1 getVariable [gname,4]; sleep 5; diag_log format ["%1",what]; and same error occurs. Maybe alternative syntax was introduced after Arma 2 1.10, which I use?
  22. Thanks, but I need default value for an undefined variable, so standard syntax here is not an option and so am trying to use this: object getVariable [name, defaultValue] with the described effect.