ACES

[UNN 0]

Quote[/b] ]This is not a thing I like very much (to insert something in the editor to make an addon work), but it's much better than to have the proxies ejecting the plane in the middle of a combat (and perhaps causing a CTD). Putting the ACES_LOGIC thing in the editor can be avoided, I think, grouping the proxies with the player's group

Yeah, I already know about units created with invalid groups causing CTD's, when ejecting from aircraft. But that won't stop them from ejecting in the first place, the problem you original reported, of all the weapons disapearing during damage? I have not tested an ACES aircraft, but the ACES base class was kicked out of a truck when that was disabled, so I assumed the same will happen with ACES aircraft?

The problem we discussed in Gnats thread was, after taking so much damage, the AI pilot orders the rear gunner logic to eject.

Adding a couple of scripts to the event handlers will remove all these problems, and no need for a game logic to be placed in the editor. Not that the Game Logic is a bad thing, it's not like it's asking a lot from the mission designer.

Quote[/b] ]The proxies have geo lods because, not to having to duplicate them, most use the same p3d as the conrespondent ammo.

Well the aircrafts geo will cover the collison detection most of the time, but there are HE ammo bugs associated with a proxies geometry to. As well as the blood problems, so yeah I did not think they were needed.

[sa8gecko 0]

Quote[/b] ]I have not tested an ACES aircraft, but the ACES base class was kicked out of a truck when that was disabled, so I assumed the same will happen with ACES aircraft?

Try creating it with the createUnit command and then give it a 'disableAI "MOVE"' command.

You can check what happens by yourself downloading the BWMOD Typhoon. I didn't have the time to check it thoroughfully, anyway:

1) damage the aircraft a lot, or better make the enemy AI do that: any weapon that will damage it without destroying it with a single blow is OK. MCAR Gaskins are OK, Backfire rear turrets too, but for example the DKMM Tunguska is not: too much powerful.

2) try to fire some missiles: I always used the default load of 4 amraams and 2 sidewinders

3) sometimes an error pops up, and usually two proxies gets deleted, resulting in the missile not being placed in the right spot, cause of course the script gets interrupted by the error.

4) once this happens, the error usually continues to pop up and you can see a parachute opening and leaving the plane (a removed proxy) each time you pull the trigger. So the proxies stay in the plane till its destruction.

Just to be sure you can put this line in the 'ACES_fired.sqs' script, at the start:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">player globalchat format ["%1",[crew ((_this select 0) select 0),count crew ((_this select 0) select 0)]]

so each time you pull the trigger you can see if any proxy left the plane.

I still don't know why it happens ONLY when the plane is damaged: maybe this has something to do also with the typhoon's scripts, and not only with ACES'.

Quote[/b] ]The problem we discussed in Gnats thread was, after taking so much damage, the AI pilot orders the rear gunner logic to eject.

BTW: did Gnat placed that turret on his B-52? If not, it's now time he does.

[[aps]gnat 28]

BTW: did Gnat placed that turret on his B-52? If not, it's now time he does.

What do you mean Gecko ?

The turret is on my released B52 using the cargo proxy, dead logic method, but because it doesnt work in MP I'm removing it from the next release.

[BlackScorpion 0]

Modern B-52H's don't have the tail turret anyways, removed to save weight and due to lack of effectiveness in modern world.

[UNN 0]

Quote[/b] ]I still don't know why it happens ONLY when the plane is damaged: maybe this has something to do also with the typhoon's scripts, and not only with ACES'.

It does sound like the same problem, we had with the MCar logics? Although aircraft, boats, cars and armour all have their own ways of doing it. It's not exactly a major problem for ACES, as most of the time aircraft probably get destroyed in one or two shots. It tends to show up, when you try and shoot them down with an MG. I posted my suggestion, on the off chance they might want to address the problem.

[sa8gecko 0]

Quote[/b] ]It does sound like the same problem, we had with the MCar logics?

Only at first glance. The proxies are still there, I checked, but not all. One or more is missing.

The line that gives the error (zero divisor) is this one, located in ACES_fired.sqs:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_c = count(_proxies2 select _i)

Perhaps is the newly created unit (_AP), to replace the now expelled proxy (sorry, but you must have present how the script works, so keep it at hand) that, because of the damage, refuses to board the plane.

Here's a picture explaining what happens:

here you can see:

- the plane is damaged

- the trigger was pulled 2 times: the first time was ok, but, together with the right proxy, another one gets deleted (see bottom of the plane, amraam configuration shouldn't be like this)

- the second time a proxy is missed: see last number printed on screen: 12 instead of 13 (pilot + crew). To be precise is 'LOGIC Echo Black 1' that is missed: 'LOGIC Bravo Red 1' took the place of 'LOGIC Bravo Black 1'

- in consequence of this, simultaneously when pulling the trigger the second time, the error message appears.

- continuing pulling the trigger will result in less and less logics be present on board, even though, of course , the ammunition is fired (but, of course, not from the right spot).

Quote[/b] ]It's not exactly a major problem for ACES, as most of the time aircraft probably get destroyed in one or two shots.

no, it's not a major problem, as the missiles get fired anyway. But it's annoying.

[sakura 0]

Sorry guys for the interrupt but how do you get the weapons under the Plane !!

If I wanne fly i never had any weapons on the plane i can only fie them but dont seee them under the plane !! HHHEEELLLPPPPPP!!!!

[sa8gecko 0]

@ Sakura:

you need to place a game logic unit in the mission editor and call it "ACES_LOGIC"

[sakura 0]

yes i know and have the logic placed but if i start the game with the view on the plane the rockets and bombs are there but if i strt the game on the other siede of the island and come to the palne no wapons on it Helppp PPLLLLLEEEEESSSEEE!!!!

[hardrock 1]

I don't get to read the forums as often as I would like to, so I will try to focus on some points discussed here.

@autocenter=0: Thanks for the suggestion, we will try that.

@Removing ACES_LOGIC and using the player's group:

That is something impossible for us. The first goal was to create a logic selectable in the Mission Editor (like ACES Logics -> ACES Init) so the mission maker isn't required to insert the name. I think, if a mission maker really wants to use ACES, it's not asked too much to insert one single logic. That takes only a second of time.

Additionally, there are several points speaking against using the player's group. First of all, the radio messages (which could be somehow avoided). Additionally, if the player's group contains already 12 units, you will get a problem.

So I think the compromise with the logic is a really good one.

@setpos at logic position: As I already stated, I didn't think of that two years ago, but it will be handled like that in the next version of ACES. Regarding calculating the position of every single bomb position on racks, you have to note that we need to make a compromise between performance and features. This is something that absolutely isn't needed (although it would be doable, much is) but would heavily impact on the performance of the fired event handler script. So that will be left away.

@weapons ejecting: As sa8gecko said, this problem was mainly solved by using createUnit with soldier based classes instead of createVehicle with logic based classes (thanks to Terpentin for that solution). There are still some bugs as you have noticed, but hence, this is an alpha version.

Vektorboson is rewriting the two year old ACES core and might find and remove some bugs. The core system will be changed to be more performant, also the config-system will be slightly changed.

I personally don't have a lot of time to work on ACES, but fortunately the rest of the ACES crew is quite motivated. I will try to work together with Vektorboson improving and expanding the ACES core, but don't expect too much for OFP. Armed Assault will bring us nice new commands, which will hopefully help a lot porting ACES over to Armed Assault with better and lighter code.

I know that the Operation FlightSim website (http://ofp.info/hardrock) isn't up to date anymore, but that is mainly due to lack of time. Still, I invite you to get over there and use the forums to discuss any ACES or Eurofighter matters, ask questions or make suggestions on how to change or improve ACES.

hardrock

[sa8gecko 0]

Quote[/b] ] I think, if a mission maker really wants to use ACES, it's not asked too much to insert one single logic. That takes only ....

That was a subject of the conversation between UNN and me, and it wasn't a suggestion. Besides, you can always take the player's group name, ungroup the player, create the logic and grouping it correctly, ungroup the logic, regroup the player. As I said, this is not a suggestion: it's just I like to have the last word

Anyway I say it again to be clear: this wasn't a suggestion but a subject of the conversation between UNN and me: we both have projects involving gamelogics.

Quote[/b] ]This is something that absolutely isn't needed (although it would be doable, much is) but would heavily impact on the performance of the fired event handler script.

first part of the sentence: correct

second part: absolutely not, at least if you (you or Vektorboson) didn't rewrite the script from scratch making it a third of what it's now. It just needs a function (1.5 kb) call in the case a multiple ejection rack is used, plus an entry in .cfg file to tell what proxies to use for the bank angle, plus an array for every multiple rack type you can have ('name of the weapon+AR'="[[1,0,-.8],[1,-.4,-.5],[1,.4,-.5]]" for a TER, for example) to be stored for simplicity in the stringtable.csv file (as well as the function itself, that this way will be readily available in memory without having to load the file before). Did you get my PM with the modified F-4E, Hardrock ? I admit that as you said "This is something that absolutely isn't needed", but it looks good. It looks very good for taking screenshots

I hope you can get the irony and won't jump on me again...

this one is for Kikill: I don't know if you have already corrected it, but give a look at the AIM-9X model.

And about proximity fuses ?

[hardrock 1]

It looks very good for taking screenshots

I hope you can get the irony and won't jump on me again...

Oh, I hope it didn't sound as if I jumped on you. It's just so hot here . . .

Of course I get what you mean. But it wouldn't be one simple calculation, once again you had to consider the plane's direction. A few lines of code for nonsense, you know what I mean anyway.

[UNN 0]

I see, the proxies are being killed as soon as the aircraft is damaged. Only you have to take that into account, if the aircraft makes it back ok. With dead proxies a player can climb into a cargo position. As soon as it's repaired, any AI can also climb in:

I still think events are the best way of avoiding these issues, as you guarantee stopping all the proxy problems, 100% of the time. Without having to create weapon groups, infantry classes, place game logics or worry about blood clouds.

[hardrock 1]

I still think events are the best way of avoiding these issues, as you guarantee stopping all the proxy problems, 100% of the time. Without having to create weapon groups, infantry classes, place game logics or worry about blood clouds.

Negative. If you base the weapons on a logic and add an event handler "Killed" to them, OFP will CTD before the event handler comes into effect. We originally had the weapons based on logics (which avoided the need of the global ACES_LOGIC), but experienced many CTDs when the plane was hit/killed and the logics tried to eject. This is an OFP bug that we can't do anything about.

So the first thing I tried was, of course, to kill or get rid of the weapons using event handlers. Unfortunately this didn't help it, we still got the CTDs. So the final step was to base weapons on Soldiers, which first of all causes the blood splatters and also requires the ACES_LOGIC.

I guess a really good solution will only be available in Armed Assault, if at all . . .

[UNN 0]

Quote[/b] ]Negative. If you base the weapons on a logic and add an event handler "Killed" to them, OFP will CTD before the event handler comes into effect. We originally had the weapons based on logics (which avoided the need of the global ACES_LOGIC), but experienced many CTDs when the plane was hit/killed and the logics tried to eject.

True, but the GetOut event is fired first. The best guess we had was the CTD is caused by the logic (with an invalid group) being moved into a parachute. I say parachute, as it only effects aircraft, and then only when the units are ejecting.

Because the GetOut event handler is called before this, for the very first logic to be kicked out. You can prevent it happening to the rest with one line of code, and replace the exiting logic back into it's correct position. So you can use Createvehicle Logics, prevent the CTD's, remove the geo LOD's (if you wanted) and avoid the problems illustrated above.

But like you said, with Arma around the corner. It's probably not such a big deal.

[hardrock 1]

True, but the GetOut event is fired first.

Interesting fact. I'll keep that in mind.

[sa8gecko 0]

I must say another time that UNN is right and I was wrong. I believed that 'unit disableAI "MOVE" ' was sufficient not to make proxies automatically eject when the plane is damaged. Realized this when the F-4 I made ACES compatible didn't work as I expected. So every ACES plane must have a EH 'hit' that kills every cargo unit in case the damage is greater than a certain value:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">hit = "if(_this select 2>.1)then{_crew=crew (_this select 0)-[gunner (_this select 0)] - [driver (_this select 0)];{_x setdamage 1} foreach _crew;};";

(let's hope no passeger gets ever aboard such a plane...)

but, please, UNN step in and explain your method in details.

In the typhoon this is done by the damage.sqs script, that in addition and in my opinion wrongly, locks the plane so you can't even eject. It seems like WW2 japanese fighter pilots who were compelled to go down with their planes or try desperately to keep them in the air even if burning and looosing pieces, because they didn't bring parachutes to save weight. BANZAI !!!

But not everyone is Saburo Sakai...

Also, the ACES_fired.sqs script needs to be modified: in case the plane is damaged, after the second time the trigger is pulled, the script gets stuck in this section:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">;=========================================================

;Find the proxy that should be changed, hidden etc.

;=========================================================

#findProxy

; left right

; proxies2 format: [ ["Weapon","Weapon"] , ["Weapon","Weapon","Weapon","Weapon","Weapon","Weapon"] , ["Weapon"] ]

_c = count(_proxies2 select _i)

; this loop returns the right array and the index at this array

? (_ind<_c) : goto "checkSide"

_ind = _ind-_c

_i = _i+1

goto "findProxy"

when _i > count _proxies2 .

And of course the new proxy inserted in place of the one expelled must be killed as well, if the plane is damaged. What puzzles me at the moment is why two proxies get deleted the first time the trigger is pulled after the plane has been damaged, screwing up all the rest.

[vektorboson 8]

In the typhoon this is done by the damage.sqs script, that in addition and in my opinion wrongly, locks the plane so you can't even eject. It seems like WW2 japanese fighter pilots who were compelled to go down with their planes or try desperately to keep them in the air even if burning and looosing pieces, because they didn't bring parachutes to save weight. BANZAI !!!  

But not everyone is Saburo Sakai...

Ejecting from the EF is done by pressing special keys (I don't know right now). The action-menu is anyway the worst choice for ejecting, BIS could have made...

[hardrock 1]

Ejecting from the EF is done by pressing special keys (I don't know right now). The action-menu is anyway the worst choice for ejecting, BIS could have made...

Q+V, IIRC

[sa8gecko 0]

Quote[/b] ]What puzzles me at the moment is why two proxies get deleted the first time the trigger is pulled after the plane has been damaged, screwing up all the rest.

Got it. I'm a bit slow, but I think I'm right:

- the plane gets damaged: all the proxies are killed

- the trigger is pulled

- a proxy is ejected

- the new proxy enters the plane BUT SINCE THE OTHER PROXIES ARE DEAD it takes the place of the first cargo position, which contains a dead proxy

- this cause the dead proxy to be ejected and the new one to take its place, in the WRONG position (wrong because it's not the one wanted)

- pulling the trigger again just cause the above process to be repeated: the just inserted proxy gets ejected by the new one and the place left empty by the just fired 'missile' proxy ejected voluntarily by the script doesn't get filled again

So I think that re-living the proxies just for the moment the new one must be inserted should do the trick. I'll try something and will let you know. And if you already know about this you're a bastard because you just let me sweating on this.

EDIT>

putting this line:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">call {if(damage _selP >=1 || !alive(_selP))then{_AP setdamage 1;{_x setdamage 0} forEach (_crew-[_selP]);_AP moveInCargo _plane1;{_x setdamage 1} forEach (_crew-[_selP]);}else{_AP moveInCargo _plane1;_AP disableAI "MOVE";}}

just after these ones:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">;=========================================================

;Normal missiles

;=========================================================

#normal

_selP action ["getout",_plane1]

;replace model

_rd=(random 100) call _fRound

"ACES_PROXY_BASE" createUnit [[0,0,0], group ACES_LOGIC, format["ACES_TMP_%1=this",_rd]]

call format ["_AP=ACES_TMP_%1; ACES_TMP_%1=nil",_rd]

[_AP] join grpNull

in place of this one:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_AP moveInCargo _plane1

should solve the problem. It did, in my case.

[sa8gecko 0]

@ Sakura:

your problem is probably due to the fact that a certain animation isn't executed fast enough.

If you want, you can try the following fix, and then let us know:

- depbo ACES.pbo

- go in the \ACES\scr directory and open up ACES_init.sqs

- after these lines:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">ACES_MACH1 = 800

ACES_MISSILE_CAMS = []

ACES_SELECTED_CAM = 1

insert this one:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">ACES_LOADED =[]

- save the file

- open the file ACES_payload.sqs

- after this line:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">@ACES_DEFINED

insert these ones:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">?((_this select 0) in ACES_LOADED):exit

ACES_LOADED=ACES_LOADED+[_this select 0]

- save the file

- pbo again

Of course this is a quick fix that I just did for myself and probably a future version of ACES will use a different system. Just to be warned.

[sakura 0]

@sa8gecko

Yes Problem solved great guys really !!

All things going well as its possible at this moment!!

[UNN 0]

Quote[/b] ]I must say another time that UNN is right and I was wrong. I believed that 'unit disableAI "MOVE" ' was sufficient not to make proxies automatically eject when the plane is damaged. Realized this when the F-4 I made ACES compatible didn't work as I expected. So every ACES plane must have a EH 'hit' that kills every cargo unit in case the damage is greater than a certain value

No worries. I made a mistake myself regarding logics, thought I had it fixed. The eject problem only shows up when you attack the aircraft with an enemy aircraft. If it's one from your own side they won't eject

Anyway you can't allow the none group logic to eject, without causing a CTD, as Hardrock originally said. But the getin & getout events should still be able to fix the problem.

As you know, if you kill off all the weapons proxies from the start, then they will never eject. All you have to do is prevent the player and the AI from getting into those dead positions.

For the player you can lock the aircraft. Add your own getin & getout user actions, for the drivers position. Then get those to lock and unlock the plane, and move the player with e.t.c

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_Vehicle Lock False

Player Action ["getin driver",_Vehicle]

@(Player==(Driver _Vehicle))

_Vehicle Lock True

That will stop him climbing or moving into a cargo position. The AI will have to be instantly removed using the getin event, if it every tries to get into a cargo position. Also dead logics would make managing the logics positions, a little trickier. Not an ideal solution, I know.

[hardrock 1]

For the player you can lock the aircraft. Add your own getin & getout user actions, for the drivers position. Then get those to lock and unlock the plane, and move the player with e.t.c

Nope. After all, this should work for any plane, also for those with cargo spaces for soldiers.

Also it should IMO be as clean as possible of such work-arounds. They don't really work and cause a lot of inperformant code.

[sa8gecko 0]

Quote[/b] ]Nope. After all, this should work for any plane, also for those with cargo spaces for soldiers.

You certainly know that the current code can't work with passengers. Even with a gunner there could be problems, but this is an easy fix. So UNN should have imagined, as I did, that there's no place in ACES for passengers. Sure it would be interesting to use ACES with choppers too. In my opinion helicopters are far more useful than planes in OFP, and the same will probably be true for ArmA. And of course these choppers (i.e. MH-6, Kiowas or Mi-24 and the like) have cargo spaces for soldiers. So you can no more kill the proxies when the vehicle gets damaged: better yes, you can, but you should not kill the eventual passengers. This is easy to do, checking the passenger type ("man" not to be killed). The problems arise when you have situations like this one:

- a chopper has 6 soldiers aboard, plus pilot and co-pilot

- the choppers gets damaged, and the ACES proxies are killed to prevent them ejecting

- the chopper can anyway continue flying, and it does, and then lands

- the squad aboard disembarks, and the chopper evacuates another squad

- this squad has more units than the allowed passenger seats in the chopper, but anyway less than the total number of cargo proxies

- what will happen next ? I predict that some of the 'weapon' proxies will be ejected, and lost.

You must ensure this can never happen, but is it easy ? Unfortunately you can't tell the AI which 'seat' it can use and which not.

And then, a suggestion:

why don't you use some form of weight check for weapon placing ?

I explain it better: if for every ACES weapon you specify a weight and you require the plane addon maker to specify the weight each pylon can stand, you won't end up having an F-16 with MK84s attached to the wing tips. Also you can specify a total weight of ammo the plane can't exceed, so you won't end up with an F-16 carrying 40 tonnes of ammo. This should be rather easy: for ACES weapon, set an entry in stringtable.csv structured like this:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">ACES_MK84AP_WGH,"900"

where the _WGH suffix is added to the 'weapon' type. This will make easier to insert new entries and checking the weight of each one without having to parse arrays.

For the plane's pylons and the max load weight you can add entries in the plane's .cfg file. If a pylon gets overloaded, simply nothing is installed in its place (just an ACES_PROXY_BASE unit) and a message can advise the player of the situation. If max load is exceeded, nothing more is loaded in the plane (the remaining slots get filled with ACES_PROXY_BASE units) and another message can tell the player about this.

Also, it would be a good thing to prevent east weapons be loaded on west planes and vice-versa. Since I'm not sure if 'side' would work (a western pilot on a eastern plane), this can be easily solved with another entry in stringtable.csv for ACES weapon and a entry in .cfg file for the aircraft.