|
|
Post by PsyWarrior on Nov 9, 2004 7:06:51 GMT -5
Greetings, We are pleased to announce the release of the long-awaited BETA:2.5!The BETA 2.5 fixes numerous bugs, and adds new functionality to Project MCAR. For full details, please see the Readme file. Here's a list of some of the most important changes or things you need to know: - Despite what was said previously, MCAR: BETA: 2.5 is not MP compatible. We are looking for help here, if you know your way around MP editing, please get in touch!UPDATE:As of the 2.5.1 patch, Project MCAR is now tentatively MP Compatible. Please test and feedback. -BETA version of documentation/ manuals added, for addon designers and mission editors. -TOW 2B 'Real' HMMWV added -Several new AA guidance codes introduced, and demonstrated on the Sa-9 Gakin. -Kill reporting added to some vehicles. Still not 100% reliable yet. -3 Demo Missions added, with one more on the way. -Code added to deal with savegame issues. -Misc. Bugfixes and upgrades This list is not exhaustive, but it gives you an idea of some of the things that have changed in this version. Files:The BETA: 2.5 files can be obtained here. Please use mirrors to download, when they are available. MCAR: BETA: 2.5MCAR Manuals (beta)Demo Missions2.5.1 Patch:Extract to your addons directory, OVERWRITING the psy_mcar_config.pbo and psy_mcar_scripts.pbo files. You must install the BETA: 2.5 before applying this patch. xoomer.virgilio.it/sa8gecko/beta2.5.working/psy_mcar_config.pboxoomer.virgilio.it/sa8gecko/beta2.5.working/psy_mcar_scripts.pboMirrors:BETA 2.5 c/o OFP.InfoBETA: 2.5 manuals c/o OFP.infoDemo Missions c/o OFP.infoAdditional Information:For further information on the inner workings of MCAR, please consult these link for sa8gecko's (ongoing) attempt to document the BETA 2.5: Scripts: BETA: 2.5 scripts explainedAnd functions: BETA 2.5 functions explainedIf you have any questions about the inner workings of Project MCAR, please do not hesitate to ask the Lead Developer, sa8gecko, here: Ask Sa8GeckoManual Errata:1. The README states that the Sa9-Gaskin missiles have a speed that is This is not correct. Only the standard Gaskin missile behaves in this way, the others start to decelerate just after having reached max speed (at engine burnout). And they have an endurance of about 19.5 secs, whereas the standard one has only 15 secs to live. Enjoy the update, and look out for bugs...  If you are an addon designer or modder, and you want to either update a released addon, a work-in-progress, or to create an addon based on MCAR: BETA: 2.5, please contact us, we would like to hear from you. -PsyWarrior -MCAR Project Manager EDIT: Added Mirrors. EDIT: Added 2.5.1 patch links. EDIT: Updated MP Compatability information |
|
|
|
Post by Sa8Gecko on Dec 26, 2004 9:17:00 GMT -5
|
|
|
|
Post by h- on Dec 27, 2004 19:29:14 GMT -5
Mirror for Beta 2.5.1 patchBeta 2.5.1I just received a word from our MP testing 'horde' and we are having greenish light on MCAR Beta 2.5.1 in MP... (so the latest patch is needed)... The light is 'greenish' because no insanely extensive testing has been done (I mean no redicilous amount of players etc etc etc) but the basics are covered... So this does not guarantee 100% functionality... Also, no respawn behaviour has been tested but this should not pose a problem if init eventHandler is run (by OFP engine) when a vehicle is respawned... The missile guidance code are quite vulnerable on lag/desync, and the 'Real' variant Humwees as well as the various Gaskin codes are very heavy and may cause that lag/desync themselves as OFP netcode is probably not meant for moving that much extra calculations all around...  So we are eager to hear all the bugs that may (and most likely will) lurk in MP realm, so do test this... (pretty please ;D)
|
|
|
|
Post by Killswitch on Feb 1, 2005 14:05:55 GMT -5
Hey guys! I tried, but I couldn't keep my curiosity away from MCAR. Lovely thing, the missile-equipped cars. Now, some things I noted in the 2.5.1 patch that will affect MP. PSY_MCAR_sensor and ...gamelPSY_MCAR_init.sqs is executed on all machines on mission start. In it, the two objects PSY_MCAR_sensor ( EmptyDetector) and PSY_MCAR_gamel ( Logic) are created using createVehicle and the objects are later used by the functions PSY_MCAR_calcH and PSY_MCAR_hShooter. The problem: with N machines (including the server) in a MP session, there will be N instances of these objects created, one unique for every machine. That in itself creates a short-duration network load. However, the bigger problem lies in their use. Currently, the missile guidance is run on the firer's machine only, so in reality only one of these N separate instances of the sensor or Game Logic is used. From what I can gather, the missile guidance does a lot of moving around of these objects when a missile is fired. This creates a boatload of network traffic as the position and whatnot of the objects are transferred. Possible optimisation: Use camCreate instead. While there are still N instances of the sensor and logic created, they create no additional net traffic, nor will they later cause any traffic when moved around. More PSY_MCAR_init.sqs optimisation possibilitiesIn case there are more than one MCAR vehicle in a mission, this file will run several times. Each time, things that are already initialised will again be initialised (preloading of function strings and creation of above-mentioned objects). With the current 2.5.1 use of createVehicle for the sensor and game logic, even more objects are created. To avoid this, imagine PSY_MCAR_init.sqs looking something like this: ?PSYMCARInit:goto"initdone"
PSYMCARInit=true
PSY_MCAR_sensor = "EmptyDetector" camCreate [0,0,0]
PSY_MCAR_gamel = "Logic" camCreate [0,0,0]
; Preload functions shared by all types of vehicles
PSY_MCAR_getLaunch = loadFile "\psy_mcar_scripts\PSY_MCAR_getLaunch.sqf"
PSY_MCAR_calcH = loadFile "\psy_mcar_scripts\PSY_MCAR_calcH.sqf"
PSY_MCAR_vNorm = loadFile "\psy_mcar_scripts\PSY_MCAR_vNorm.sqf"
PSY_MCAR_trail = loadFile "\psy_mcar_scripts\PSY_MCAR_trail.sqf"
PSY_MCAR_hShooter = loadFile "\psy_mcar_scripts\PSY_MCAR_hShooter.sqf"
crew_mcar = loadFile "\psy_mcar_scripts\PSY_MCAR_crew.sqf"
#initdone
? (typeOf (_this) == "psy_mcar_gaskin"): goto "Gaskin"
? (typeOf (_this) == "psy_mcar_hmmwv_tow2a"): goto "Hum2A"
? (typeOf (_this) == "psy_mcar_hmmwv_tow2b"): goto "Hum2B"
? (typeOf (_this) == "psy_mcar_hmmwv_tow2aReal"): goto "Hum2AR"
? (typeOf (_this) == "psy_mcar_hmmwv_tow2bReal"): goto "Hum2BR"
#Gaskin
?PSYMCARAAInit:exit
PSYMCARAAInit=true
;
; Lots of lines with loadFile specifics for AA functions
;
exit
#hum2A
?PSYMCARATInit:exit
PSYMCARATInit=true
;
; Lots of lines with loadFile specifics for AT guidance functions
;
exit
;
; And so on
;
Well, you get the picture  One can even imagine just having two sections there, one for AA inits and one for AT inits. Currently, there is one label for each type of vehicle in there. Lots of redundancies can be eliminated. Doing that helps increase readability, IMHO. Missile guidanceCurrently, here's how it works (hoping I got it right): The magic there involves deleting and creating dummy missiles indicating the momentary pitch of the missile as it travels. That means a lot(?) of deleteVehicle and createVehicle:s during its flight. Doing that and all the setPos:ing and setVelocity:ing of things creates a lot(?) of network traffic. How to decrease the network load? An alternative design would be the following: For this, one has to add "dummy missiles" to the CfgAmmo of MCAR, missiles that have the same model as the real thing but they do zero damage. There will be one dummy for each real missile. All machines now run the guidance script. On every machine, a missile is camCreate:d. The guidance script uses camCreate instead of createVehicle during flight. Only one machine in the network creates the real thing, the missile that actually does damage. The others are just there for visualisation. On all machines, players will see a missile being fired and flown to its target. The actual damage will be done only on one machine - the firer's. What does this accomplish? Less network traffic, but more work for each client. Ok, that'll be all for now. Hope some of it will be of use. Regards, KS |
|
|
|
Post by h- on Feb 1, 2005 15:37:54 GMT -5
Hi... And thnx for the input This missile guidance stuff is too confusing for my MP knowledge We tried that dummy missile/camCreate stuff, but it presented a myriad of problems, some that I witnessed, some that we have only theory of... I have to dig up the witnessed problems, it was so long ago I just can't remember them all... But in short, the system did not work at all... Altough, I can't remember whether the sensor and gamelogic used camCreate instead of createVehicle... So, it was decided by me and the MP test crew that we leave it with the current way, because that at least ensures some sort of MP compatability... The theory part is that what ensures that the dummy missiles created alongside the 'real' missile hit the same target if they all are guided by individual guidance code?? Because there can be situations that there are multiple targets in the same vicinity and one of the codes may decide to hit 'that' target insted of 'this' whereas the others still hit 'this' target... This can be caused either a short desync or lag, or just the fact that the targets are very close to each other etc... Of course that is nothing but a visual anomaly but that still pretty much would ruin everything... Of course you are more than welcome to tinker around with the code and even test it if you like... |
|
|
|
Post by Sa8Gecko on Feb 1, 2005 15:58:12 GMT -5
Thank you, Killswitch, for your notes.
In effect Hater_Kint tried to do what you explain: probably,
for lack of experience in MP, the results were not very positive:
- no lag (the good thing)
- most of the times the missile didn't get created (the bad)
As I've been told by Hater_Kint, only in one try did the missile
work as expected (alas, I can't confirm it myself cause I didn't
partecipate in the tests because of my crappy internet connection).
I think that anyway Hater_Kint could be more specific, and
maybe give you the code of the code he utilized, with
HitSquadZulu, for the tests.
As about PSY_MCAR_sensor and _gamel, they're vital
for the proper working of the guidance code: I made them
global to evitate to create and delete them everytime they're
used. Unfortunately, as you have understand, the code
is heavy. But for the Gaskin missile, given the velocities at
which the target and the missile itself operate, it has to be
run very frequently for course correction, so that it can hit
the target. I don't know if you've tried this, but on lag-free
environment the MCAR gaskin is much more lethal than any
standard AA missile: you can put it to test using a plane
that doesn't deviate missiles with countermeasures, for a
fair test (infact the gaskin missile is immune to these).
We really appreciate your help: thanks!
I hope Hater_Kint put there a link to the code he used in
his failed tests, so maybe, if you like, you can have a look.
EDIT>
post made before Hater_Kint posting his own above.
That is: I took too much time to reply and Hater_Kint preceded
me, so some incongruences could be explained this way.
|
|
|
|
Post by h- on Feb 1, 2005 16:01:42 GMT -5
Uhh... I might not even have the code anywhere, unless Zulu has saved it somewhere But yeah, what Sa8 said pretty much happened when we tested it... |
|
|
|
Post by Killswitch on Feb 2, 2005 9:46:54 GMT -5
Ah - I see you've already been down the "alternative road" with the distributed missile system instead of the current centralised. And after a bit of thinking I realise that the problems you listed indeed will occur (different final targets being attacked, problems in catching the proxy bullet on remote machines and so on). D-oh!  Ok, lets forget about the distributed solution for a while then ;D How can the current system be streamlined then? Again - by minimising the use of createVehicle to the places where it's actually needed. And that boils down to the missile-in-flight replacement and the "RKT_detonator" creation. The following things, however, can be done using camCreate without affecting functionality and at the same time improving MP/network traffic: [/i] in the ..._init.sqs [2] All occurences of "EmtpyDetector" createVehicle ... can be camCreated instead. Lots of those in the scripts. [/ul] I did just that and tried a wee test mission on a dedicated server. Initial results: MCAR still works just fine. createProxyAA and createProxyAT unctionsThese run on init and loads up the proxy logics into the dummy cargo positions of the vehicles. Problem: Currently every machine in a MP session will create three GameLogics and try to stuff their copies into the cargo of the affected vehicle. That means unneccessary network traffic and a lot of redundancy. Solution: Do it only on the machine where the vehicle at hand is local: (The lack of proper indendation above is a limitation of the forum system  ) Ok, that's all for now. Back to more testing... |
|
|
|
Post by h- on Feb 2, 2005 10:49:53 GMT -5
Thanx a bunch m8 ;D Actually back then I was thinking of testing would publicVariable help if certain key variables were shared from the 'killer missile' code to the dummy missile code... But I never got around doing it... Yay... I think I had these done with camCreate back then... I've been too busy to actually dig up the codes we used then  Oops... I think I had this in mind when I was assing about with the later released 2.5.1 code... Huge piles of thank yous and well dones etc. phrases of praise to you for doing this... We really appreciate it... |
|
|
|
Post by Sa8Gecko on Feb 2, 2005 13:58:24 GMT -5
As Hater_Kint said, we really appreciate your help, Killswitch !
About catching the bullet, this should be done istantly by the
'fired' eventHandler, at least this happens in Single player
mode: is it different in MP? I read somewhere the eventhandlers
don't behave correctly in MP, but, as I said above, I've never
had the occasion to test it.
About the possibility to attack different targets in the 'distributed'
solution, this could happen to the regular tows and the
gaskin, but the real tow humvees have a much more efficient
targeting routine, the only limitation being when you have
several tanks in a very thight space (for example 5 tanks
in 200 square meters), cause nearestObject calls could not
report all tanks (maybe one is missing, or two), and if this
tank is the one lying on line of sight from the shooter to the
target and another routine running on another PC has catched
it instead, then the 'mishap' could occur. But I think it's a
remote possibility, so, since the real tows are the most
prone to problems in MP, I think the distributed solution
would be the best: for these, atleast.
|
|
|
|
Post by raedor on Feb 3, 2005 11:51:48 GMT -5
is there a chance to get 2.5.2 with the bugs mentioned by killswithch (he's a very good betatester, he did that with our t-55s, too) fixed?
|
|
|
|
Post by h- on Feb 3, 2005 12:01:18 GMT -5
Working on it  EDIT: And hoping that Killswitch comes by here again with some more of this good stuff ;D |
|
|
|
Post by raedor on Feb 3, 2005 18:49:17 GMT -5
Working on it EDIT: And hoping that Killswitch comes by here again with some more of this good stuff ;D whoops, sorry, i did not see that killswitch posted his report some hours ago. i thought all this is already a bit older... thx for the answer anyway. |
|
|
|
Post by h- on Feb 3, 2005 19:47:47 GMT -5
No probs... I just actually had a two man test session and the stuff seemed to work without any bigger problems... So, this sure is looking good... EDIT: Killswitch: If you like, I can give you the most recent code to look at... |
|
|
|
Post by Killswitch on Feb 5, 2005 13:21:00 GMT -5
Sure - I wouldn't mind having a look-see at it. "psy_mcar_scripts" is small enough to send via e-mail and the address ought to be accessible by you guys from my profile on this forum.
|
|
One can even imagine just having two sections there, one for AA inits and one for AT inits. Currently, there is one label for each type of vehicle in there. Lots of redundancies can be eliminated. Doing that helps increase readability, IMHO.
)
