Zenophon's ArmA 3 Co-op Mission Making Framework
* Credits go to CallMeSarge for this great logo
Introduction
Ladies and gentlemen, Armaholics of all ages, I am proud to present a work over a year in the making: Zenophon's ArmA 3 Co-op Mission Framework. My framework is a library of 252 SQF functions and 87 macros organized into a carefully designed API that is both easy to use and extremely powerful. The functions cover everything from manipulating arrays to an extensive task system. Each one has been meticulously designed and tested to provide useful features with minimal bugs and issues. The framework is designed so that each function is a logical building block that achieves a straightforward effect. The strength of the framework is that each small part fits together neatly with others, allowing you to quickly implement your mission design intuitively.
The framework works with any map and requires no addons. It is compatible with any mod because you choose which functions execute. There is effectively no performance impact to compile the entire framework, and every function has been diligently optimized. All 206 public functions are also carefully documented in an exacting style, and many resources are provided to help you learn to use the framework. The framework is created with these goals in mind: Simple co-op fun for both players and mission makers Bottom-up design using flexible pieces that you control Truly random and dynamic missions without extra work for mission designers Procedural mission design instead of manual placement using the editor Eliminating large, static functions with assumptions about what you want in your mission Server-oriented execution to create more efficient multiplayer missions A simplification of locality and interacting with clients in multiplayer A solid, powerful, and bug-free library to use as a foundation for your own code The framework's many functions are divided into 14 categories with a specific purpose: The Data functions are the foundation of the framework, supporting both simple and complex operations on arrays and strings. The Dialog System allows dynamic creation and display of GUI's using only function calls. The Fire Support system is a tool for mission makers, not players, to create any imaginable artillery, mortar, or airstrike. The Loadout functions, including a full custom loadout system, provide every option you need to easily equip both players and AI. The Math functions are auxiliary functions that deal with various 2D trigonometric operations on positions and polygons. The Misc functions are just that, miscellaneous. They don't fit in anywhere else, but are still useful. The Object functions deal with objects, and provide numerous ways to check on and interact with players, AI, and static objects. The Objective system is designed to make side missions extremely simple for mission makers with just one line of code. The Orders functions provide a tested and working way to make AI do things, and some offer simple but powerful randomization. The Position functions generate and check random positions, allowing infinite randomization within your control. The Preprocessor library offers both general and framework-specific macros that improve ease of use for many small tasks. The Spawning functions allow you to spawn any object, AI or static, that you need and offer both straightforward and randomized spawning. The Task system is a self-contained system meant to separate the mission maker completely from the issues of tasks, making any task operations simple. The Trigger functions perform operations on tasks based on preset conditions and are designed to complement the Task system. Download
Google Drive: (Go to file>download, or ctrl+s)
(.7z file) https://drive.google.com/file/d/0B-QFvxyAVKTUd0I4bFpPZTFLVTQ/edit?usp=sharing
(.zip file) https://drive.google.com/file/d/0B-QFvxyAVKTUS3dDcXdURG96bFE/edit?usp=sharing
Contact the author:
ZenophonArmAFramework@gmail.com
Changelog
Documentation
The included documentation explains how to use each part of this large framework in order to create missions. The documentation set features complete, standardized documentation organized by the categories for all of the framework's public functions. Further standard documentation, such as a changelog, FAQ, etc., are provided.
There is a series of 20 beginner tutorials to help first-time mission makers create simple missions using framework functions. For more experienced scripters, there are 15 intermediate demonstration missions and 8 full sample missions to show more advanced scripting techniques and more framework functions. Other helpful resources, including a Notepad++ SQF language, are provided.
Multiplayer and JIP
The framework was designed with the idea that the server should manage everything that it can, and few to no scripts should be run on the clients. Framework functions are designed to work in a multiplayer environment (dedicated servers too, of course) without the mission designer even considering how or why. Regardless if a mission is singleplayer or multiplayer, the framework's functions will do what they say they will without you changing anything.
The framework (or any function) cannot intrinsically deal with JIP and support it without any changes to your mission. Because you cannot reasonably be expected to divine what you need to do to make your usage of the framework JIP compatible, there is a JIP demonstration mission for you. Using the template there in your own mission, with a some customization, will make your mission JIP compatible.
Bugs
There will be bugs; this is not a final release, nor will it ever be. I have made every effort to test and debug all 194 public functions, and that that documentation agrees with the actual code. Bugs are not your fault; they come from some mistake within a framework function. It is not possible to produce bug-free software of this magnitude without mass public testing. This holds true whether or not the framework is still in beta. The development cycle of adding, improving, and fixing things goes on forever.
I assure you that I have every intention of fully supporting the framework for a long time. Fixing bugs and issues will always be my first priority over adding new features or tweaking things.
Feedback
I am not so arrogant as to think that I have considered everything, have a perfect design and implementation, and have judged the needs of ArmA mission makers fairly. I highly encourage you to submit any suggestion that occurs to you, even if you are not sure about it.
For simple feedback like 'I liked it' or 'I hated it', or if you have something important to say, this thread, PM, or email is fine. Concerning bugs, please post, PM, or email me a report (others will thank you for improving the framework) with every possible detail.
Concerning issues with understanding and using framework functions, please make use of every resource you have available to you. If you have a technical question about a more obscure function, feel free to look at the source code and experiment with it. If you really cannot figure something out, PM or email me with the information needed to help you.
Your issues, bugs, and feedback are important to me. This framework is important to me, and I am not going to 'get bored' or 'have real life issues' a month after release, leaving you with bugs. I have invested a lot of time into this framework, and I will continue to do so.
Editor Limitations
The framework can be the only resource used to create your mission, or you may use it in conjunction with the editor and your own scripts. However, you cannot use any framework function in an object's init field, a trigger's condition, etc, in the editor. You can still use framework functions in places in the editor that do not execute instantly upon mission start, such as a trigger's activation field.
I have no plans to change this; it seems like a significant problem, but it is in fact advantageous once you learn how to create and organize your mission using external scripts. Your mission will be better organized and easier to change and debug with all of its code and function calls in a few SQF files. There is nothing that can be done in the editor that cannot be done with scripting. There is a lot that can be done with scripting that cannot be done in the editor.
You might think that the editor is preferable to my complex framework. I can say with 100% confidence that my framework is quicker to use, more reusable, easier to test and debug, more effective, and more powerful than the editor. You will achieve better missions more quickly once you learn to use the framework.
What the Framework is Not
First, the framework is not a magic black box that generates lots of features for you with a few inputs. This is not a system of mission templates that lets you create a 2-hour combined arms mission in 5 minutes. This is not a random mission generator, it is not a resource for players. It is a tool for mission makers.
Second, the framework does not implement abstract systems. This means things that do not achieve a direct effect in the game world or perform a concrete operation. I will never add a wounding system, weapon resting, team killing protection, points and scoring, respawn, or anything else that is superfluous to the mission itself.
Third, the framework does not control the mission, your implementation does. The framework does not run any functions unless you call something (most functions also call other framework functions). There are no hidden functions observing the mission and guessing what you want next. Almost every action must be done by you manually, and others are optional.
Finally, the framework is not a collection or compilation of various people's work. Everything in the framework is designed and coded by me without using any external libraries and other people's code (except for a few BIS functions for GUI stuff). I must be able to guarantee the quality and functionality of every line of code (nearly 16000 lines) if I claim to be the author of the framework. I have purposefully reinvented the wheel numerous times to allow this framework to provide the best experience possible.
Legal
In addition to the terms of the Legal.txt file (please read), the framework is also released under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0) license.
Conclusion
You might also not be very impressed yet, but I assure you that you will be. I have spent over 2000 hours creating this framework. Believe me when I say that this framework is worth your time.
Credits
MimirAesir, Tutorials
MooseMan (https://forums.bistudio.com/user/906086-pellelil/), Zen_SpawnFlare
Ladies and gentlemen, Armaholics of all ages, I am proud to present a work over a year in the making: Zenophon's ArmA 3 Co-op Mission Framework. My framework is a library of 252 SQF functions and 87 macros organized into a carefully designed API that is both easy to use and extremely powerful. The functions cover everything from manipulating arrays to an extensive task system. Each one has been meticulously designed and tested to provide useful features with minimal bugs and issues. The framework is designed so that each function is a logical building block that achieves a straightforward effect. The strength of the framework is that each small part fits together neatly with others, allowing you to quickly implement your mission design intuitively.
The framework works with any map and requires no addons. It is compatible with any mod because you choose which functions execute. There is effectively no performance impact to compile the entire framework, and every function has been diligently optimized. All 206 public functions are also carefully documented in an exacting style, and many resources are provided to help you learn to use the framework. The framework is created with these goals in mind: Simple co-op fun for both players and mission makers Bottom-up design using flexible pieces that you control Truly random and dynamic missions without extra work for mission designers Procedural mission design instead of manual placement using the editor Eliminating large, static functions with assumptions about what you want in your mission Server-oriented execution to create more efficient multiplayer missions A simplification of locality and interacting with clients in multiplayer A solid, powerful, and bug-free library to use as a foundation for your own code The framework's many functions are divided into 14 categories with a specific purpose: The Data functions are the foundation of the framework, supporting both simple and complex operations on arrays and strings. The Dialog System allows dynamic creation and display of GUI's using only function calls. The Fire Support system is a tool for mission makers, not players, to create any imaginable artillery, mortar, or airstrike. The Loadout functions, including a full custom loadout system, provide every option you need to easily equip both players and AI. The Math functions are auxiliary functions that deal with various 2D trigonometric operations on positions and polygons. The Misc functions are just that, miscellaneous. They don't fit in anywhere else, but are still useful. The Object functions deal with objects, and provide numerous ways to check on and interact with players, AI, and static objects. The Objective system is designed to make side missions extremely simple for mission makers with just one line of code. The Orders functions provide a tested and working way to make AI do things, and some offer simple but powerful randomization. The Position functions generate and check random positions, allowing infinite randomization within your control. The Preprocessor library offers both general and framework-specific macros that improve ease of use for many small tasks. The Spawning functions allow you to spawn any object, AI or static, that you need and offer both straightforward and randomized spawning. The Task system is a self-contained system meant to separate the mission maker completely from the issues of tasks, making any task operations simple. The Trigger functions perform operations on tasks based on preset conditions and are designed to complement the Task system. Download
Google Drive: (Go to file>download, or ctrl+s)
(.7z file) https://drive.google.com/file/d/0B-QFvxyAVKTUd0I4bFpPZTFLVTQ/edit?usp=sharing
(.zip file) https://drive.google.com/file/d/0B-QFvxyAVKTUS3dDcXdURG96bFE/edit?usp=sharing
Contact the author:
ZenophonArmAFramework@gmail.com
Changelog
Documentation
The included documentation explains how to use each part of this large framework in order to create missions. The documentation set features complete, standardized documentation organized by the categories for all of the framework's public functions. Further standard documentation, such as a changelog, FAQ, etc., are provided.
There is a series of 20 beginner tutorials to help first-time mission makers create simple missions using framework functions. For more experienced scripters, there are 15 intermediate demonstration missions and 8 full sample missions to show more advanced scripting techniques and more framework functions. Other helpful resources, including a Notepad++ SQF language, are provided.
Multiplayer and JIP
The framework was designed with the idea that the server should manage everything that it can, and few to no scripts should be run on the clients. Framework functions are designed to work in a multiplayer environment (dedicated servers too, of course) without the mission designer even considering how or why. Regardless if a mission is singleplayer or multiplayer, the framework's functions will do what they say they will without you changing anything.
The framework (or any function) cannot intrinsically deal with JIP and support it without any changes to your mission. Because you cannot reasonably be expected to divine what you need to do to make your usage of the framework JIP compatible, there is a JIP demonstration mission for you. Using the template there in your own mission, with a some customization, will make your mission JIP compatible.
Bugs
There will be bugs; this is not a final release, nor will it ever be. I have made every effort to test and debug all 194 public functions, and that that documentation agrees with the actual code. Bugs are not your fault; they come from some mistake within a framework function. It is not possible to produce bug-free software of this magnitude without mass public testing. This holds true whether or not the framework is still in beta. The development cycle of adding, improving, and fixing things goes on forever.
I assure you that I have every intention of fully supporting the framework for a long time. Fixing bugs and issues will always be my first priority over adding new features or tweaking things.
Feedback
I am not so arrogant as to think that I have considered everything, have a perfect design and implementation, and have judged the needs of ArmA mission makers fairly. I highly encourage you to submit any suggestion that occurs to you, even if you are not sure about it.
For simple feedback like 'I liked it' or 'I hated it', or if you have something important to say, this thread, PM, or email is fine. Concerning bugs, please post, PM, or email me a report (others will thank you for improving the framework) with every possible detail.
Concerning issues with understanding and using framework functions, please make use of every resource you have available to you. If you have a technical question about a more obscure function, feel free to look at the source code and experiment with it. If you really cannot figure something out, PM or email me with the information needed to help you.
Your issues, bugs, and feedback are important to me. This framework is important to me, and I am not going to 'get bored' or 'have real life issues' a month after release, leaving you with bugs. I have invested a lot of time into this framework, and I will continue to do so.
Editor Limitations
The framework can be the only resource used to create your mission, or you may use it in conjunction with the editor and your own scripts. However, you cannot use any framework function in an object's init field, a trigger's condition, etc, in the editor. You can still use framework functions in places in the editor that do not execute instantly upon mission start, such as a trigger's activation field.
I have no plans to change this; it seems like a significant problem, but it is in fact advantageous once you learn how to create and organize your mission using external scripts. Your mission will be better organized and easier to change and debug with all of its code and function calls in a few SQF files. There is nothing that can be done in the editor that cannot be done with scripting. There is a lot that can be done with scripting that cannot be done in the editor.
You might think that the editor is preferable to my complex framework. I can say with 100% confidence that my framework is quicker to use, more reusable, easier to test and debug, more effective, and more powerful than the editor. You will achieve better missions more quickly once you learn to use the framework.
What the Framework is Not
First, the framework is not a magic black box that generates lots of features for you with a few inputs. This is not a system of mission templates that lets you create a 2-hour combined arms mission in 5 minutes. This is not a random mission generator, it is not a resource for players. It is a tool for mission makers.
Second, the framework does not implement abstract systems. This means things that do not achieve a direct effect in the game world or perform a concrete operation. I will never add a wounding system, weapon resting, team killing protection, points and scoring, respawn, or anything else that is superfluous to the mission itself.
Third, the framework does not control the mission, your implementation does. The framework does not run any functions unless you call something (most functions also call other framework functions). There are no hidden functions observing the mission and guessing what you want next. Almost every action must be done by you manually, and others are optional.
Finally, the framework is not a collection or compilation of various people's work. Everything in the framework is designed and coded by me without using any external libraries and other people's code (except for a few BIS functions for GUI stuff). I must be able to guarantee the quality and functionality of every line of code (nearly 16000 lines) if I claim to be the author of the framework. I have purposefully reinvented the wheel numerous times to allow this framework to provide the best experience possible.
Legal
In addition to the terms of the Legal.txt file (please read), the framework is also released under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0) license.
Conclusion
You might also not be very impressed yet, but I assure you that you will be. I have spent over 2000 hours creating this framework. Believe me when I say that this framework is worth your time.
Credits
MimirAesir, Tutorials
MooseMan (https://forums.bistudio.com/user/906086-pellelil/), Zen_SpawnFlare
-
-
-
- 788 replies
