DD_Friar

@Gunslinger52 - Without looking at the mission my first thought was either you have used a static model or not ticked the "player drivable" on the unit. I assume you have Combined Arms as well as that is needed. I will have a look at the mission later and let you know. I am at work at the moment.

Module: cargoReceiver @cfrag or anyone else that has used the module, I would appreciate your advice / feedback. Having added cargoManager and cargoReceiver modules to my mission, when picking up a cargo, I assume I still use the default DCS cargo assignment (via Comms "All cargo") to generate the smoke above the cargo? I create my cargo via an objectSpawn zone from a radio menu command. It is just that I am sling loading my cargo and dropping in my cargoReceiver zone which should generate a message but nothing is happening? I am releasing when I get the voice command "the cargo is on the ground" and I am within my cargo Receiver zone? Any tips / experience from anyone using this module? Does what I describe sound like it should all be ok?

Got it, thanks my code now works.

@cfrag Do you have a resource for the correct cargo item descriptions to supply to objectSpawn Zone please? I have just tried as per the ME but does seem to work. I am looking for the Huey netted one and the container?

@Gunslinger52 Please find attached a mission which will hopefully help you. nullI have a couple of tips / pointers as well. set your scripts to load at mission start I have included a little trick (that is in the user guide) of adding a blank message with clearview ticked that hides the script loading messages. in your original mission you had the message text as a flag (with a !) which is why you got no message. Moving Humvee.miz

Hi @Gunslinger52, no, when a plane takes off the state of landedAtZone1 remains unchanged. departedAtZone1 however does get changed. Other zones are looking for a change to the state of the flag, not by default a value. I will take a look at you mission for you and see what I can find. I thought I had posted this message but obviously did'nt. cfrag has also posted what I said above

I think you may have a version typo... null

@Gunslinger52 When using the LZ module, as you say you have two flags landed! and departed! (these two have ! at the end meaning they are flags being updated) Your other modules that are watching these two flags for activity are not just looking for it to be equal to 1 (although you can achieve that if that is what your mission logic needs but I don't think that is applicable here) they are looking for a change in its state/value. Lets say you have the flag "landedAtZone1" against the landed! parameter and "departedZone1" against departed! I land in the zone, "landedAtZone1" is hit and, by default, incremented. I have a another module, lets say a cloner. You want a vehicle to activate on the landing. That will have a parameter called clone? and flag that is "landedAtZone1" (LZ is the Yeller, Clone is the Listener "LZ to Clone are you receiving Over - Go ahead LZ Over, - This is LZ, we have a landing in Zone 1, Over - Roger That LZ I will send out the trucks, this is Clone Out."). "This will action every time landedAtZone1 changes". Multiple landings means multiple clones. Same applied to "departedAtZone1".

I don't actually work FOR the software house, well, used to, but they decided they no longer needed my services so I set up on my own, but funnily enough I was once the IT Manager for a Wine Merchants

@cfrag ref Yeller Documentation Just to support you in your method, as a job, I provide consultancy and support for a set of applications that share common data e.g. employee information. They have exactly the same approach. Each application when produced, has a set of values that it is willing to offer or "publish", it also has a set of values it requires or "subscriptions". For example the HR application will offer up a new employee name, start date, address. The Payroll application is listening for that information, the payroll application will offer up last pay date which the HR application is listening for. To sum up you have exactly hit on an approach that is currently being used by a multi-million pound software house.

@cfrag We the un-worthy are forever in your shadow of greatness for providing so many great updates. Just to re-assure you, I too am now a devotee of the Debugger Module, I have seen the light... Salute and many thanks once again. Regards Friar

As of 6th November this issue is still there. null

@cfrag I have checked my logic and adding the raiseflag at the start to set the value of the keyDestroyedBuilding seems the only way to get this working. As I plan to use Persistence on this mission, should I produce 2 versions, the first version that has the raiseflag function at the start and another that does not for subsequent runs of the mission where flag values are loaded as I do not want to re-set the destroyed building values if they were hit in a previous session?

Many thanks for taking the time to have a look. I fully suspect that was caused by me doing copy paste from the quick reference guide (as I often do). Usually I am aware of it and delete it out. Ok I will take another look with the edits I added after posting (keyBuildingDestroyed set to 1 at mission start and the objectDestroyed parameter set to off to change from 1 to 0 when banged) to see if my original logic would have been ok.

@cfrag Please find attached a small test mission where I am trying to solve my logic issue. It now has the debugger and I have been using it to change values of flags. My convoy only starts when keyBuildingDestroyed = 1 which is incorrect. If you have a minute are you able to take a look and suggest what I am doing wrong please? EDIT: After posting this mission I came up with an idea which I think solves the issue. At mission start I had added RaiseFlag to set the value of keyBuildingDestroyed to 1 (1 now equals a live building). I have added a method change parameter to "off" on the "objectdestructor" module which will change the 1 to a 0 when the building is destroyed. With this value the gate is then closed that passes the signal to the goConvoy. ChangerLogic.miz

ok, sorry about that. Let me put it a different way then. Can you check please the way the convoy module looks for the state of flags when the mission starts. I believe that it does not check their status and only reacts when they are banged AFTER the mission has started. My example was the owner of the airfield was set in the ME so was red when the mission started. Convoy seems to react only when a flag gets changed due to it being banged by another module.

@cfrag - Please may I ask, did you see the above post I made a few posts ago? It was in the middle of a couple of my posts where I answered myself and may have got lost in the mire.

Having just now looked at what it can do, I see now instead of me having to place units in the ME that go and do things to trigger the flags I need, I just need to use the debugger to manually change them. For example, at the moment in my test I have an airfield zone and manually drive a vehicle into the zone to capture it / trigger the "ownerairfield" flag value to change. Now all I have to do is to add a mark point and give it "-set ownerairfield 2" I now get the massive potential and assistance this can give. Shame on me for not exploring this sooner... null

Sir, that was my intention of posting the scenario in a specific mission that demonstrates the logic (and where I am going wrong) so that I can correct it. With respect to your Lordship, I will have a look at how I can use the debugger in the future.

@cfrag - I must have stared at that logic for hours on Sunday afternoon and did not spot that.! Dam you! That said, it has not solved my issue. May I ask, do you have Combined Arms? I would like to post a very simple mission that will hopefully explain the scenario better and one that you and others could use to help me fix my logic and one that if they wanted to implement the same scenario. I ask about CA as I am using a tank in front of a small building that I can shoot and blow up as it is easier to test? regards Friar

Hmmm. I'm not sure I can follow. Yes I can see why That should have said the convoy is NOT generating, but it should as the building has not been destroyed. My tests so far are as with the code snipits as provided. The airfield changes from red to blue, which should then trigger the red convoy. At the moment nothing happens. Other than the "ownerairfield" flag none of the other flags seem to being affected.

In my initial tests I am playing with the building in-tact so the convoy should generate as the building has not been destroyed, but its generating.

Take a look at the DML Toolbox by @cfrag. This is as excellent utility (NOT a mod) that gives you the ability to add scripts to your mission with absolutely no scripting skill required. Also if you build a mission for multiplayer your other players DO NOT have to download / install anything extra. All the magic is in the mission you build. You build you mission by using zones with controlling parameters. Using this tool has completely changed the way I build my missions. I can not recommend it highly enough. You can find all the details here.... For example using the "Spawn Zone" module you can achieve the below.... null

@cfrag or anyone else that can see what is going on - all advice welcome! Salute one and all, I am currently trying to implement a scenario where attacking convoys are only created if key building have not been destroyed, a sort of way of encouraging blue forces to strike key infrastructure buildings to weaken enemy response. These buildings my not be where I want the convoys to start from, hence have shied away from the "factory" module (is that the right thing to do?) I have tried to use the changer module as a gate but have got something wrong as with the key building in tact the convoy still fails to spawn. I attached a below a screenshot of my logic which I can not get to work and and would very much welcome some pointers The convoy should spawn if "ownerairfield" = 2 and "testbuildingdestroyed" = 0 null

@cfrag Modules: Convoy and Clone Zone (and possibly Airfield) Issue: Difference in spawn logic at mission start Salute Sir, I think I may have found a difference in the way the two (or three?) modules behave at the start of a mission. I believe the new logic you added for the convoy module may differ slightly from that of the approach the Clone Zone (and airfield?) uses. Clone Zone example - I have an "ownedZone" set to "red" within the parameters. I then have a nearby "cloner" that uses the "ownedBy#" flag and a "cloneTriggerMethod" set to =1 for the spawn to take place. If the town is captured by blue I do not want them spawning next time the mission starts (I will be running this mission with persistence). When the mission starts the units I require get spawned in the town (I am using the "inBuiltup" parameter set to 15 and it is working really nicely by-the-way). All good. Convoy example - I have an airfield which is set to red within the mission editor, it also has cloned red units which are activated onto the airfield at mission start (onStart=true). I then have a nearby convoy that uses the "ownedBy#" flag as well and the new "convoyTriggerMethod" set to =1. At mission start the convoy is not triggered. I am assuming that it is not detecting the value of the flag already set and is only looking for change? If I change the airfield to neutral in the editor, the occupying cloned red forces change the ownership to red and the convoy starts as expected (with helicopter escort which is another nice feature). If I am correct this shows a slight difference in the "at mission start" logic. If this is what it has to be, no problem, it still works this way but I thought I would highlight this in case it was not what you intended and/or point it out for other builders. As always, many many thanks for all the hard work and regular updates and new features you add to this excellent toolbox. Cheers Friar