Jump to content
Bohemia Interactive Forums

Grezvany13

Member
 View Profile  See their activity

  • Content Count

    99

  • Joined

  • Last visited

  • Medals

Everything posted by Grezvany13

  1. Grezvany13
    I did some testing, although my SQF version of the script doesn't work as expected, and I'm not familiar enough with SQS to debug that. However I did found the reason for your error (which in English is "Error behaviour : type array, object expected"). To solve this, all you have to do is change the first line to: _unit = _this;
  2. Grezvany13
    Well, there are a couple of things you can do for us to help you: 1) share the code which you currently have (especially the SQS file in question), either directly in a post or a link to the source code 2) post the error(s) which you currently get And since ArmA3 is optimized for SQF instead of SQS and it's way easier to debug and maintain, rewriting the script to SQF will make your life much easier.
  3. Grezvany13
    Extended Event Handlers are the easiest way to do what you ask; although this does require CBA! class Extended_Init_EventHandlers { class CAManBase { class Custom_Init_For_CAManBase { init = " [_this] exec 'script.sqs'"; }; }; }; In your 'script.sqs' you'll find the object as "_this select 0". Please note that, depending on what you do in the script, you might need to do some other stuff to get for example the player or AI instead of the object itself.
  4. Grezvany13
    I don't know the source code of the Exile mod or of your mod, however an educated guess is that Exile is "removing" all default weapons (including your grenade) before it "adds" it's own weapons to the game. Of course this could also just apply to a single class which you happen to inherit, or a variable which doesn't meet the requirements of Exile. Do you get any errors/messages in your RPT files regarding this issue?
  5. Grezvany13
    Something to share: My editor of choice is Atom in combination with the ArmA Language package (developed and maintained by the ACE3 team) for syntax highlighting. Unfortunately it doesn't have any syntax validator to prevent hours of debugging to find a missing quote or semicolon, but I can live with that. Something I would like to see: When I started with making missions there were (and still are) a lot of templates/frameworks/blueprints available to start working from, which allowed me to quickly build what I wanted without spending days at the Biki to learn everything needed. Within no-time I was able to build exactly the same from scratch, but without the overhead. However this doesn't exist for mods/addons... The only way to get started is by digging into the Biki and going through the source code of other mods/addons without any (inline) documentation. It would be nice to have a single package with a "working" mod which contains all the basic configs and script (possibly) required to build a mod, and of course fully documented. I a (read: my) ideal world this would mean that each addon would contain a topic which is included; eg. "CfgFunctions", "CfgVehicles", "UI/dialogs", "Modules", etc. Just my two cents :)
  6. Grezvany13

    Pack scripts into Mod

    Grezvany13 replied to MikeBagdala's topic in ARMA 3 - ADDONS - CONFIGS & SCRIPTING

    The biggest problem with event handlers is the fact that it's too specific on when they are executed, while your question is too global to give a perfect answer. And for some reason there are no (scripted) events available which trigger on mission load and/or player spawn (like init.sqf and initPlayerLocal.sqf in a mission). However there is way!!!! add this to your config.cpp in the addon (addon.pbo) class CfgFunctions { class myTag { class myCategory { // call the function upon mission start, after objects are initialized. class postInit { postInit = 1; file = 'functions/postInit.sqf'; }; }; }; }; functions/postInit.sqf // execute all scripts to non-player objects // make sure the player is in-game and available waitUntil {!isNull player}; // execute any scripts you want to the player Of course you can extend this to anything you want, although it really depends on WHAT and WHEN. sources: - https://community.bistudio.com/wiki/Functions_Library_(Arma_3)#Attributes - https://community.bistudio.com/wiki/Initialization_Order - https://community.bistudio.com/wiki/player (see comments)
  7. Grezvany13

    Achilles

    Grezvany13 replied to oOKexOo's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    I doubt that that is caused by AresAchilles. It's probably because of a version mismatch (either ArmA or mods). Better check the RTP files and try the regular help forums to solve the issue.
  8. Grezvany13

    Achilles

    Grezvany13 replied to oOKexOo's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    In short you could add the following script (either in custom mod or mission); [ "VCOM", "Disable AI", { _unit = _this select 1; _unit setVariable ["NOAI",1,false]; _unit setVariable ["VCOM_NOPATHING_Unit",1,false]; } ] call Ares_fnc_RegisterCustomModule; This would then be available as a Zeus module under 'VCOM' -> 'Disable AI'. Please note that it requires a bit more code to make sure it works 100% (eg. check if you really selected an AI unit), but the sample should already do "something" (except for giving errors).
  9. Grezvany13

    broken script

    Grezvany13 replied to siclesleon's topic in ARMA 3 - MISSION EDITING & SCRIPTING

    Well, all your waypoints use the first marker (just a different radius). I"m sure something like this will work better: _markers = ["mkr","mkr_1","mkr_2","mkr_3","mkr_4","mkr_5","mkr_6","mkr_7","mkr_8","mkr_9","mkr_10","mkr_11","mkr_12","mkr_13","mkr_12"]; _mrk1 = _markers call BIS_fnc_selectRandom; wp = (_this select 0) addWaypoint [(getMarkerPos _mrk1),0] setWaypointType "move"; _mrk2 = _markers call BIS_fnc_selectRandom; wp =(_this select 0) addWaypoint [(getMarkerPos _mrk2),10] setWaypointType "move"; _mrk3 = _markers call BIS_fnc_selectRandom; wp =(_this select 0) addWaypoint [(getMarkerPos _mrk3),20] setWaypointType "move"; _mrk4 = _markers call BIS_fnc_selectRandom; wp =(_this select 0) addWaypoint [(getMarkerPos _mrk4),30] setWaypointType "move"; _mrk5 = _markers call BIS_fnc_selectRandom; wp =(_this select 0) addWaypoint [(getMarkerPos _mrk5),40] setWaypointType "cycle"; Or if you want go fancy: fnc_randomPatrol = { _group = _x select 0; _markers = _x select 1; _waypoints = _x select 2; for "_i" from 1 to _waypoints do { _mrk = _markers call BIS_fnc_selectRandom; if (_i == _waypoints) then { wp = _group addWaypoint [(getMarkerPos _mrk), (_i * 10)] setWaypointType "cycle"; } else { wp = _group addWaypoint [(getMarkerPos _mrk), (_i * 10)] setWaypointType "move"; } }; }; _markers = ["mkr","mkr_1","mkr_2","mkr_3","mkr_4","mkr_5","mkr_6","mkr_7","mkr_8","mkr_9","mkr_10","mkr_11","mkr_12","mkr_13","mkr_12"]; [(_this select 0), _markers, 5] call fnc_randomPatrol;
  10. Grezvany13
    The following script will allow you to check the CfgAmmo entry for 'laserLock' _ammoClassName = "Bo_GBU12_LGB"; _laserLock = [(configFile >> "CfgAmmo" >> _ammoClassName), "laserLock", 0] call BIS_fnc_returnConfigEntry; _laserLock now returns 1 is yes, and 0 if not (even when the laserLock variable is not set).
  11. Grezvany13

    Default Zeus missions will not load all addons at same time

    Grezvany13 replied to jackralph96@gmail.com's topic in ARMA 3 - ZEUS EDITING

    I doubt any of the mods is causing it, except for one: Ares. Instead of Ares I suggest you use Ares Mod - Achilles Expansion, which is a replacement for Ares and adds a lot of new features (and fixes some issues). Give it a try and check if this solves the issue. If not, then you might need to enable/disable all mods to see which one causes the problems.
  12. Grezvany13
    1. Yes, but requires some code to make it work, and I'm not sure if it will work for what you need it for. A solution is to check if the Zeus interface is opened (and closed) using the UI event handlers: class RscDisplayCurator { onLoad = "[_this select 0] call some_onload_function;"; onUnload = "[_this select 0] call some_onunload_function;"; }; These functions should then set a (global) variable which then (by a third function) can be returned. 2. If I'm correct the "best" which can be done is only showing the units from the same side as Zeus (so BLUFOR Zeus can't see OPFOR units on map, unless spotted by friendlies). As for being able to edit the "uneditable" units via the map, this seems like a bug. But I should test this before I can confirm (not that it's required ;) ).
  13. Grezvany13

    Achilles

    Grezvany13 replied to oOKexOo's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    As a result to your current poll (regarding map textures for Zeus), it is possible to switch from satalite to contour by default! Simply press CTRL + T while having the 2D map opened (just like in the Eden editor). So this is a feature which doesn't need to be included ;)
  14. Grezvany13

    Achilles

    Grezvany13 replied to oOKexOo's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    I think this would be a great addition, especially if it's dynamic enough to use it on "everything" (read: all Zeus object/units) and has the option to add custom scripts. 1) select the module 2) place module on object (unit/vehicle/item/etc.) 3) show GUI with settings (parameters of addAction function) - title : text which will be shown to the player in the addAction menu - action * : selectbox with predefined actions (eg. 'Complete Task', 'Add Intel', 'Switch On/Off', etc.) and an option for custom script - script : textbox to add custom script - arguments : arguments which can be used within the script (not sure if needed though) - priority : a selectbox with FIRST (first item in list), NORMAL (somewhere in the middle) and LAST (always at the bottom of the list) - showWindow : selectbox/checkbox with TRUE (default) and FALSE, will show the action in the middle of the screen - hideOnUse : selectbox with TRUE (default) and FALSE, will "disable" the action when currently used - trigger * : selectbox with condition which needs to be met before the action is available (eg. 'Is alive', 'Is dead', etc.) and an option for custom script - condition : textbox to add custom script - radius : maximum distance between player and object to see the action - repeat * : selectbox/checkbox with TRUE and FALSE, on false it will remove the action after completion * = custom settings which will prefill the parameters of the AddAction function Of course the amount and types of predefined actions and conditions can (and should) be extended as much as possible, as long as they are stable and reuseable.
  15. Grezvany13

    Achilles

    Grezvany13 replied to oOKexOo's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    Here's an example of how it will look when implemented in AresAchilles, and only took about 20 new lines of code. As you can see the default modules don't have an icon (since BI didn't include the dlc variable), and both the Ares and Achilles modules have their own icons.
  16. Grezvany13

    Achilles

    Grezvany13 replied to oOKexOo's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    With the CBA Settings API it's rather easy to create options and will just require some if-else statements in the code to execute the correct variation. As for the DLC icons; this isn't supported by by A3 for modules, and does require manual generation of the module tree. But I think that no one will object if the modules have both the Achilles icon and an informative icon at the same time. True; for some reason modules only work with sub-categories and the category variable is skipped completely. Although if you manually generate the module tree it is possible to have more depth (depending on the code). The code I currently have does work but still has some issues (eg. only supports known mods/modules, sometimes duplicate categories/subcategories, etc.). However, in combination with the DLC icons, it works like a charm ;) Additionally to this I'm working on an implementation to register custom modules and/or add support to 3rd party mods without having them required in the mod. I completely agree on this. That's why I didn't want to build a new mod just to extend existing ones (which is a pain to do properly).
  17. Grezvany13

    Achilles

    Grezvany13 replied to oOKexOo's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    Why don't you have informative icons on the left side (just as vanilla modules) and use a DLC icon on the right side (just like with DLC/mod units)? This way users can easily identify from which mod the module is coming from. It does require a modified version of the old Ares method of adding modules to Zeus (by a script instead of simply using 'addCuratorAddons'), unless BIS adds this feature themselves. To make this work: 1) Create a CfgMod entry for the mod (in addition to mod.cpp) 2) Add the 'logoSmall' variable to the CfgMod entry 3) Add the 'dlc' variable to the module class(es) 4) Use 'tvSetPictureRight' to add the icon to the right side of the list item I currently have a working version for this in a mod which I'm working, among some other things which I feel missing in Zeus and AresAchilles; like configurable vision modes, subcategories for modules(!), show/hide Zeus watermark, etc. I'll be happy to try to integrate this into AresAchilles (through a fork and PR's) or to let you use parts of the code (since I will release the code as open source), although I'm currently not able to work on it actively. But let me know if you're interested!
  18. Grezvany13
    Well, I'm sure you could see the reason when you checked the RPT file since it's rather obvious ;) The following 3 lines are broken: _unit addmagazine "11Rnd_45ACP_Mag; _unit addmagazine "11Rnd_45ACP_Mag; _unit addmagazine "11Rnd_45ACP_Mag; They all miss the ending quotes, which causes a coding error.
  19. Grezvany13
    You'll get the best performance boost when you don't run the code at all ;) Currently you run the loop as long as a player is alive, although I think you can add more variables (eg. "isWounded", "hadTreatment", etc.) and break down the loop in separate parts. But in comparison, ACE3 Medical has way more scripts and checks running within a single loop, and I never found it a bottleneck (performance wise).
  20. Grezvany13
    ArmA3 has a system for this for the FIA units, and is described in the Biki: https://community.bistudio.com/wiki/Arma_3_Characters_And_Gear_Encoding_Guide#FIA_headgear_and_facewear_randomization It does mean you might need to create custom functions for other items than headgear/facewear, but it's a lot easier than running (heavy) scripts.
  21. Grezvany13
    I think it will be a bigger issue if you are working on the contents of your gear (like a backpack), switch it (because it's too small), and suddenly all the contents are replaced by default stuff. Especially because there's no way to see the contents before selecting an item. Even on the Biki it states that prefilled gear (like backpacks) shouldn't show up in Eden, Zeus or the Arsenal (scope = 1;) https://community.bistudio.com/wiki/Arma_3_Characters_And_Gear_Encoding_Guide#Backpack_configuration So in my opinion it's not a bug, it's a wrongly configured item.
  22. Grezvany13
    I'm not entirely sure, since I never done this myself, but based on my knowledge of Arsenal it seems that the following this happening: - Player has a prefilled backpack on spawn (items are there through the config) - Player opens arsenal, which checks which backpack and items which the player carries - Player takes another (empty!) backpack, and Arsenal prefills it with the items from the "old" backpack - Player takes the (prefilled) backback, and Arsenal will take the filled backpack and ADDS the content from the "old" backpack Result; duplicate items. The best way to solve this is by creating an empty backpack for Arsenal (if it's custom), and have a separate config for the prefilled one (not available in Arsenal) which will be used on spawn of the unit.
  23. Grezvany13
    The error is simple: "Error list: Type Script, expected Object", so the function 'list' requires an Object but get's a script instead. So the issue is before these files, and caused by the script(s) which are calling them. Since 'list' works with trigger objects, it's probably something where the trigger doesn't exists or a wrong value is returned elsewhere. To answer your question; there's nothing wrong with these scripts (regarding the error), and the error is caused elsewhere.
  24. Grezvany13
    I just some testing myself: 1) I created a new mission (F3 Mission Framework) 2) I moved the contents of description.ext (of mission, which worked without modifications) into description.h (in addon, from which I know it works) 3) I tried to run the mission The result was that my game crashed, however this was because it couldn't do an include which was set in the describtion.h file (tried to include a script present in the mission). This means that it is possible to include .h files from an addon into a mission, including configs. It was on my local machine (and not a dedicated server), although based on my knowledge this shouldn't be an issue when both the mission file and mod/addon are present on the server and loaded correctly. And if you take a look into \a3\missions_f_epa\Campaign\Missions\A_m01.Stratis\description.ext (the one you tried to include), it even contains includes to other mission settings within the PBO ;) So even A3 is doing it. I still think it's a issue within the addon. FYI; For my mod I use the Addon Builder to create the PBO's, which is part of the ArmA 3 Tools (available through Steam), but due some issues with it I do use some custom settings to make it work properly. This includes manually setting the AddonPrefix, since it fails to read the $PBOPREFIX$ file. BTW: you said it does work locally, but not on the dedicated server. Perhaps something very stupid, but did you load your addon at the server (with the -mod=@addon parameter) and performed a full restart?
  25. Grezvany13
    Thanks for the extra info, that really helps. The $PREFIX$ file can only be used within mission PBO's, while addons use $PBOPREFIX$. So as I expected this is the issue why it can't be found ;) I'm not 100% about this, but to be sure I would also do the following to make sure the mod gets loaded correctly: - Create a mod.cpp file in the root of the mod (so \@ndClient\mod.cpp) - Add the CfgMod {} class to the config.cpp within your (main) addon See https://community.bistudio.com/wiki/Mod.cpp/bin_File_Formatfor more information about this. And as a bonus: you also might take a look at the paths of the audio files in description.h ;) 1) As far as I can see the mod won't be loaded correctly, because it's not identified as such. To fix this you'll need to add 2 things: 1a) Create a mod.cpp file in the root of the mod (so \@ndClient\mod.cpp) 1b) Add the CfgMod {} class to the config.cpp within your (main) addon See https://community.bistudio.com/wiki/Mod.cpp/bin_File_Formatfor more information about this.
×