UNN

It's good to see plenty of British kit comming into ARMA. Being spolit for choice, is not a bad thing.

A said before, you can't directly test for the existance of a file. One method might be to use stringtables in the mission folder? For example if someone wants to overwrite the default value for DMSMOKE_LIFETIME_PARTICLE, they would add this to a stringtable in the mission folder: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">STR_DMSMOKE_LIFETIME_PARTICLE,0.3,,, In your code you would have this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">//See if there is an entry in the string table _NewValue=Localise "STR_DMSMOKE_LIFETIME_PARTICLE"; If (_NewValue=="") Then     {     //Use the default value     DMSMOKE_LIFETIME_PARTICLE=0.7;     }     Else     {     //Use the user defined value     DMSMOKE_LIFETIME_PARTICLE=Call Compile _NewValue;     }; But to be honest, if your using global variables, why not just get the mission editor to set the new values using init.sqf?

Me too, only the balance was never right for H2H IMHO. On average, something that played out closer to the history would have been better. I just wish you could have more than two people instead of just H2H. It's not like the game play has even come close to advancing beyond today’s technology. If you're going to re-release it, add something significant!

Actually you can do it via the confg and you don't even have to pay for it But you’re still faced with the same old problem. Configure it as a tank or a car? As a tank you can get the tracked suspension to work e.t.c As a car you can't, although you can animate the tracks using model.cfg

At the moment I'm writing the core system scripts, so the Cargo scripts can interact with the rest of our addons. That’s almost finished, but I still have a couple of things to add to the Cargo system. Once there done, I just have to decide what objects and vehicles to include for the initial release. So still a little way of just yet, but it's getting there.

I think that was about it. What I read from the official statements was: Making Arma's content available to Arma addon makers for the game in general is ok. Making Arma's addons available to other games is not, at least without prior consent. I don’t think BI did anything different from when they stepped in to protect addon makers, from the Dawar's escapade? I don't know how all that was resolved. But if BI are willing to uphold the rights of addon makers, then addon makers should uphold the rights of BI.

I can't ever remember seeing anyone who has used such words on the forums without a Moderators intervention? But then, I can't see how you would want to apply a term such as "shithead" to anything living? Putting that aside for one moment. I like the whole era, so more addons of this kind are much welcomed. Good job

Well not exactly sure myself, it was something I read on the ACES forum. But it sounds like the same problems we have with the OnMapSingleClick command. As in, one persons scripts or addon, can overwrite what’s been assigned to either the display event handler, or the map click event, of another script or addon. I know it means more work on you're part, but it seamed like the init event handler has already set a precedent in this area, so it's kind of a natural extension? Perhaps a little different, in that it really needs a set of scripts for addon free missions as well.

Yeah, I made a similar suggestion here: http://www.flashpoint1985.com/cgi-bin....t=70000 Right at the bottom of the thread. Just in case you didn't test them, the same applies for config useraction conditions and probably trigger conditions to.

Are there any plans to add support for the DisplayEventHandler? I believe that also suffers from similar problems to the init event. Cheers

Yeah, we (@RKSL) are looking at introducing smaller components over a period of time, while still keeping each addon stand alone, where possible. So version control of pbo’s gets a little more complicated and we have to go to extra lengths. But I will continue this on the ACES forum, as I've already read the thread you're quoting from, I just didn't have time to add anything there. I understand about breaking a large MOD like ACES into modules. As Rock said, we are doing the same at RKSL. But the thread was really about individual addons, which may or may not, eventually end up in larger MODS. It kind of seem a bit over the top to suggest using the same approach for a single unit, released by one addon maker. The time taken to repack a single p3d and small config is minimal to say the least. Again, five or more pbo's for a large MOD like ACES is fine. But a single addon, I'm not so sure.

I would certainly be interested in hearing opinions on version control, that does not undermine the structure of previously made user missions. If someone makes, say a tank addon. Should they have separate addons for the sounds, textures, config, p3d and scripts. Five pbo's for just one addon? Again thinking of version control. Five addons does seam a bit excessive for one tank? With regards to the length of time it takes to make a single model, config, textures, scripts, sounds e.t.c verses a fourth party large scale config Mod. Please take into account that, there is only one large scale config required for a fourth party mod. There may be 30+ individual addons included in that Mod. So in effect, you are saying that a large scale fourth party Mod is the equivalent to, if not more than, the amount of man hour that goes into 30+ addons? To me, the maths just don’t add up!

You might as well exclude the object from your dialog, using it's class name. No object exists within ARMA for the Townhall, thats why you get the CTD.

Actually that’s not exactly true. Although this is a complicated thread to follow, seen as it's running multiple topics: How can addon design best facilitate large scale fourth party config MODs. How can addon design best facilitate the addon makers. Along side those two topics you also have the issues of: Large scale fourth party config MODS having trouble obtaining permissions and access to use third party addons Individual addon makers seeing their work being credited to somebody else's MOD If you look at each individual topic on it's own, then you can see where the conflicts lie. How can addon design best facilitate large scale fourth party config MODs. Of course anyone who is interested in, or creates large scale config mods, will see the benefits in Terox's proposal. It makes their life easier and requires them to do less work to produce their config mod. Many of the replies have been centred around "it makes more work for us, so why not do it this way". While It's not unreasonable to want make the things you enjoy doing, easier and more efficient. It is unfair to expect individual addon makers to shoulder that burden. How can addon design best facilitate the addon makers. I can only speak for myself on this topic. But I think breaking down addons into multiple pbo's causes major headaches when it comes to version control. Large scale config Mods do not have to worry about version control, they release their work on mass. Individual addon makers do have to worry about version control. So again, I by default will prefer a method that makes life easier for myself, as an individual addon maker. Large scale fourth party config MODS having trouble obtaining permissions and access to use third party addons I think Terox has covered the problems he faces with regards to permissions in his original post? As I've never made a large scale config Mod, I am not going to presume to know the problems involved. So I can't add anything to this. Individual addon makers seeing thier work being credited to somebody else's MOD ryankaplan should have been around long enough to notice how someone can be credited with an addon simple because they were the last person to modify the original config. I've lost track of the threads I've seen were someone, in all innocence, has posted a modified version of an existing addon. Despite the fact that the person releasing the modified addon, repeatdly credits the original addon maker in his initial post. You only have to scroll half way down the page before you find a string of post congratulating the guy who modified the config, for making such a great model. Like I said, the guy who modified the config never tried to deceive anyone or lay claim to someone else’s work. Only not everyone reads the readme or reads beyond the download url, in the original post. Some people may think this is a trivial matter, but when you have spent months (perhaps years) working an individual addon. It can be very disappointing to see your efforts being swallowed up by some glitzy ad campaign for the latest config mod. I think it's safe to say, reading the posts in this thread that: There is not one solution that works for everyone So the natural conclusion should be to cooperate in finding some sort of compromise for everyone's requirements. While it might not be the ideal solution for each party, it can't harm to talk in a calm and rational manner, about how we can try to help each other out?

I'm not fighting anything, I have no reason to. I was interested in what the perceived problems were. If I don't understand something, or something does not appear to make sense. I can't help but ask questions

One thing is for sure, at this point in time I don't make missions, so I'm interested in what is required. Only I'm a little confused about the requirements. I'm assuming the missions (in the example you posited) have already been created for the TEROX_MOD* and not the original addon class? So I'm assuming the class names should always remain the same, only the content they point to differs. So Terox (sorry to hijack you as an example) would have ultimate control over the class names, so he can ensure missions made for his large scale config MOD always remain the same. As with any other third party addon MOD? The missions created for the original class names are effectively, out of his control. I'm assuming large scale fourth party MODS do not use the original class names, but create their own? We are talking about text files are'nt we? There are plenty of search and replace programs that could do the job in seconds. Again, if it really is common practice to have to edit hundreds of mission per addon, then the process should be automated. Automation should make some of these issues mute. In this case I was referring to the the main config as the defining config for the large scale mod in question. Addon dependencies defined in configs look for corresponding entires in cfgPatches. As long as they are present Arma does not care if the actual pbo's exists. So Arma would load fine with a ghost cfgPatchs entry. It would however, crash when you try to create a unit that points to say a p3d that is not present. So the trick to avoid this would be to prevent invalid mission content from being called i.e scope. AFAIK you can't alter a specific class, but you can alter the immediate class it inherits from. For example you could have a bad config like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Tank; class UNN_NewTank : Tank    {    \\My stuff goes here    }; Or a good config like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Tank; class UNN_BaseTank : Tank {}; class UNN_NewTank : UNN_BaseTank    {    Scope=2;    \\My stuff goes here    }; Having the additional layer allows me to override all the inheritance for just my tanks and not all of Arma's default tanks. So a fourth party mod could define this config, to remove my original tank config from the mission editor menu's, and reduce potential clutter for the new large scale MOD: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Tank; class UNN_NewTank; class UNN_BaseTank : Tank    {    Scope=1;    }; class TEROX_MOD_Tank : UNN_NewTank    {    Scope=2;    \\Terox's stuff goes here    }; Without that additional layer, you would have to redefine all the classes that inherit from the original Arma class Tank. When realy you are just interested in the classes that inherit from the UNN tank classes. I'm not sure I have explained this very well. Perhaps Q can confirm this one way or another. From what I have tested so far, you need access to the preceding class layer, to make such changes? Edit: Modified config examples

To use the term better, would mean it was worse if they did exist. I think it's more a case of them not having any noticeable effect either way. Can't say I've gone into it in great detail. But some dependencies are only written to the mission.sqs when the addons are created in game. But if you start changing addons in a mission, then you have to expect to do some work. I usually just delete all the dependencies then load the mission into the editor and run it and save. Takes about 1 minute? Don't know about RHS addons, but if you’re talking about changing textures, then that’s modifying the p3d. I thought Terox wanted to avoid that? I can see your point when it comes to weapon packs. If a soldier is configed for a particular weapons pack, that isn't used, it seems like a waste to have to include it? But in that case you could write a null definition within the main config. Just a config.cpp entry that satisfies the addon dependencies. Which would probably just be  a line or two in cfgPatches? There is a lot addon makers can do, to allow more flexibility with dependencies. Most of the stuff I'm writing can auto detect the presence of particular pbo's and act accordingly. The bit I added about hiding third party addons was incorrect, it requires addon makers to adopt the sort of thing Q is doing with WGL, so it won't work for old addons. Creating bases class that inherit from the standard classes, allowing you to override things like scope. There are certainly things addon makers can do to help people further on down the line.

The only time I've had a CTD when creating objects, is when either the main p3d can't be found, or a proxy in the p3d can't be found. There may be other ways, but for me that’s the main cause. But I don't understand what you’re trying to do. You mentioned about editor updates, is the editor update causing the CTD? Or are you making your own objects using the content of the editor update? Arrays that contain other arrays can be many things. Objects are also pointers Assuming the new PublicVariable command won't help with nested arrays? Then depending on what sort of info is in the array, it can be very easy. For example, if you have an array of letters and numbers: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">MYARRAY=[1,2,3,["A","B","C"]] MYARRAY can be converted to a string, broadcast over the network, and converted back into an array on the clients. If your Array contains either array pointers or objects, groups e.t.c Then you still have the same problem, you will have to do something along the lines of my previous post. Given the variable names you used in your example. I can only assume they are objects? Of course you can circumvent that particular problem if you populate your arrays on each client, as and when the objects are created.

Actually you have a fourth choice, which doesn't require any modification to the original pbo: (4)Create your own config for the mod and inherit all the required classes from the original pbo. Modify the inherited classes to conform to whatever standards you want. Its even possible to prevent the original units from appearing in the editor while the new MOD is installed, so no worries about clutter in the mission editor. Unless you want to physically change the p3d or textures, then this method is the least problematic. As it allows you to use content from authors who may have left the community, without breaching any copyrights. Inheritance, is not something an addon maker should object to on it’s own. Nobody expects to ask permission to use third party addons in a mission? But when your packaging someone elses addons into your own mod, there is a danger that people will assume you created all the content. So at the very least you should seek approval from the original authors. Don’t get me wrong. I’m all for a modular approach to the content of pbo’s. But it should be done to aid the design and support of addons. Not to facilitate large, fourth party, collective mods.

There are a couple of ways, depending on how the object was setup. Perhaps the best method now, would be to see if the class name exist in the configs. Take a look at config_name or one of the related commands. Although I'm sure there is a better command, only I can never remember what it is Yes, but if your looking for an easy way, then no. You have to add the references yourself. Say you had an array setup like: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">MYFIRSTARRAY=[A,B,C,D]; MYSECONDARRAY=[1,2,3,4,MYFIRSTARRAY]; Assuming MYFIRSTARRAY has already been initialised on the client, you could broadcast MYSECONDARRAY, after converting it to something like: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[1,2,3,4,"ARRAYPOINTER:MYFIRSTARRAY"] When MYSECONDARRAY is updated on a client, you could write a function that searches for the tag ARRAYPOINTER: and converts the suffix MYFIRSTARRAY to a variable, which is then implanted as an array pointer, into the original array to replace the text string "ARRAYPOINTER:MYFIRSTARRAY". Sorry I can't be anymore specific about all this, only I've never had to so this as yet, so it's all just theory. But it will work under given circumstances.

@Rommel What you're trying to do here: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_dummygroup = Â format ["%1grp", _side]; If (_dummygroup == "WESTgrp") then {_dummygroup = WESTgrp;} else { }; Could be done like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_dummygroup=Call Compile format ["%1grp", _side];

It's well established knowledge that what you hear from some guy who posted in some forum, always has a cunning incite into the motivations of any individual, all via the magic of internet protocols. Any sane person would be wise to listen to some bloke on some forum, with the utmost austerity when it comes to an almost omnipotent factual content. While I can understand this bloke, on whatever forum, wants to remain incognito. But thanks to the brave Kaio23, the biggest scandal since Watergate has been unveiled before our very eyes. The names might change, but the garbage they spout remains the same

The easiest way is to create a trigger that covers the entire map, set to detect anybody (or perhaps OPFOR). Call it MyTrigger. Then run this script: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_Target=ObjNull; WaitUntil     {     //Wait until a target it created     WaitUntil         {         _List=List MyTrigger;         {If ((_TypeOf _x)=="laserTargetW") Then {_Target=_x}} ForEach _List;                !(IsNull _Target)         };     //Update marker position here     //Wait until the designator is turned off         WaitUntil         {         IsNull _Target         };     //Update marker position here     //Repeat unless the Player (guy carrying the designator?) is killed     !(Alive Player)     }; Of course the above code only covers one laser target per mission for side west. Like I said, it's just a simple example. The laser target created by a unit on side west, is set to hostile (side east) so other west units will attack it.

We haven't finalised exactly what's required. But at the very least, we are looking for something that will work for both MP and SP. With the ability to map\modify a flight path before or during flight. The mechanics of getting the UAV into the air and back on the ground again, will be handled by a player. We would also like to allow the UAV to be useable by the AI, for anyone who wants to play a supporting role to it. With the flight paths and target priority set by the mission designer. The final phase of our goals, and the most ambitious. Is a fully autonomous system, were the AI or player can decide where and when to deploy the UAV, according to what happens during a mission and coordinate with whatever resources are available to it. So it really depends on how easy it is, for any third party system, to satisfy all of these requirements. I think the deciding factor will be, what hoops we have to jump through, to get Arma's AI to comply with all of the above. If it means we have to write our own system then that’s ok. Also as Rock said before, if someone has their own model\system, then it should be easy enough to bolt on our Laser Designator, if they want to use it.

As SickBoy pointed out, it's an object-datatype until you delete it, so no need to convert anything.