OFPEC Forum
Editors Depot - Mission Editing and Scripting => ArmA - Editing/Scripting General => Topic started by: Worldeater on 08 Jan 2009, 22:04:31
-
I'm currently writing a replacement for the Voyager's ArmA Extended DLL (http://voyager.alfamoon.com/index.php?go=News&in=view&id=16).
The idea is to put code into the running ArmA process, tap the file access and check for special filenames. This allows for loadFile (http://www.ofpec.com/COMREF/index.php?action=details&id=200) to exchange data with the code. I got this part working fine.
Now I'd like to have some sort of mechanism to tell scripts that my extension is available. Voyager's DLL doesn't provide this functionality. Kegetys' ArmAlib seems to accomplish it by further poking around in the processes memory to replace a script command (I guess that's why his lib depends on specific ArmA versions). Being version dependent is unacceptable if there's another way. I also don't like the idea of tampering with any of ArmA's data.
My first idea was to use loadFile and poll for a special filename (like ":status") and see if it returns a non-empty string (my code would ensure that the file is found). But this displays an error message if my extension isn't running. Having error messages is also unacceptable.
So, do you guys have any suggestions on how I could let a script know that my extension is available?
-
havent tried myself, but you might play with try/catch (http://www.ofpec.com/COMREF/index.php?action=details&id=803) blocks to avoid error messages while being able to catch the exception.
-
I've already tried it, to no avail.
-
You can use a file in ArmA's root.
For example the readme.txt.
Then you simple load it and convert it to string (parseNumber). Either it is 0 or your version number ;)
The only 'problem' is that no one else can load that file.
-
Thanks i0n0s! That was the spark that got the fire lit! :good:
Let's not just take some file. Let's take a script file that ships with the package and have it call itself over and over again:
sleep 1; [] spawn compile loadFile "HAA_CheckStatus.sqf";
So all the extension has to do is to tell ArmA the content of the file is:
HAA_isActive = true;
Recursion stopped, global variable set. Nice!
Well, so much for the theory. The next problem is that ArmA keeps track of the files it has read and won't read them again. But... it will forget about the script files whenever it lost focus.
Uhm, looks like I have to find out how to trigger a focus change. Sounds pretty easy... :)
-
You want to use a file which comes with your addon?
Otherwise the user may not have it ;)
Remember that the file is not allowed to be within a pbo since they don't trigger a CreateFileW call.
To bypass the "read only once" you simple can use exec which should read it from the file on every call (as sqs).
Be aware that this problem occurs too on your commands. So ':time' will only get called once and then ArmA will use the cached version. My solution in the RTE was a integer which was passed to (':time:124'). But using exec should be a solution too.
Btw: If you want to integrate your dll into the real time alternative, feel free to contact me ;)
-
havent tried myself, but you might play with try/catch (http://www.ofpec.com/COMREF/index.php?action=details&id=803) blocks to avoid error messages while being able to catch the exception.
I know this has already been discounted, but I'll reiterate that try/catch only operates via manually thrown exceptions. It does not interact, nor is supposed to interact, with the ArmA error system. I think we've all wished we could catch ArmA errors this way at once time or other ;P
---
Good luck with this, but I'm not entirely sure what advantages this system will have over ArmALib. I would ask for about 1000 new features to come in extensions like this, but sadly, the fact that these systems aren't likely to be universally used any time soon (and having a new one to replace ArmaLib, rather than extending the reasonably popular ArmALib, is only likely to make global acceptance harder), I won't use be keen to use them. As it is, I do add optional functionality to a couple of my systems if ArmALib is available, but I'd be very hard pressed to rely on it. Nevertheless, good luck with this project!
Something I would like to suggest though, would be a modular extension system. If it was easier to extend ArmA with new functionality, rather than relying on Keygetys to do this work, I think that would be a genuinely useful replacement for ArmALib, et al. For example, the easiest way to extend ArmAlib that I can see is to connect to it via a named pipe. Kind of messy and non-multiplexed for a really useful system, I think (i0n0s's editor uses this method, but what happens when 2 systems want to use this pipe at the same time?). I still have a early WIP sitting around somewhere, which is a Ruby backend system that hooks into that pipe to be my own way of extending it (and yes, I was going to multiplex the pipe via sockets). If nothing else you've reminded me I should dig that out again and fix it ;P
Aaaanyway, just some late-night thoughts.
-
This is not going to be a replacement for ArmAlib. The idea was to provide an alternative to the "ArmA Extended DLL" for people who trust their AV software / Windows Defender more than some random guy on the internet who tells them to ignore warnings about trojans.
The (BSD licenced) source code will be included so people with an appropriate technical background can have a look at what's going on behind the scenes.
The package will consist of three parts:
- A tiny core (plain old C, ~300 LoC) that exchanges data between scripts and some external program.
- At least one example project (VB.Net, Perl, Assembler, Snobol, whatever) that shows how to connect to the core and process the data.
- An optional script part (SQF) that provides a wrapper for loadFile and checks whether the core is loaded or not.
The whole thing is going to be nothing more than an open source "ScriptLink" with proper examples of how to use it. One of the example projects will simulate Voyager's DLL so it can be used for Silola's 3DE (http://mapfact.net/include.php?path=content/download_eng.php&contentid=658&PHPKITSID=b12fbe94c11f91bcfba5c65dbeb5ee86). It is not really meant to be used by the average scripter to pimp up his mission but for coders who develop tools like RTE or 3DE.
-
Yeah, sorry, I was a bit negative before! Absolutely, an open-source anything that is closed-source is worthwhile.
Good luck!
-
Any progress in here?
-
Nope. The project is delayed until I a) get some new motivation and b) find a clean solution.