Jump to content

Search the Community

Showing results for tags 'feature request'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • BOHEMIA INTERACTIVE
    • BOHEMIA INTERACTIVE - NEWS
    • BOHEMIA INTERACTIVE - JOBS
    • BOHEMIA INTERACTIVE - GENERAL
  • FEATURED GAMES
    • Vigor
    • DAYZ
    • ARMA 3
    • ARMA 2
    • YLANDS
  • MOBILE GAMES
    • ARMA MOBILE OPS
    • MINIDAYZ
    • ARMA TACTICS
    • ARMA 2 FIRING RANGE
  • BI MILITARY GAMES FORUMS
  • BOHEMIA INCUBATOR
    • PROJECT LUCIE
  • OTHER BOHEMIA GAMES
    • ARGO
    • TAKE ON MARS
    • TAKE ON HELICOPTERS
    • CARRIER COMMAND: GAEA MISSION
    • ARMA: ARMED ASSAULT / COMBAT OPERATIONS
    • ARMA: COLD WAR ASSAULT / OPERATION FLASHPOINT
    • IRON FRONT: LIBERATION 1944
    • BACK CATALOGUE
  • OFFTOPIC
    • OFFTOPIC
  • ArmA Toolmakers's Releases
  • ArmA Toolmakers's General
  • Die Hard OFP Lovers' Club's Topics
  • Japan in Arma's Topics
  • Arma 3 Photography Club's Discussions
  • The Order Of the Wolfs- Unit's Topics
  • 4th Infantry Brigade's Recruitment
  • 11th Marine Expeditionary Unit OFFICIAL | 11th MEU(SOC)'s 11th MEU(SOC) Recruitment Status - OPEN
  • Legion latina semper fi's New Server Legion latina next wick
  • Legion latina semper fi's https://www.facebook.com/groups/legionlatinasemperfidelis/
  • Legion latina semper fi's Server VPN LEGION LATINA SEMPER FI
  • Team Nederland's Welkom bij ons club
  • Team Nederland's Facebook
  • [H.S.O.] Hellenic Special Operations's Infos

XBOX Live


PlayStation PSN


Origin


PlayFire


SoundCloud


Pinterest


Reddit


Twitch.Tv


Ustream.Tv


Duxter


Instagram


Location


Interests


Interests


Occupation

Found 4 results

  1. UI Fix in editor

    Please, PLEASE for the love of god, consider ordering the editor's FILE dropdown menu in the following manner: New Open Save As Save Thus saving everyone the grief of accidentally clicking "save" and overwriting anything by accident, instead getting a prompt. Thank you.
  2. Hello everybody After the news about the Jet DLC, i couldnt help but wonder why something has never been done about amphibious/littoral operations, namely something around the concept of a Marines DLC. More than a third of all vanilla maps are made of water, but in turn the only seafaring vehicles available are the RHIBs, the minigun boat and the submarine thingie. Way too little, considering all the operations that can be conducted from the sea. Burnes had started to make some landing craft utility boats, namely the LCAC and the Mk10, but due to a hardware meltdown everything was lost and the project has been halted since. But i feel there should be more in terms of amphibious operation vehicles -moreso than jets, BTW, but as far as i am concerned thats gonna be a badly needed Sensors DLC with some planes thrown in as a bonus. In particular, there should be for both west and east sides, something on the category of a LHD (more on that later), LCU, AAV and LCAC or heavy cargo lander. About the issues pertaining such a large ship as a LHD, there are some unexplored problems: there hasnt been such a big vehicle yet, so there is no reference about it's physics, hitpoints, vulnerabilities, how it should be damaged and eventually break and sink, etc; there is an engine issue about moving objects with people standing on them which wont stuck on the surface of said object but will slip away (or rather they stay still while the vehicle moves away), and this is a problem that also Burnes met when working on his landing crafts of his; and if our maps are waaaaaay too little for jet operations the very same thing can be said about naval operations (once you create a LHD for both sides it stands to reason that then youll place them both in a map and try to have the both of them throw things at each other). But if the first two are engine's problems, the third one is rather easy to solve: the space outside the map of Tanoa and Altis is still seawater, so you can go off the map as much as you want to. But then again, i dont plan to solve all the problems: i dont have the skills to address these issues. And the smaller vehicles are useful for storming beaches and badly in need to put all this water to some use. I only wanted to raise awareness on this issue and gather (or maybe just test) the interest of the community. So, what say you?
  3. sync <code> SQF makes it very easy to achieve asynchrony, while at the same time offering no means of synchronization. Some people seem to think that race conditions aren't a thing in SQF. This is of course wrong, as the scheduler is free to pause execution almost anywhere. A simple example: if (player hasWeapon _someWeapon) then { player removeWeapon _someWeapon; player addWeapon _someOtherWeapon; }; Here it is entirely possible (though admittedly unlikely) for the scheduler to pause between the condition and the effect, and consequently for the player to drop the weapon, keeping it, while also receiving the new one. I have personally witnessed a similar situation occurring in a real game under very heavy lag. Using certain hacky solutions it is possible to get around these issues. Relating to the previous example, it is for example possible to create an atomic function which at the same time attempts to remove the weapon, and returns a boolean indicating whether it was. It is also of course possible to create simple mutexes and consequently spinlocks. Neither solution is very pretty however. As such i suggest the following, very simple, script command: sync { /* some critical section */ } This command should execute the right hand argument synchronously, without the possibility of interruption by the scheduler. Use of any scheduler-only commands such as sleep and waitUntil should generate errors, just as they do in the unscheduled environment. If used in the unscheduled environment the command would have no special effect of course, behaving instead similarly to call. [<string>,...] preprocessFileLineNumbers <string> Many mod developers make clever use of macros for conditional compilation, for instance in order to enable or disable debugging features such as logging, argument validation, call stack tracing, et cetera. This is often done using macro constants defined either in each code file, or in a central header file. Unfortunately it doesn't seem to be possible to include files from the mission in an addon, as it is vice versa. This means in order to enable or disable the aforementioned features, one has to rebuild the mod, or a part of it while defining different macro constants. To ease this, and undoubtedly many other tasks, i suggest the extension of the preprocessFileLineNumbers command with a variant accepting, as the left hand argument, an array of strings representing macro constants to be defined during preprocessing. For example: ["MY_MACRO", "DO_THE_DEBUG"] preprocessFileLineNumbers "myScript.sqf" Would be equivalent to defining these macros at the top of the myScript.sqf file, like so: #define MY_MACRO #define DO_THE_DEBUG // ... compileFinal <code> We can all agree that the compileFinal command, as well as the underlying concept, are great additions to SQF. However they seem to necessitate placing each function, no matter how small, into its own code file. I would often prefer to place related functions, such as class member functions, next to each other in the same code file. For instance: //map.sqf my_fnc_map_add = { // add key value pair to the map }; my_fnc_map_get = { // retrieve value from the map using the specified key }; my_fnc_map_remove = { // remove the specified key from the map }; my_fnc_map_hasKey = { // determine whether the map contains the specified key }; Now all of these functions end up being non-final, and editable. For a dirty workaround something like this might be used: my_fnc = compileFinal str {...} However extending the compileFinal command with a variant accepting code as the right hand argument seems like it would be very simple to implement. serializeObject <object> / deserializeObject [...] Persistence across sessions is nothing new. Implementing it however ranges from arduous to downright impossible (at least without hacking memory via extensions), depending on the desired fidelity. Correctly saving and loading the attachments on a weapon inside a backpack inside a vehicle for instance isn't exactly simple. What i'm suggesting is two new simple commands to streamline this process. The proposed serializeObject command, given a right hand argument of type object, might return an array containing enough information to recreate the object with high precision. Properties such as type, position, orientation, velocity, damage to each part, and the entire inventory tree should be included. The counterpart, deserializeObject, could then be used to bring this array representation back to life. This would simplify immensely the task of persistence seen in many missions and mods, as well as offer a performance boost by moving a significant portion of SQF code over to a native implementation. Please share your thoughts, or any other suggestions you might have. If any (or all) of these have been suggested before, i apologize.
  4. I'm using zeus a lot. But everytime im on my server & open zeus I need to use ARES to add all players to zeus so I can follow them. Can't there be a module for like adding all pre-placed objects into the zeus interface? Would love this feature
×