dreadedentity

What about kinematics?

Variables are deleted without a trace. Anyway, you should not be using scripts to run code, you should be compiling your scripts using the built-in functions library. The only variables you need to worry about are global variables, but I doubt you'd be dynamically creating global variables (also you shouldn't).

You can access the editor by pressing escape and clicking on GUI EDITOR on the buttons along the bottom. Once inside, right click somewhere and select the type of control you want to use and click okay to add it. Some controls are not visible (at least from what I remember, it may have changed now) so you need to shake the mouse around to find them. I recommend changing "Position Type:" to safezone, it's never let me down. NOTE: The GUI Editor does not contain sample controls for all controls possible in the game (Trees comes to mind). This is annoying, but not game-breaking, you can add a placeholder control and change it's inheritance later. After you have created the GUI and styled it the way you want to, press ctrl+s to save it. I recommend first saving your dialog in "GUI Editor" format (this will allow you to go back into the editor and easily load your dialog to make small changes), then save it again as "Config (controls as class)" (this is what the game can actually use). When you have selected your format and click OK, the information is in the clipboard, so you have to alt+tab and paste it. All you need for your dialog is an idd number and a controls class: class MyCustomDialog { idd = some_number; class controls { //paste the gui editor output here }; }; You can either paste this directly in description.ext or put it in a separate file and then #include that file to description.ext. You will need a file with all of the base classes, make sure you #include this before the dialog, or else you will have issues because you can't use a macro that doesn't exist. You'll probably have buttons in your dialog. You can use the "action" attribute to make the buttons do things when you click on them: class SampleDialog { idd = 501; class controls { //////////////////////////////////////////////////////// // GUI EDITOR OUTPUT START (by DreadedEntity, v1.063, #Kicazy) //////////////////////////////////////////////////////// class RscButton_1606: RscButton { idc = 1606; text = "Click me"; //--- ToDo: Localize; x = 0.340729 * safezoneW + safezoneX; y = 0.94202 * safezoneH + safezoneY; w = 0.0955624 * safezoneW; h = 0.0340016 * safezoneH; action = "systemChat 'You clicked me';"; }; //////////////////////////////////////////////////////// // GUI EDITOR OUTPUT END //////////////////////////////////////////////////////// }; }; That should get you started in the right direction

I recommend changing all of your controls to "Position type: Safezone", I always used this method and I find it to be pretty reliable. Never used the GUI_GRID method, but I do know that if you want to use that you need to #define GUI_GRID_W, GUI_GRID_H, GUI_GRID_X, and GUI_GRID_Y

I also was not able to find the server

arma3server.exe is the executable that you run to start the server

No local variables are available either, private or not. This is because spawn creates a separate thread, rather than a lower scope

_startingMags = {_x == "30Rnd_556x45_Stanag"} count magazines player; waitUntil { ({_x == "30Rnd_556x45_Stanag"} count magazines player) > _startingMags)};

Normally when you have problems loading GUI elements, it's because your base classes (classes that your controls are derived from) are missing some (or all, in your case) required attributes

Austin, clever use of the getResolution command should make this a non-issue

This is very true, it has been several months since I've written any code that is worth posting

It goes a little deeper than that. It's not that you don't use suspension, it's that you can't use suspension. In Arma, we have scheduled environments and non-scheduled environments. In a scheduled environment, commands are put into a queue and run when it's their turn. This is what causes something called "script lag"; when a mission designer has too many active scripts running, they must all wait for their turn to execute, which can cause scripts to take much longer to run. However, in a non-scheduled environment, all of the code is executed on the spot. Everything else is stopped until all non-scheduled code is run (that includes rendering and playing sounds). If you had a sleep in that code, the game would freeze until it ended. At some point during development, a BIS dev thought that would probably not be a good idea and added some code to stop suspension commands from being run and throw an error. Some common non-scheduled environments include: The debug box (accessed by pressing esc) Initialization fields of objects placed in the editor Event handler code (includes mission event handlers, object event handlers, and GUI event handlers) The code in an addAction command Function calls It's a good idea to keep in mind whether your code is in a scheduled or non-scheduled environment when it will be run, you can eliminate some errors before they even happen. Any non-scheduled environment can be turned into a scheduled environment through use of the spawn command.

I'm glad I could help, honestly I thought that was going to be a lot harder to do that it was. This idea could be expanded upon to create another feed in the top corner as a kind of global kill feed that all players will see. Also, I'm pretty sure chat works exactly the same way as this system, except that the older messages move up instead of down.

So I guess it wasn't as complicated as I thought it might be, because I'm done. This simple system works by keeping a global list of controls, then through a "Killed" event handler it will move existing controls down and create a new control. This simple system also fades out the created controls and deletes them (confirmed by watching the global list shrink). To start off, you'll need 2 variables: One to keep track of all created controls, and another to keep assigning unused control numbers (controls cannot be created with an idc of an existing control, all idc's must be unique). Place something like this in init.sqf: activeControls = []; control = 2000; Now you need to create your event handler. To keep things easy to edit, I recommend that the only thing that your event handler contains is a script call using execVM (to make yourself really look like you know what you're doing, compile your script using the Functions Library and just do a function call instead of a script). You'll probably end up with something that looks like this: this addEventHandler ["Killed", { [control, _this select 0] execVM "kill_feed.sqf"; }]; Now what? I guess you need to actually write the script that your event handler calls. You'll need to access the global list of controls and move every active control down just a little bit. You'll then need to create another control for the most recent event, set it's text and color, and fade it out over the course of a few seconds. Oh yeah and you'll also need to spawn another thread that will handle deletion of the control you just created. After you created the control, don't forget to add it to the global list (and also increment your idc number). When it's all said and done I think you'll have something that looks like this: disableSerialization; { _ctrl = (findDisplay 46) displayCtrl _x; _pos = ctrlPosition _ctrl; _pos set [1, (_pos select 1) + 0.025]; _ctrl ctrlSetPosition _pos; _ctrl ctrlCommit 0.25; }forEach activeControls; UISleep 0.25; _ctrl = (findDisplay 46) ctrlCreate ["RscText", _this select 0]; _ctrl ctrlSetPosition [0.45, 0.7, 0.4, 0.1]; _ctrl ctrlSetTextColor [1, 0, 0, 1]; _ctrl ctrlSetText ("You killed a " + (getText(configFile >> "CfgVehicles" >> typeOf (_this select 1) >> "displayName"))); _ctrl ctrlCommit 0; _ctrl ctrlSetFade 1; _ctrl ctrlCommit 10; 0 = (_this select 0) spawn { disableSerialization; _ctrl = (findDisplay 46) displayCtrl _this; UISleep 10; ctrlDelete _ctrl; activeControls = activeControls - [_this]; }; activeControls = [_this select 0] + activeControls; control = control + 1; Hope that helps

This is a very complicated dialog, but you've gotten me interested. I've wanted to make a kill feed of some kind for a while but I haven't gotten around to it. The idea is very simple, rather than trying to work with set controls exported from the GUI Editor, I suggest trying out dynamically created controls with the ctrlCreate command. I'm going to keep looking into it and try to make something a little better, but this code should get you started on the right path (paste in init.sqf): sleep 1; disableSerialization; _display = findDisplay 46; _ctrl1 = _display ctrlCreate ["RscText", 1]; _ctrl2 = _display ctrlCreate ["RscText", 2]; _ctrl1 ctrlSetPosition [0.5, 0.7, 0.2, 0.1]; _ctrl1 ctrlSetText "Test1"; _ctrl1 ctrlCommit 0; sleep 0.5; _ctrl1 ctrlSetPosition [0.5, 0.725, 0.2, 0.1]; _ctrl2 ctrlSetText "Test2"; _ctrl1 ctrlCommit 0.25;

This so much EDIT: It's such a pain to write: while {condition} do { //stuff counter = counter + 1; };

That's pretty cool how it's from Moricky's actual steam account. Also, the default base dialog control classes can be easily found in the config viewer where they can then be copied and pasted (has anyone found out if it's possible to derive a class in description.ext using the default classes?)

I'm not really sure if this is faster, but it will clear up a lot of space in your project. Did you know you can tell the engine to add a control event handler during it's creation? Here's a sample: class RscListbox_1500: RscListbox { idc = 1500; x = 0.507964 * safezoneW + safezoneX; y = 0.414996 * safezoneH + safezoneY; w = 0.103526 * safezoneW; h = 0.272013 * safezoneH; onLBDblClick = "_this call ACS_fnc_execute;"; }; Using this method, you can eliminate those 2 useless scripts. This might even be able to solve the performance issue you've been having. It seems like you're creating too many scripts at the same time and doing too much work, crowding the scheduler. It is very possible to significantly lengthen a script's runtime by having too many scripts running.

Will you please post a larger snippet/the whole script?

Why not just use publicVariableServer? There is literally no reason to have if (isServer) then {} I think the first part means that now PVEH's can use setVariable variables for object, group, and teammembers. It's hard to tell though, of course they know what changes were made since they programmed it but reading this does not make any sense to me, but the second change is pretty cool. Now you can have code like: missionNamespace setVariable ["myVar", 0, true]; which in the past was not possible.

You need to put your defines.hpp before dialog.hpp in your description.ext. It's not possible to inherit from a class that doesn't exist.

Are you the server host or is it a dedicated server? Because if it's a dedicated server that you join, then init.sqf gets run for every player and the server.

This may be what you are looking for: isMusicPlaying = false; //toggle to let scripts know if music is already playing _musicStartEH = -1; _musicStopEH = -1; while {_musicStartEH == -1} do { _musicStartEH = addMusicEventHandler ["MusicStart", { isMusicPlaying = true; systemChat format ["%1 has started playing", (_this select 0)]; }]; }; //safely add event handler, loop will continue to run until the event handler is added while {_musicStopEH == -1} do { _musicStopEH = addMusicEventHandler ["MusicStop", { isMusicPlaying = false; systemChat format ["%1 has finished playing", (_this select 0)]; }]; }; //safely add event handler, loop will continue to run until the event handler is added { waitUntil {!isMusicPlaying}; //halt loop until music is finished playMusic _x; } forEach ["MySound1","MySound2","MySound3"]; //Play 3 sounds from CfgMusic; MySound1, MySound2, MySound3 Do note that this was hastily-written and not tested, so it may contain errors or simply not work at all. Also, since it uses waitUntil, it's probably best to run this code in a scheduled environment (like from init.sqf)

fixedWidth might possibly make it so that expanding a control has no effect, but I'm not really sure

As far as I know, there's no way to do this. Not sure if there's an easy way to do this, but what you can do is assign each letter a value that could correspond with the control's width and then add up all the values and set the control width with ctrlSetPostion and ctrlCommit. There might also be a way to check if your control is wide enough using ctrlTextHeight, if the control isn't wide enough the text is bumped down to a new line so if you make sure the return value is below a certain amount then your control is wide enough, if not then it needs to be widened. That's purely anecdotal though since I haven't used that command before and there is no documentation on that wiki page past proper syntax.