Takbal

What I am trying to optimize is the defense of towns, which is done by server-side AI. The fact that humans can be entirely replaced by AI was indeed one reason to choose WF, as I cannot expect that lots of humans are playing on my server. This way I can still collect AI vs AI data if nothing else. BTW, whats wrong with WF? I know it is a matter of taste, but IMHO it is the best MP game mode.

FYI: the server is up at 155.198.117.142 ([iMPERIAL] Warfare VETS) for a few months now and looks stable. It is using A2: Combined Ops and running Warfare with an improved version of Benny's edition on Chernarus (I felt the factions of Takistan are too asymmetric). It is on hard difficulty to make everything more realistic (down to no crosshairs). I could definitely use data with more human players, so if you happen to have Combined Ops, give it a try.

I tried and it does not help in my case, although what I am observing a general performance breakdown in the latest betas and the 1.07 patch, not just next to trees, rather everyhere. I reported it here: http://dev-heaven.net/issues/11550 I cannot be sure, but I have a feeling that it is the same issue.

BIS answer was positive which we really appreciate. Setting up a server is under way. Our study is more about how to help the decision maker, that is, how to improve AI decisions via learning by examples, rather than applying serious games for training. To study decision making, fidelity is only necessary to maintain abstract properties of the problem space (like the problem of environment, teamwork, hidden observations and need to estimate probabilities). We do not want to re-create reality, just use something where players has similar problems to solve as in reality. We are happy if gamers play, as they are human 'experts' in this environment. If you are interested in playing on the server and helping science, I will post its address later here.

We are thinking about using ArmA II for collecting data in multiplayer environment and test algorithms based on these data which produce better AI behaviour. We understand that Bohemia Group recommends VBS2 for such purpose which we also own. The problem with VBS2 it is much harder to find players. With ArmA II it is easy to set up a server, run a popular mission and collect data about how players and AI behave, non-stop, 24h a day. Obviously players must be notified that some of their acts are anonymously recorded on the server. The goal of the project is non-profit academic research and to produce publications. My question is whether this use is allowed by BIS and the licensing, and to what extent. There are multiple possible levels of using ArmA II, which must be differentiated between. 1. Modding the game and setting up a server is obviously allowed as this is officially encouraged. Logging player data is a question of agreement between the players and the server owner (some data is always logged anyway). Probably the only concern here is using the program not for personal use, rather for common good (science). 2. A scientific publication can omit all refererence to the game, including its name, any data taken from it (like showing screenshots, its map etc.) and present the study's results in a general form (like 'we used a multiplayer game...'). This can be done in such an extent that it is not even obvious that ArmA II was used. It is not for hiding the fact, just to protect the concerns of the publisher about how the game is used. 3. A scientific publication can make explicit that ArmA II was used, but do not reproduce any data from the game, only the results of the research. License 3/III probably concerns this point: "[you are not entitled to] exploit the Program or any of its parts for any commercial purpose". It looks like BIS is actively chosen *not* to restrict non-commercial exploitation. 4. A publication may show some elementary data from the game, like showing map fragments, the layout of a town or screenshots. This looks like being forbidden in the license without written consent, as it is publishing parts of the game, although in a very mild form. What is the official BIS policy about this regarding academic research? I would be happy if anybody from BIS could clarify whether any of the points 1-4 are allowed, and which one is preferred.

so once more...

I just found an interesting remark in the arty module: And also this: And then in the script synchronization is truly processed on the server side only. I do not see any special to it rather than using the synchronized objects as a (static) array, but according to the second remark, "deprecation" migh occur, whatever the hell it means... Are the logics server side only? If I remember correctly I was able to create them on clients. They were not showing up as remote.

I have seen this technique, namely attaching/detaching logic to objects in the official scripts. Also noticed that many logics need to be some objects to be synchronized to it to work properly, like the SecOps module needs the player, but I could not find any description about what do these commands actually do to abstract things like a game logic. To my understanding, a logic is practically an object without physical entity ordered to it. It is "sideless" in that sense that it has "sideLogic" side, but otherwise it behaves like a normal object does, so it can be PublicVariable'd or can co-exist on clients/server. I am not sure about their purpose next to serving as a namespace, but what I see as a potential useful feature is to actually serve as a "switchyard" for scripts in MP, if some of their functions can be called even when they are remote, but executing those scripts only on those instance where they are local. I suspect that attach actually does that: it *transfers* ownership of an object to that instance which has the object which you are attaching to. So it probably behaves as a virtual "transferOwner" command, but not sure about that. As it is not transferring those functions which are compiled into the global namespace in the client of the original owner when the logic was initialized, it does not make sense without an actual running instance (or at least an initialization) on the new owner as well... I have even less idea about synchronizing. With triggers, I can understand that you can create a condition list with them. But for logic? Do they guarantee that, for example, the objects synchronized will be accessible somewhere to the scripts in the logic? Or are they serving as a replacement for PublicVariable, and keep updating the data of the synchronized objects to the client owning the logic? I could start experimenting on my own, but somebody may already figure out what do attach/detach and synchronize do for logics at the game engine level. Please share it with us.

Sorry, bad login :)

Luke, just a question about that lock/unlock bug: was the action entirely disappearing from the menu, or you could select it, but it did nothing? If it happens next time please send me the .rpt files.

Hi all, How to change an already defined script's path or an existing GUI class from a *mission* (not from an addon)? I am quite beginner, so probably the answer is simple. I am modifying the warfare mission and I have to change a script which is called through the onLoad definition of an existing GUI class. I un-binned the CA UI's config.bin and looked into the class definitions. Unfortunately, the script path looks like wired in by BIS using the 'ca\Warfare2\Scripts\Client\GUI\GUI_BuyGearMenu.sqf' absolute path in the 'RscDisplayBuyGear' class. #1 idea: replace the existing script or its path by some trick from the mission. I could not find a way to do this, and I doubt whether it is possible at all, so I moved on. #2 idea: as I can change which dialog class is used (in GUI_buyPrepareMenu.sqf), so lets modify the 'RscDisplayBuyGear' class to have my custom script named in the 'onLoad' part. 1. proposal for #2: inherit from the original RscDisplayBuyGear into a new RscDisplayBuyGearCustom class and use that. I tried to use the following: //////////////////// class RscDisplayBuyUnits; class RscDisplayBuyUnitsCustom : RscDisplayBuyUnits { onLoad = "[findDisplay 106, _buyType] execVM 'Scripts\Client\GUI\GUI_buyUnitsMenu.sqf'"; idd = 5088; class Filters; // are these necessary to inherit? class controlsBackground; class controls; }; ////////////////// and I replace the following line in GUI_buyPrepareMenu.sqf: ... case 'units': {CreateGearDialog [player,"RscDisplayBuyUnitsCustom"];}; ... Then when the above script is called then it complains about "Warning Message: No entry 'bin\config.bin.RscDisplayBuyUnitsCustom'." and the dialog is dead. 2. proposal for #2: try to replace the original class partially and use the original GUI_buyPrepareMenu.sqf. I have seen a a way to do this in the stra_debug2.pbo addon which works. ///////////// class RscDisplayGear; class RscDisplayBuyUnits : RscDisplayGear { onLoad = "[findDisplay 106, _buyType] execVM 'Scripts\Client\GUI\GUI_buyUnitsMenu.sqf'"; idd = 5088; class Filters { class All; class Primary; class Secondary; class HandGun; class Items; }; class controlsBackground { class Mainback; }; class controls { class CA_Filter_Arrow_Left_L; class CA_Filter_Arrow_Left_R; class CA_Filter_Left_Icont_L; class CA_Filter_Right_Icon_R; class Gear_Title; class Unit_Title; class Available_items_Text; class CA_Filter_IconUnits; class CA_Filter_Icon1Units; class CA_ItemName; class CA_Money; class CA_Money_Value; class ListboxArrows { class VScrollbar; class HScrollbar; class controls { class Available_units; class Queued_units; class CA_B_Add; }; }; class ButtonFilters; class ButtonContinue; class ButtonClose; }; }; ///////////// Result is no effect - buy menu is unmodified. stra_debug2 is an addon and uses the definition in a config.cpp, so probably I could do the same with making an addon and using its config.cpp, but I would like to have a mission without addons. I have tried to create a config.cpp in the mission folder and repeat in it what I had above, also tried converting it to config.bin, but it looks like being not used at all. 3. proposal for #2: Copy the entire class. Again, no effect. #3 idea: perhaps the problem is with the new, ArmA2-introduced CreateGearDialog command, and it cannot read classes from description.ext, only from config.bins. One of the comments say that CreateGearDialog is used because of filtering; not sure whether using CreateDialog helps. Anyway, replaced it with CreateDialog and tried the proposals above again. Now the problem is that the class definition cannot see the base classes. Tried to look around the files, but no .hpp's to include. I tried renaming CAUI's config.cpp into UI.hpp and including this in description.ext, it partially works, but throws a lot of error. So then 1. how to use CreateGearDialog with a custom-made mission class? 2. if it is impossible, then how to make description.ext aware of the classes defined in the UI's config.bin, and use them properly with CreateDialog? Any ideas welcome... ------------------------------------------------------ UPDATE: If I create an addon with the following config.cpp: /////// class CfgPatches { class RscDisplayBuyUnitsCustom { units[] = {}; weapons[] = {}; requiredVersion = 0.100000; requiredAddons[] = {}; }; }; class RscDisplayBuyUnits; class RscDisplayBuyUnitsCustom : RscDisplayBuyUnits { onLoad = "[findDisplay 106, _buyType] execVM 'Scripts\Client\GUI\GUI_buyUnitsMenu.sqf'"; idd = 5088; }; //////// it works. But come on - it is such a mess to force people to download and install a 450 BYTE (!!!) .pbo. There should be another way...

One more vote for a rapid port to ArmA2... I would like to use it. Nice work Kegetys anyway! :)

I was boxed last night as well - should have asked the guy to stop or ask admin to kick him but I was a bit surprised. ArmA is about giving a close to real experience about combat, and walling in enemies is the farthest possible from this. This is an exploit, period. Anyone doing it should be banned on spot. If unsure about exploits, always ask the simple question: can it be happen in real life? Shelling a camp can, while building magic walls cannot. It is easy to be fixed: if an enemy is nearby (a bit further than building range), building is disabled, just like capture is not done whenever enemy is nearby. This solution is realistic: nobody places sandbags or sets up buildings when fired upon.