UNN
Member-
Content Count
1767 -
Joined
-
Last visited
-
Medals
-
Medals
Everything posted by UNN
-
If you mean directly, then no, I don't think you can. Indirectly, you have a few more options. Using either a single global variable\array or the setVariable command. Something like: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">MAN01 AddAction ["An Action","AScript.sqf"]; AScript.sqf: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">(_This Select 0) setVariable ["SCRIPTPOINTER",_This ExecVM "TheRealScript.sqf"] UserActions are a bit clunky, can't Spawn or Call code with them either. Unless you do something similar to the above.
-
The eject action is a global command. Anyone will be ejected, as long as there is one person playing, that isn't in the list. Something like this will do: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">If !(Name (Driver ah1a) in gol_rf) Then {If (Local (Driver ah1a)) Then {(Driver ah1a) Action ["Eject",ah1a]; Hint "Only -{GOL}- can fly the Attack choppers"}} That should be enough
-
Try this, just to see if the aircraft work? (untested): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class CfgPatches     {     class DMSmokeEffects         {         units[] = {};         weapons[] = {};         requiredVersion = 1.08;         requiredAddons[] = {"CAAir", "CAAir3", "CAData","CATracked", "CAA10", "CaWheeled", "CaWheeled3"};         };     }; class CfgVehicles     {     class Air;         class Plane : Air         {         class eventhandlers             {             killed = "_this execVM ""DMSmokeEffects\Scripts\DMSmokeEffects.sqf""";             };         };     class Helicopter : Air         {         class eventhandlers             {             killed = "_this execVM ""DMSmokeEffects\Scripts\DMSmokeEffects.sqf""";             };         };     };
-
There are a couple of examples of user actions here: http://www.flashpoint1985.com/cgi-bin....2;st=15
-
I'm not sure if the required addons order will help in this case, as you pointed out the empty class definitions are the problem. I think DMarkwick will have to move up a class to get the events working. Add your events to the following classes, then you should be ok: LandVehicle Plane Helicopter Ship Man (if you want infantry to) I think that about covers it, but I may have missed some out?
-
Yeah, it's something we’ve been discussing amongst the team. It is possible thanks to some of the new Arma commands. There are limitations, those kind of lights don't cast shadows. But they’re ideal for things like interior lighting and instrument panels.
-
No, it's more to do with how the engine draws other objects when you’re sat in a cargo position. As long the vehicle is not moving and has a suitable geometry LOD, there is no problem with walking into a vehicle and sitting down in a specific seat or driving another vehicle into the back. But if your watching the process from a unit sat in a cargo position, then it can draw the boarding units at the wrong scale or draws them as though the are actually outside the vehicle. I will certainly keep an eye out to see when and where this problem occurs. That way we might be able to narrow it down. But its not fatal and only happens if you’re sat in a cargo position watching something else moving around inside the vehicle.
-
I suspect your going to have to live with a limitation for this current engine? It's easy enough to walk\drive into a Cargo LOD. But drawing objects internally that, as far as the engine is concerned, exist outside, is another thing. I've noticed in the Arma engine the same problem with OFP…Hmm...I'm struggling to put this in a half decent way...But objects that exist in world coordinates (outside and independent of a vehicle) are not drawn in the same way as objects that occupy an internal LOD like cargo, pilot positions e.t.c While it will work. You may have to turn a blind eye every now and again
-
Yeah, thats not a bad start. I used that myself. You can also unpack the config from inside Bin.pbo and get the styles e.t.c For all the Arma dialogs. Look for things like class RscDisplayGear. To preview that particular dialog and the others. Run this from a radio trigger: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">pDialog=CreateDialog "RscDisplayGear"
-
Checking the content of an Array?
UNN replied to ZNorQ's topic in ARMA - MISSION EDITING & SCRIPTING
Can you draw a comparison? I'm trying to think of a programming language that lets you compare mixed content like pointers and such? I haven’t done any windows programming for quite some time. So perhaps I'm missing something? -
How to destroy variables so ArmA doesn't save them
UNN replied to mrn's topic in ARMA - MISSION EDITING & SCRIPTING
Yeah, I missed the Call commands from the then statement second time around. Didn't realise, until I read the error Mrn posted, that isNill takes either code or strings. But like I said, I wasn't tested Still don't know if this will actualy remove the variables from the savegame file either. -
How to destroy variables so ArmA doesn't save them
UNN replied to mrn's topic in ARMA - MISSION EDITING & SCRIPTING
@T_D thats what I was about to post Well if it requires type string or code, then give it what it wants: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{if !(isnil (Compile Format ["%1",vehicleVarName _x])) then {Call Compile Format ["%1=nil",vehicleVarName _x]}} foreach _logics Or perhaps: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{if !(isnil (Format ["%1",vehicleVarName _x])) then {Call Compile Format ["%1=nil",vehicleVarName _x]}} foreach _logics Yes, it would be quite interesting. Edit: Fixed typo -
How to destroy variables so ArmA doesn't save them
UNN replied to mrn's topic in ARMA - MISSION EDITING & SCRIPTING
There are others, but it would take this off topic... <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if !(isnil ("vehicleVarName _x")) then { _x setVehicleVarName nil;} foreach _logics To remove the editor placed, variable names on the logics? You could try: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{if !(isnil (Call Compile Format ["%1",vehicleVarName _x])) then {Call Compile Format ["%1=nil",vehicleVarName _x]}} foreach _logics Assuming you placed and named the logics using the mission editor? Not tested the code, so it might need tweaking. JIP and re-spawn not guaranteed. -
Yeah, apart from the obvious difference of no visible cargo objects. I have to use map icons when dragging and dropping with the script version. But other than those two, it will work the same, with either addons or scripts. This looks like an interesting thread, along with some other methods. At worst, we will use a rigid rope, with some restriction on the transporters ability to pull stunts. At best, we are hoping for something that looks and feels, more life like.
-
I should know better than to skim through posts. Anyway, you peaked my curiosity, so I had to give it a try I think this was what you were suggesting? MyBaseClass.pbo: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class CfgPatches     {     class MyBaseClass         {         units[] = {};         weapons[] = {};         requiredVersion = 0.1;         requiredAddons[] = {CACharacters};         };     }; class cfgVehicles     {     class Land;     class Man : Land         {         class eventhandlers             {             fired="Hint ""Bang Bang""";             };         };     }; AWestSoldier.pbo: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class CfgPatches     {     class AWestSoldier         {         units[] = {"AWestSoldier"};         weapons[] = {};         requiredVersion = 0.1;         requiredAddons[] = {};         };     }; class cfgVehicles     {     class SoldierWB;     class AWestSoldier : SoldierWB         {         Scope=2;         DisplayName="My New Soldier";         };     }; For the AWestSoldier.pbo config I did'nt bother adding the requiredAddons section. As I think this would be closer to what DMarkWick originaly wanted. If you imagine AWestSoldier.pbo could be an addon that was created and released before his own addon. It all seemed to work ok. But there was one issue, the Hint now shows up for any unit placed on the map simply because the addon was present in the addons folder. So it would effect every mission, regardless of whether the mission designer\server admin wanted that or not. But if you change the config for MyBaseClass.pbo to add a logic as an effect switch: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class CfgPatches     {     class MyBaseClass         {         units[] = {"DMWSwitchEffects"};         weapons[] = {};         requiredVersion = 0.1;         requiredAddons[] = {CACharacters};         };     }; class cfgVehicles     {     class Logic;     class DMWSwitchEffects : Logic         {         DisplayName="Enable DMW Effects";         class eventhandlers             {             init="DMWEFFECTS=True";             };         };     class Land;     class Man : Land         {         class eventhandlers             {             fired="If DMWEFFECTS Then {Hint ""Bang Bang""}";             };         };     }; Ok, so your adding an extra event handler to every infantry guy in every mission played, while the addon is installed. Even if they do not want to use the effects scripts for that particular mission. In most cases it probably won't have any adverse effect. So all in all I think it works out as a better solution to a giant trigger Â
-
Out of curiosity, which do you think would be easier to learn for someone who has never done any programing before. C++ or the Arma\OFP script language? P.S You would'nt by any chance, have been previously banned from these forums?
-
I see what your getting at. We did something similar in OFP for the Rapiers. The Ammo packs were configured to only resupply a specific type. It would certainly add to the rational of the system. Rather than Arma's default, game orientated, one size fits all approach. I will try and add something along those lines for the release. Cheers
-
Yeah, I looked at those for the 5ton truck. There a bit of an odd size for that vehicle, thanks to the seats in the back. It's a shame the flat bed fuel truck version, isn't available without the barrels. But I'll see if crates work with some of the other vehicles. Lol...I don't want to get distracted atm with creating new objects from the Arma proxies. But the config for the proxies are pretty straight forward and work with O2 in Arma. If anyone is that way inclined. It's certainly possible to make dynamic palletes, using the same principle as Col Klinks gun racks in OFP. I'm just not sure if you can convert them into suitable proxies for transport. At worst, you might have to create 12 different objects (all proxy based so it would total 36kb in size), showing a pallete loaded with anything from 1 to 12 crates. At the very least you could just have a fixed pallete of 12 crates that acts like one giant ammo box.
-
I forgot to say, I updated the config to this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class cfgVehicles     {     class House;     class MyHouse : House         {         scope=2;         displayName="My House";         model = "\ca\buildings\Misc\KBud";         animated = 1;         class AnimationSources             {             class Dvere1                 {                 source = "user";                 animPeriod = 6;                 initPhase=0;                 };             };         };     }; Not sure if it needs to be binarized? Especially when you take a look at this on the wiki: ODOL v40 File Format And this older version: P3D File Format - ODOLV40 There's plenty in there that you can't do with O2. Model configs are not really my thing, so perhaps someone can work out whats missing for buildings?
-
Planes rock the wings constantly while attacking
UNN replied to RN Malboeuf's topic in ARMA : CONFIGS AND SCRIPTING (addons)
Well it was a question rather than a solution….Still waiting for the answer...But believe it or not, the logic involved with re-aligning with an old target, is not that different to aligning with a new target. -
I can only assume MIG didn’t have the same problem. As it happens, since then, I tested it a little bit more. If you replace: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">model="\MyHouse\MyHouse.p3d"; With: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">model="\CA\Buildings\Misc\KBud" The animation works fine. So I guess it's down to the p3d. BTW KBud is Arma's default model for the outside toilet
-
Planes rock the wings constantly while attacking
UNN replied to RN Malboeuf's topic in ARMA : CONFIGS AND SCRIPTING (addons)
Have you switched to the AI pilot view while testing? I noticed something similar with the AV, it appeared to be trying to constantly line up with the target. But would keep over compensating, then try to re-adjust. -
I see, sorry. I only read this line fully (and weedomatic's original post): Weedomatic suggested something different to the WGL method, so I did not think to read on. With the new method of inheriting in Arma, a third party addon might only declare: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Class SoldierWB; e.t.c In thier config. But if it does still work then that is a better solution.
-
There is an element of eye candy for the mind, to it. You don't really need to have visible cargo. But there is some tactical advantage to it as well. At least in some cases, you can see what vehicles are carrying and act accordingly. Not sure how realistic it is? But something like this: Would be really handy for me, when it comes to scouting in a CTI. Seen as I prefer to play as a Squad Leader. BTW If there are any other default Arma objects you would like to see as cargo. Let us know.
-
I think DMarkwick wants his scripts to run with all addons, rather than a specific addon? This way he can automaticaly support the default Arma units as well as those made by other mods. Without having to keep creating new configs and pbos every time someone releases new units.