WildFire

Legendary picture.

I think its about time we enlist the help of some F4 mod programmers. Or any programmer for that matter. I wish I was educated enough to figure it out. If some highly gifted individual were to work on this and perhaps pass it to ED for integration or just release it as a mod, I would be more than willing to donate to the cause. Of course sound files will have to be completely redone and added but its not impossible. Heck, MSFSX and ED so far have shown me that pretty much anything is possible. All I want for christmas........ do da do:music_whistling:

Wait a second.... You got my attention. If you do this change, which I will have to try anyhow, will it work to refuel? Will the tanker see both aircraft and allow you to refuel with it, or does it still recognize each client as a separate flight? Hmm... Ok I see your thinking with SADL, understandable. So we base it off callsigns. So in essence you could not join flights mid-air, unfortunate. But if we could just get it to work with one flight, forget all the joining strike packages and stuff, if we could have a full flight of four working, that would be enough at least.

I'll give these methods a shot when I give it a go next time. Thanks for the input. APU starts arent a problem and Ive been using those for a long time. Just windmilling, I dived from 18000, at 35 degrees until I just about ripped my wings off, had the Bleed Air off and was holding IGN after about 3000 feet of drop. However I wasn't motoring the engine beforehand. Manual doesn't say so. If five cant be accomplished what is the point of 6? And in step 6 it doesnt define "operating". What does that mean, 60%? More? My point was shouldn't we be able to set failures in the ME that don't immediately fireball our engine? And the real main question, has anyone ever been able to fix a failure, hydraulics, engine, flight controls? Like a real failure not like purposely shutting down your engine to get hydro failures or something.

Here's my thoughts on this. So you have a different callsign, as IRL that would not change in flight. However if you were ordered to join another package, your callsign would stay the same however you would change the SADL to match the current package your joining. Which is why this is ok. So even if you had different callsigns you could still join a flight and perform actions such as landing and refueling. This is completely ok. As for memory addressing the solution is simple, at mission start have this trigger~ Hawg1-1 joins game= true , then, reference hawg1-1 SADL code Store variable name (SADL code) = Hawg1-1 (To talk to the tower for startup we would need the SADL to be preset, which is why we need ME privileges). Now everytime the AI calls a command on SADL code blah blah it equals Hawg1-1 and that gets filled into the AI comms script. Create another trigger that is defined by each client changing their SADL at anytime so that variables can be overwritten or destroyed any time SADL codes are changed. What we dont want is the client(s) to join an AI flight. And for this a solution is relatively simple. Limit the given SADL codes for clients. If in the ME a skill is selected then a SADL code is auto-generated like it is now. For each AI in that flight have the same SADL group. However modify the A-10C cockpit so that clients cannot select this set of locked AI groups. It is completely ok to take away some of the group numbers since we should never have 99 groups in one mission anyhow, I would rather have functionality rather than complaining about not being able to create a hundred AI groups. I'm not speaking for everyone but I wouldn't doubt that more mission editors would agree with this rather than less. Feel free to chime in, anyone. I for one also believe that we should be able to set our SADL codes in the editor. Seems as this kind of system would base all AI comms off SADL codes we need to be able to manipulate them and modify them to suit our mission as mission editors. Honestly I cant Imagine why players would ever need more than 20 groups. People want to play together, they want to be in groups, so we don't need that many. Even limited at 20 and running 2-ship flights you have room for 10 flights, which is more than enough. Most mission editors use flights of four so that's even less needed groups. Thanks for all the +1's. I hope we can build enough steam here. Keep posting pilots, bring some major attention to this thread.

I know this has been addressed before, couldn't find it with search, but why cant we have multiple clients in the same flight? The problems off the top of my head are- Jtac would have to send data to all the possible ID's in the flight leads group. Tower comms would have to be redone to take into account multiple ID's in group. Tower comms need improvement anyhow, but for now a tower could just clear a whole flight I would think. I believe that's how it works in real life, doesn't flight lead usually call to tower/approach and declare wing info so the tower can direct and clear the entire flight? Refueling- Here is why I am asking. To be able to have a flight lead contact the tanker, the tanker count the group/unit ID numbers and then only apply the appropriate comms to each client. Each client would have a selection for pre-contact, and abort. If the connected aircraft is not the aircraft that requested pre-contact the tanker would abort. Only the flight lead, or the first ID in the group would have the option for flight abort refueling. If the current aircraft takes on a full load then the tanker automatically clears the next ID for precontact. And they may abort and the tanker will begin its script for the next aircraft/ID in line. This must be a lot to implement in code, but I think its still worth ED's time to look at, cause right now, I believe, in this realistic simulator the most unrealistic thing is the comms. Everything else seems like it has been given a good looking at, or update. Is there another issue out of scope that Im not even hitting on? Seems like the whole system should be based off the SADL codes.

I was playing around with some system failures and I have random failures always on and I was wondering if anyone has been able to use the procedures in the manual to fix a failure? Like an engine failure immediately starts a fire. The manual states to lower power to idle and see if the fire goes out. Which in my experience it never does. Hence I have to put the fire out and I always lose the engine. I've never been able to windmill an engine because the engine operate button does not stay up in the IGN position. I have to hold it, and that doesn't seem to work. And with the APU procedure I always have to set the fuel flow to override. There should be a step for that. Hypoxia is kind of neat, I found it works if you turn your oxygen and cabin pressure off at altitude and wait for it to set in. Although you never actually pass out. I've also noticed whenever I lose hydraulics there is a step to try to maintain pressure, but it never works. So my question is have any of the emergency steps been implemented? Do emergency procedures basically do nothing? Has anyone found different results?

I wish this would have been posted before. I remember reading about a failure and when I lost some hardware on a gun run I tried to follow procedure. I almost got dead. I went into a stall at super low altitude. I recovered but because I only had one engine and it was at low power due to battle damage I never cleared the mountains. Even after full jettison. It was cold. I recovered from stall but ended up circling around and getting chewed up by sir shoots lots of bullets. Should have ejected I was kinda hoping he didnt see my smoking heap in the sky cruise by at 150 knots. Yeah so that didnt work.

The idea is you can add bunkers and roadblocks to groups, so that you can make them part of objectives, or AI targets. So if you send an AI to attack group and you have some bunkers in that group, the bunkers will be destroyed too. Good for hide and seek missions where in order to complete the objective you must find enemy bunkers and destroy them. Could have done this before with a static building, its just being able to set it to a group gives you a few more options. I think that was the intention anyhow..

Yeah if its your zero wp then its already in orbit. However it needs a enroute-refueling action before the orbit action, I think. Unless its automatic these days. I forget. I think its already there when you select the refueling task... Keep in mind the speed you are setting I believe is TAS, or true airspeed. At higher/lower altitudes you will have to tweak it. If I have my tanker up at 25k like up in the mountains then she has to be way way slow, as the A-10 is basically a snail at that altitude. And the tanker will need to carry less fuel to fly at low airspeeds. Anything less than 20k though and you can set it up pretty high. I would suggest finding what your speed is fully loaded and with full fuel at the tankers altitude. It will vary with temperature and pressure conditions. Then subtracting about 10-20% depending on that speed. Your true airspeed is in the editor or can be set with the HUD test mode. It is easier to refuel when you are moving faster, keep in mind any AI or multiplayer aircraft that may be heavier loaded.

Well Guam is a US territory. The rest I believe we have active airbases in and near. Hence if there was a problem in transit they could scramble local fighters in a short time. Except Iceland? I had a friend in Keflavik when it shut down, is there any more bases there? Dont think so. But not a hostile priority in anyway either.

Yeah I'll get a screen in a minute. But yeah if I start a new mission the building is there, and rendered correctly. hence why I know its related to the old version. Looking at the miz file though there is no difference between the old map and the new map. When they put out the patch it should have overwritten the old map so there honestly should be no way the old map could be addressed. Its an odd problem. First screen is shore mission, second is a brand new mission just made.

The tanker will only leave the orbit if you give it a stop condition or switch waypoint triggered I think. It will orbit until it goes bingo, then will RTB. A good racetrack is to set your waypoints (the orbit waypoint and the one directly after it) at least 40 kilometers apart. I often have mine around 100 or more for anything more than a two ship flight that is going to need to refuel.

Ok I notice while testing the missions I redid for Shore so far that in some places I am having this error. Some of the first missions start at Sukhumi and there is a building on the tarmac that wasn't there previously and so when I tried to play it the building was there but the texture is missing. Instead I see the building and its totally orange and I think it has "missing texture" somewhere in there. I've seen it before in previous patches. So my question is; is the map not updating and if not how do I get it to? I unzipped the mission and checked the map names to verify that, and all was correct as far as I could tell. Nothing different as far as the mission or options file. It was missing the new Warehouses file, but as far as I can tell that file has nothing to do with the rendering of units or buildings, it looks to me like it only sets variables. Any ideas? I'm thinking of creating a new mission in this version, and then copying the mission and option files over, then converting it back to miz and then reloading the mission in the editor. I wasn't very successful last time I tried that though.

Our skipper said he flew through only NATO allied countries to get across Europe/Asia. So Im going to have to assume that meant that they didnt have any problems carrying munitions. And I didnt really see a bird leave the deck without at least a missile unless we were near the US. It was a carrier and hence the planes can stay on the boat but for most of the trips we made across the larger ponds they werent with us. I think weight and drag was an issue. It completely astounded me how fast a carrier is, the fastest ship in the fleet, by FAR. When the the reactor is going full steam and the prop is cranking, shes a regular speedboat. For combat deployments we would haul a@# across the pacific and meet up with our planes in Japan, after the pilots had a nice cozy two or three days on their asian vacation. Then we would keep hauling a bit slower fully laden with fuel and aircraft into the AO. When we came home after 11 months we hauled a*# again and our planes flew all the way home from the middle east on their own. That specific cruise was around the globe so we came back to the east coast hence our birds went across Europe. Course the Air force does things a LOT different. I can only speak for the planes I seen leaving the deck.

Moved to the mod section?? Its clearly a blatant joke. moderator fail.

You mean the likely event? Im pretty sure when the zombies hit, due to the high rate of success with A-10's involved in a ground war, that A-10 pilots would be the first to go. That or fat, slow people, its a tossup in my mind.

Basically the mission is tough and your best keeping your eyes out the window. Its just easier and faster, as it is in real life. Some of the variables that make this apparent- foul weather tight valleys lack of engine power in cold weather possible enemy small arms fire So yeah you could keep your head in the tgp, but you might have trouble finding anything. And some of the enemy units dont even show up til much later so the possibility of staring at the TGP for three hours without a hit is likely, and could be amazingly frustrating.

Im still working on shore. Been a long, tough semester but its almost over. Either way if I can pull a miracle it'll be Thanksgiving weekend, if not it will have to be Christmas break or around New Years. And shore has always been broken as far as I know. When I did the first couple of missions I was looking at the triggers and there is no way some of them would have worked. However I thought the ideas and concepts were pretty neat. Hence my desire to fix them. And to let anyone know, the shore has 12 missions, Im on number 6 now. And the first 5 took about a week or two when I had the free time.. Was interested in putting sound files in but I can see this as being a problem with future patches, so I am attempting to keep the campaign as simple as possible.

Much better said, a perfect summation of the thought I was trying to convey. Thank you.

Questions for sir Druid, looking at your method kind of interests me, regardless of my own ability I always observe others for ideas and such, hence my trolling here.... Anyhow, just one question, 1) whenever I made an MP mission with "is damaged" as a condition for an AI, it never worked. Have you been able to somehow get this to work? Or maybe it has been implemented since when I tested it (I think it was .8 ). And thanks for letting us know you dont have to turn a flag off each time, that does cut down a bit. Isnt it neat with this flag system how many options you can come up with to do the same thing?

Can you read lua, and more importantly can you program lua? Cause if you dont know how it works and how to fix the mistakes that your going to accidentally put in, then you dont have any business trying it. What Im saying is its not worth it to try if you dont know the language or at least know a similar language. Honestly Its easier to create a baseline mission with all your triggers in it, then save it to two different files. You can always do that.

The nice thing is you can use one trigger to run its own loop, example being a my second trigger where the flag turns itself on and off by itself. All you have to do is start it and stop it. Start it by flipping that flag at anytime and stop it with a separate unrelated flag. For this method any one of these three will work fine, however the flag 2 line in my example is extremely useful for loops. And that is something you can use in every mission. When you start building very large missions with tons of triggers your going to need triggers that are simple to keep track of, run themselves, and are known to work. When your trying to limit and troubleshoot the million of bugs in every mission being able to keep everything very simple and not depending on each other is important. Therefore I would suggest memorizing this method, it is very useful and will you aid you many times in the future.

If you dont like continuous triggers, I dont, you could do it this way, Once, unit alive(Enemy Unit), Set flag 2 to true SwitchedAction, Time since Flag(2,60) AND Flag 3 false, display message AND set flag 2 off AND set flag 2 on Once, unit dead(enemy unit), set Flag 3 true. Although you will need more conditions to find the right time to activate that first trigger, such as when you activate the enemy group you could just set flag 2 on. Keep in mind the first time will take XX seconds to show the message.

The continuous triggers check the conditions ever second or two I think. Once it starts have it activate another flag. Use this other flag to start your timer. Basically you need something like, Continuous, unit alive, flag 1 on Once, flag 1 on, set flag 2 on have a new set of conditions that is a repeatable trigger that checks for flag 2 every XX seconds. Also have it check that flag 3 is false. in the activation have it display the message, then turn flag 2 off and back on. and in XX seconds it will repeat its actions. When unit dies or is killed add a new condition that sets flag 3 to true, and it will stop.