antonstruyk

Not sure why this is happening. Opened https://github.com/astruyk/Ares/issues/209to investigate

This is already a feature (as of V.1.8.0) - the parameters passed to the code in the exec code modules is the same as the parameters passed to the custom modules (that is, parameter 0 is the location in the world where the module was dropped, parameter 1 is the unit (if any) that the module was dropped on).

There have been legitimate concerns from admins regarding keys that span multiple versions. I admin a server myself, and I get that it's nice to GUARANTEE that people are on the same version. It's easy for me to know exactly what changes go into each release (I write the damn thing) but it's an undue burden to place on every other admin out there (plus, I'm not always 100% able to keep myself from allowing features to creep into point releases). New versions will have the 'one .bikey per release' policy that I've had in the past. Thank you for participating in the experiment :D

I don't really plan on doing anything Eden related until it gets further along.

Oh, yeah, I should have mentioned in the release notes: For bugfix releases (1.8.X) I'm going to switch to using the same key as the initial release since it reduces the amount of key juggling that admins have to do. For versions with new features (1.X) it'll be different keys. The key naming will be updated in future versions to reflect this (i.e. 'Ares_1_9.bikey' or 'Ares_1_9_X.bikey' or something). If people have concerns with this let me know I can continue to do one-key-per-release. The thinking is that this way admins only have to update the server if there is an actual feature release so people can take advantage of bugfixes on servers that support their feature release (e.g. 1.8.*) immediately. (Also - it's annoying to have to generate the keys all the time :) )

They simply use https://community.bistudio.com/wiki/enableSimulationGlobalto enable/disable simluation for the object that they are dropped on. Can be used to turn off physics for objects you place in the world. Was requested in https://github.com/astruyk/Ares/issues/201

New (minor) version released! V.1.8.1 * Fix some broken inheritance for vests and hats that might have been interfering with other equipment mods * Fix an issue where bad SQF was being generated by the for Guerilla and Civilian units when saving. * Add enable/disable simulation modules.

For those of you having issues pasting code you've copied out of the 'Generate mission SQF' module - two things: 1) There is an issue with AAF units currently - https://github.com/astruyk/Ares/issues/200- You can fix the generated script by replacing the instances of 'GUER' with 'independent'. 2) If you don't have AAF units or continue to have issues, can you put the generated SQF in pastebin (or something similar) and link it here so we can see what's wrong with it?

In coop you'd want either server or local (probably server would be best if you're not doing anything fancy with AI locally). Running it on all machines would have every client execute the code, which would make a copy of each unit/object for each person connected - probably not what you want.

I used to have a proprietary format that allowed for this, but that was deprecated in 1.7.0 and removed in 1.8.0 (see this ticket here: https://github.com/astruyk/Ares/issues/188 ) because it was a pain to maintain and debug. It was especially difficulty to add new features (like waypoints and marker support). Adding this in a generic way to the SQF code isn't really feasible (the generated code would be just as complex as the old system) and so it isn't in the plan ATM. That said, if you have more compositions that you would like to see in Ares I'd love to add more community made stuff. Follow the instructions here to submit your own compositions for inclusion: https://github.com/astruyk/Ares/wiki/Contributing-To-Ares#submitting-compositions

MCC saves its output in '.SQM' format - which is the same as the mission files, but is a lot more complicated and pretty much unwritable and unreadable by normal humans. Ares saves its data in '.SQF' format, which is the generic scripting language meant to be written and read by humans. It's treated just the same as any other script - meaning you can execute it like any script code (dump in in init.sqf, throw it in a function, or use the Ares 'Run Script' modules to execute it on-the-fly). Unfortunately, since it's a different format you can't just drop it into the mission.sqm file like the MCC-generated code and expect the objects to show up in the 2D editor - in fact the game gets upset if you do this with SQF code and probably crashes. The tradeoff is that you can actually debug the generated script fairly easily, and since you can rebuild using Ares on the fly (by pasting and running the code with a module) you can edit them as if Zeus was a 3-d editor that way. If you want the objects to show up in a mission without you having to do anything (assuming you have access to the mission itself) you can: 1) create a .sqf file in the mission folder (say, 'setupMyObjects.sqf') 2) Dump all of the Ares-Generated script into the 'setupMyObjects.sqf' file and save it 3) Create an init.sqf file (or, open an existing one) 4) Insert the following into the init.sqf: if (isServer) then { [] execVM "setupMyObjects.sqf"; }; When you run the mission the server (which is either your machine in SP or locally hosted multiplayer, or the dedicated server) will run the script and create the objects on startup automatically. They will not show up in the 2D editor though. This means you cannot have zeus-placed units interact with 2d-editor placed events or triggers - an unfortunate downside. The reason this functionality is available at all is so that you can do all of the unit placement and setup for various scenarios offline and then easily integrate it into a mission on the fly or convert it into a script that can be saved and executed dynamically later (for example, I use this in a mission to randomly add objects and patrols I've created in Zeus simply by randomly selecting the SQF files to execute at runtime). If you're looking for something simply to pull objects out into the 2d editor, there are other solutions for that. MCC is one of them, and I believe there are some more focused 3d editor mods as well. They have their own downsides in that most of them generate code that can't be added to an existing mission on-the-fly. Since Ares is aimed at ZEUS functionality, which is all about adapting to players, being able to add these pre-setup mission features and placements on-the-fly is (IMO) a priority over exporting in a 2-D editor compatible format.

Paste the generated code on pastebin or something similar and link it here. Maybe there's something wrong with the generated SQL. You should just be able to paste it into the 'execute code' module (or an init.sqf file as you mentioned) to have it execute and build the mission again. Keep in mind it DOESN'T add the created objects to Zeus automatically so if you're just looking at the object list after recreating the level it won't show anything until you add the objects (there's a utility module for it).

This is a module that can be used to generate the class file necessary for a composition that can be placed into the game. It's the module I use to generate all of the compositions in Ares. It's really intended for use by mod authors to prevent having to write the composition code by hand... What it does is generate the text required for the class and dumps it to the ARMA log file (the RPT)... It can then be copied from there into the mod's config file, recompiled, and it will be placeable... This is the thing I used to generate all of the roadblocks, bases, etc that are included in Ares.

I'm not sure I understand what you're trying to do that isn't working. Can you please clarify the steps you're following, the expected outcome, and the actual outcome? ---------- Post added at 14:22 ---------- Previous post was at 14:17 ---------- Regarding all the HC stuff - there's another discussion regarding some work that has been done: https://github.com/astruyk/Ares/issues/159 ... Currently there are no plans to directly integrate third party HC scripts into Ares. If someone wants to write a custom module to interact with a third-party script and create an issue with the desired code (or submit a pull request for the new script in the 'extras' folder in the depot) I don't have any problem including it that way. Unfortunately, our squad doesn't use a HC so it's not high on my personal hit list.

Right now only the Artillery Fire Mission module depends on CBA.