soccerboy

when i first released 1.04 i didn't catch that part in the readme which doesn't apply to 1.04 anymore, so you can completely ignore that line. prior to 1.04 i didn't have a detection through synchronization system implemented so you had to give the artillery modules a name and place those names in the options.sqs. but with 1.04 you don't have to do any naming of artillery modules anymore. i advise you to download and try the newer 1.04 hotfix1 which has the updated readme and the fixed dispersion values.

i'm the kind of person that doesn't like to bug others with my problems and things like that :(. but i guess i'll have to over come this personal issue of mine to see perfection come to my project. however i do remember all of those guys from the past games and i'll probably contact them in the near future for some help and advice. :)

did you try shooting a few fire missions. because i'm not the one who is actually making those calculations. i'm just calling a script function that BIS made. with this: [NameOfBattery, NumberValue] call BIS_ARTY_F_SetDispersion; the three fire missions that i've executed looked correct to me.

lmao i had a look at the fire script and the dispersion value is set but not used so i'll release a hotfix for it tomorrow later today/night (depending on timezone you're in) once i'm certainly sure that its fixed. i'm terribly sorry that i haven't caught it earlier. Edit: i got the hotfix done and now i'm seeing a big difference now that its using those values. try it out and report back if it certainly is fixed so i can notify armaholic to update their files on their site. i'm uploading it now and should be done and posted soon. now with the proper dispersion i've reduced some of them because 500m seemed to ridiculous and reduced effectiveness of the artillery.

ah you're right i've forgotten to set it to repeat. both will\should work however i'm unsure which one is healthier for the system at this time. if you run into problems with it being a repeat trigger you could try it with non-repeat. but i don't think there should be any problems. as stated before, the line in the readme where it says to fill in a name in the ASSP_options.sqf file is incorrect. 1.04 doesn't detect through naming it detects through syncronization now. so there is no need to name anything anymore other than the script version which the game logic has to carry the name "Arty_detect" *without quotes* edit: lol ok well since i already replied i'll just leave it in case somebody else needs the info i just posted.

i know it feels a bit strange but during my testing i read out the set dispersion that the gun used with a player sidechat format ["%1",duration_b1]; i used that code to varify the dispersion number that has been globally transmitted to battery1 and it always read correct. but i do sense that it feels strange too. i'll look into it maybe i over looked something thats confusing the system. however compared to 100m and 500m it does expand by my observation. i'm seriously a total noob with sound effects or particle fx modding. for the radio used now i had to cheat a bit and just used player sideradio "radiomsg"; instead of the more efficient and nicer looking kbtell function. the other things like particle effects is a bit too over me and i would need some professional help with that. you shouldn't need to set any names anywhere. the only thing that you would need to do is place my ASSP Init module on the map and sync it to your artillery modules (not the guns) and then use this code in every soldier you want that will have access to the artillery menu arty_radio = [this] execvm "\artillery_ssp\arty_radio.sqf" you're however right with the readme and i'm terribly sorry for the confusing and misleading readme. i'll make sure that it'll be corrected for the next version. for now i've uploaded an updated readme for people who wish to have the corrected readme now, on the front page of this thread. also for the options that are free to change by your will should be in the demo mission called "options.sqf" you can pretty much change plenty of values in there like ammo limit, etc. i already attempted to try that and the AI have a hard time with flying. also the A10 doesn't have a "Minigun" the A10 shoots a volkswagen bug :D

its here people. see front page for download link. i'm also going to add a future additions for the project for an overview on the first post of what i'll be trying to add to this. sadly my friends got delayed so i couldn't test it in an active mission with them but i have created and played an active mission in SP. i don't want to delay and delay over and over, and i can say with 99% certainty that it'll work in SP and with 95% certainty that it should behave the same way as the previous versions but without the bugs :D if you do find any bugs let me know. if they're serious show stoppers i'll get on it immediately. i'm looking forward to all your findings :D

i started a bit of work on a PvP version but that work is only limited to a bit of menu work and some detection work and i put in a check to see which side you're on. everybody is going to have access to the "open menu" option reguardless but if anything is listed in it is regulated by two things, side you're on and are you a radio operator or not. for the PvP version it'll be done 1.05 or 1.06. i'm not sure because i'm playing around at the moment with implementing a GUI Dialog page. the radio limitation to only a certain people (soldiers) is coming in 1.04 which should be out soon if everything goes as planned.

lmao good one. now i could say BIS 1.04 which will be a while :D. now that you mentioned it though, i think i need to hurry up with 1.05 (kidding) because BIS is catching up with the version numbers and they're doing a lot more than i am. :rolleyes:

you don't. the artillery will be accessable to everybody prior to 1.04 which won't be out till next week. the name giving is to tell the system which batteries you have so it knows which code to execute on what battery.

i apologize that it has been so quiet here from me but heres some news for you guys that you all might like. i have completed the major work on the script version and i'll be starting stress testing it in a few days once my friends are back in town again. so if everything goes well i'll have a release done and ready by sunday\monday. heres the updated changelog: Changed: Dispersion Add and Subtract Menu have been replaced with set ranges of: for MLRS its 50\100\150\200\250\300 Meters. for all the others its 100\200\300\400\500 Meters. Added: Added an Option to cancel a fire mission in progress but only after the first shot. Added: A few voice Radio Dialogs for the FDC. the voices are extracted from the sounds.pbo and aren't 100% perfect but it'll do for now. i'm in the progress in making a dialog menu with the dialog maker to make it easier to create fire missions off of just one page but it won't be in 1.04. i hope this post will be proof enough that i have not forgotten nor have i given up on this project. talk to you guys again on sunday for another status update.

the way i see it is the battery will shoot where you tell it to shoot. now if you placed the target point in the wrong place then the battery is going to execute the fire mission you gave it in the wrong place. now i'm thinking that it would be nice to be able to fire a spot round to see if the marker is in the right spot before executing the entire fire mission. in easy mode with all the map icons on and stuff the spot round would be redundant. but for people who play realistically with no map icons or other aids it would make sense to be able to fire a spot round to see if you marked the target right. i'll think about this feature for a bit before i start to work on it and maybe get it in with 1.04. however you are right that it would be very very hard, at least for me, to have that many random values for each shot. i think with the way i changed the Timed option it'll be easier and quicker to set up fire missions to last a certain duration in seconds. the OPFOR artillery and PvP support will be a priority for me in 1.05.

that statement pretty much means that some of the scripts are not needed in single player like disconnection or respawn. because in single player you don't have to worry about other people not releasing the battery before disconnecting since you're the only one playing :) and from what i could see is that there is no such thing as respawn in single player so that script is redundant in single player aswell. this is reality talk not game talk. in the real life that all depends on the munition shot by the MLRS i don't know if the US Military fielded it yet but i saw a GPS guided Rocket shot out of a MLRS on future weapons before so i mean it is possible with the right munition. in game now you can either simulate it as a dumb munition or Smart munition. i like the abillity to have one big heavy precision strike but i think i will widen up the area of effect for the MLRS and the M119. and i like the idea of Shooting a Spot round and then adjusting fire and then fire for effect. but that'll have to wait for 1.05. the only big change i'm gonna implement before completion is the radio limitation that has been requested for a while now, and maybe change the dispersion as said above. i can't really say of an ETA at the time. the ETA is limited by my ability to added the last big feature to the list then i'll do some of my own testing. then i'll find a group to test it with, and then you guys can go nuts on it LOL. :D

alright as promised here comes the SITREP: after much much work i've successfully converted all the scripts from SQS to SQF. i've also successfully added an easier detection method with synchronizing the artillery modules with a logic. i'll be releasing two version, an addon version and a script version. the addon version is like a plug and play where you only have to synchronize the ASSP Init Module to your artillery modules and you're done. the script version is going take a bit more code adding but not much. V1.04 Changed: Changed the format from SQS to SQF. Changed: Opened up the Artillery Support to everybody with a first come first serve deployment Added: Option to turn off the Artillery for mission makers in the options.sqf Added: You can now either disable or enable respawn mode in the options.sqf. respawn mode is when the player respawns that he gets his menus back. Added: Auto Battery detection and classification through synchronization. Changed: Rate of Fire Menu chagned to Immediate\Fast\Semi-Fast\Slow which represent 0\1\2.5\5 Seconds. Changed: Mission Wording of Timed to Suppression. Changed: Duration Menu is dynamic now depending on which mission mode you're in. in Suppression the options are Short\Medium\Long\Very long which represent 10\15\25\35 Seconds. in Immediate its the traditional Add\Subtract. Changed: The duration menu for the M270 is dynamic depending on how many vehicles there are. max 15 duration. Changed: The batteries won't be resupplied until they run out of one ammo type. Changed: A few moments After Submitting a Fire mission you will regain access to your radio menu again but are limited to changing everything other than setting target\submitting mission\releasing battery. Changed: Now all 3 batteries can be what ever weapon you wish to choose (M119\M252\M270). example you can now have M119\M119\M252 or M270\M252\M252. etc. Changed: Dispersion Add and Subtract Menu have been replaced with set ranges of 50\100\150\200 Meters. (Changelog is subject to change with other additions) i'm still fighting with a radio limitation method which i originally was going to use the same synchronization method as with the artillery detection but because of the locality of the player (client computer) and the logic (hosting machine) synchronization isn't going to work and another easy way would have been to make a custom radio model, config and used the "hasweapon" command but thats out of my league. i'll be thinking and working on a way to implement an easy and user friendly way now that the batteries are opened to everybody so they don't get spammed with like 50 fire missions. if anybody has an idea how i would do this i'm all ears... or i guess i mean eyes. :D PS. if people wish to have one i'll also add the Russian Artillery pieces and even make a PvP version if requested.

literally the battery will always have the max number of rounds loaded through the artillery module. the ammo limitation that i simulate is virtual and is definable in the options file. now the way i understood what you said is that if the weapon has the literal ammo that would be 12 per M270 MLRS vehicle and if it were my simulation then it'll be user defined which could easily be 3,000,000 rounds probably. i do however have a method already in place to dynamically set the amount of rounds based on how much simulated ammo you have. like if you try to shoot 12 rounds with only 2 left then it'll only shoot 2. i'm unsure if its in 1.03 or not and forgive me if i don't check right now i'm having quite the success making all this into SQF and using the if/then/else which is very nice by the way. it was a very bumpy and frustrating start but i think i'm getting the hang of SQF. i'll be collecting more input from you guys and you all should get a more detailed status report on this once i get more of the scripts rewritten and functional.

i'll see what i can do to simplify it and even fix the amount of rounds you can set to be fired to a dynamic value based on how many weapons you actually have in a battery. don't misunderstand the problems that i ran into with the dedicated server. it fully works on a dedicated server but i'm unsure why 1 of my 3 missions has problems with it. the only problem that i got in that one single mission is that it doesn't reset the variables for the Shot/Rounds Complete/Splash radio dialogs so by the 2nd fire mission you'll get those three radio messages all at once for some odd reason and i have yet to figure out why it does that.

its quite late so forgive me for not understanding some of the things you brought up. in what sense did you change what file and how. i kind of like that idea. i'll give it some thought. i like that idea too. maybe even some like randomized supply outage like if a "Non-existant" convoy didn't reach the destination that it'll just reset the script without resupplying. everything intended to be changed by the mission designer is in the Options file. if you change anything outside of that you can very well break the system as with anybody's script. hmm thats an interesting idea to a problem i've been trying to solve for a while. i like that idea and will give it some thought. i did get annoyed by setting the ROF too so i normally never go beyond 3-4 seconds. thats an sqf syntax which i'm not very experienced at all for this kind of scripting. it would take me a few weeks or a month tops to figure out how to write what and where in sqf format. i think i already figured out how i would do that too so i'll look into it. as of now though my main focus is getting an addon version done with a few features like Radio limitation and Auto battery recognition so nobody has to fill in any names anywhere anymore and probably with some of the easy things you suggested will be there too. but production is gonna be slow with it for a bit because i don't spend more than maybe an hour on this per day due to other things in life.

for all its worth i did some testing around and i got them to synch with this Syntax [color="Red"]MODULE[/color] synchronizeobjectsadd [[color="Red"]UNIT[/color]] you can test if your objects synchronized properly with 1 trigger that i used for diagnosis activate alpha on activation - player sidechat format ["%1",synchronizedobjects [color="Red"]MODULE[/color]] only problem that i've seen is that after the synchronization nothing really happens nor do the modules interact with you. i've tested both SOM and First Aid Simulation and after a 3 minute long wait nothing happened. so it seems you would have to find a way to re-initialize the modules for them to interact with you. thats my guess and two cents :)

it should be packed inside the .zip file. its not a PBO but an open mission which can be changed or edited.

i tried that but sadly the AI are to dumb to fly for it to be of any use. the problem that i'm running into is the pilots (AI) are to greedy for kills so no matter if theres a tree in front of them they're gonna stay the course to kill their target and then crash because now they don't have any time anymore to pull out. i watched them try a few times and i'm gonna say 3 of 10 cases they succeeded in pulling out, the rest was a disaster. i'll keep the code though in case they learn how to fly so i can just flip it on and not work on it for days and days.

are you using the latest version? are you using it in single or multiplayer? if you're using it in multiplayer is it on a dedicated server? (it seems that dedicated servers have some issues) easiest way to get this to work without any big editing is to load up my demo mission and just copy the battery you wish to use and past it into your mission and copy the script package into your mission folder.

i already added min and max range markers on the map when you're in the process of setting the target.

oh lol if i would have known you posted here too and not just PMed me i would have just posted it here for everybody to see but i'll gladly repeat it again for others to view and maybe gather some ideas aswell.

oh i thought foxhound already corrected it. i'll send him a pm to let him know. i also did some research into building in a menu that you could call in an aircraft for close air support and i got it to function in SP and MP but sadly the AI isn't very smart at flying. so far all planes (AV-8B) & Helos (AH-1z) except the A-10 are way to greedy for the kill and crash just to get it and for me thats unacceptable for adding it in as a feature with that lack of usefulness, so until the AI learns how to fly i'll be holding onto the CAS feature. updates to the artillery are going to be coming slower now because i'll be taking my time instead of rushing it out now that we all have a somewhat acceptable build and i can finally stop obsessing over this and collect my thoughts. i will still check on the forums every day to ensure nobody has found any new bugs. if so i'll do my best to fix them.

That means the fps drop still present in MP ? Greetings it shouldn't be present because i gave the scripts a sleep time before asking for the players status. so to say every like 3 or 5 seconds it'll check if the player is dead then it'll sleep again for 3 or 5 seconds and then it'll check again. that script is responsible for giving back the players menu in case of a death and he respawns. before it constantly asked for the status of the player and thats what caused the fps drop.