ryfle
Member-
Content Count
42 -
Joined
-
Last visited
-
Medals
Community Reputation
10 GoodAbout ryfle
-
Rank
Lance Corporal
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
Various questions on scripting and the engine...
ryfle replied to ryfle's topic in ARMA 2 & OA : MISSIONS - Editing & Scripting
Thanks again, Muzzleflash. I'll look into creating my own addon that the game will load, as I plan to create my own modules and such anyway. Kinda new in this department though. If anyone else knows about the "global scripts folder", please illuminate the subject for us. :) Exactly. :) That's not to knock on BIS, but it's true. And actually, compared to many others I've seen SQF is far better. But it's still an "in-house" language, as your friend calls them. I often wonder though why script engine programmers just don't stick to what's already out there and they're familiar with. Obviously they know C and C++. So why not just copy the syntax and basic constructs, and omit complicated language features like polymorphism if need be? That I don't know. Maybe people who embark on such projects have ambitious plans when they get started, and the hope of making a full, powerful language, and their dreams quickly get battered by production schedules, investor demands, etc. As far as "in-house" languages go, I think the best one I've seen comes from a little Company called Conitec. They produce a relatively inexpensive and simple "hobbyist" game engine called "3D Game Studio", which I used to play with a bit years ago. And they've implemented their own scripting language called "Lite-C". They essentially did what I said: copied the basics of a working language, C++, omitted a few things and added a few. And the result is impressive considering that they're not a language and compiler design company! You can Google it if you're curious about it's features, or see a syntax example on Wikipedia. But it should suffice to say it compiles the script to machine code on-the-fly, has reasonable performance, can work in tandem with C and C++ code, is "COM-aware" and is somewhat extensible. I'm no expert, by any stretch of imagination, but I know a thing or two about language design and writing compilers, assemblers, linkers and even disassemblers. In my teen years, I fancied myself something of a hacker... or "h4x0rZ" as I might have called it back then, lol. :rolleyes: I've never worked in the field on a professional level, but have done some pretty cool hobby projects. I wrote a minimal x86 assembler, a C preprocessor (never finished my C compiler), a C#/.NET compiler, a couple interpreters, and I've even implemented a barebones .NET language + compiler of my own and purpose-built interpreted scripting languages. None of these were commercial quality, lacked features, had bugs, etc... But weren't bad for a one-man-job in a short period of time. With a little compensation for my time, I'd be more than happy to help BIS spruce up their SQF language and engine (seriously), heheh. Probably will never actually happen, but I put the offer out there. ;) Yep, I've got the BIS tools and a few unofficial ones, and I do this. It's how I implemented my basic spotter script where the spotter uses a rangefinder and tells you the range to whatever target you aim at -- as seen in the single mission for OA. This is true. And I'm still learning not only how the game and engine works and operates, but how to play the game and enjoy all of its features. And that's what this thread is for -- spilling at questions, discussing and learning more! :) And yes, having programming experience makes learning scripting super easy. The main roadblock is lack of documentation/examples, difficulty in finding things and some of SQF's oddities. Regards, -
Various questions on scripting and the engine...
ryfle replied to ryfle's topic in ARMA 2 & OA : MISSIONS - Editing & Scripting
I see, Muzzleflash, thanks. And if you already know C#, then you didn't miss anything by not reading it all, so no worries. And thanks to you too, Loyal. Pity there is no 'continue'. While the proposed solution you've given can work, and I was aware of it, it does make code bulkier when you've got some sophisticated inner workings in your loop. My example was chosen for simplicity, so you worked around it easily by just using if-then. But I wish we had such a thing for when it counts. :P Anyways... Some other things I'm curious about now... I found the Wiki page for the SQF preprocessor, and found the #include directive. But does it just work "as is", like in C? What I'm trying to do is write a file full of all my own SQF functions, called "atcfn.sqf". And I'm also writing a macros file called "atc_macros.?" <-- that's where I'm confused. What type of file should that header be? SQF? HPP? Maybe even .h, or anything I so choose? And do I just #include what I want, and no need for the "compile" or "preprocessFile" commands? Also, I want to have my own global scripts folder. I have scripts I use all the time and: A) I hate copying them into every mission folder B) I don't want to put them somewhere on my HD and have to use a long, full path to get at them. The Wiki page mentions this. But... my ARMA 2 OA folder doesn't have the path "ca\data\scripts\" anywhere. I have no scripts folder at all, as far as I can tell. So I suppose I must create it? Where? ---------------------------------------- P.S. to Muzzleflash: ---------------------------------------- I also think SQF is a pretty cool scripting language, and as a game developer I know how monumental the task of writing a good script engine/language is. So I couldn't knock on BIS for anything. ARMA and everything about it is incredibly impressive. But I still see room for improvement in future versions. In fact, I'm planning to soon make a suggestion thread (aimed at ARMA 3) about enhancements I'd like to see in the scripting language. One of the main things I think could make the language better is streamlining the syntax. While the language is simple and elegant in many ways, some parts of it are just, imho, hideously verbose. As I said earlier, the array indexing operator 'select' is one thing I hate. I think that maybe 'select' could remain valid syntax, for those who like it, but the C-like [#] indexing op should be added. I also think that the "then" keyword, used in compound with if/else statements, should be eliminated. It serves no purpose, and just adds clutter and more typing. The same thing goes for the "do" keyword following loop constructs. Ironically, 'do' doesn't seem to (afaik) actually do anything in SQF like it does in C. So I deem it, too, unnecessary verbosity. I'd also like to see an increment/decrement operator. And also more streamlining and consistency in the use of parenthesis, brackets and braces. And they should also eliminate the over-use of semicolons (e.g., terminating an if/else branch). If it were up to me, my enhanced SQF syntax would be like this: Array indexing Original Syntax: x = myArray select 3; Enhanced Syntax x = myArray[3]; If/Else Original Syntax: if( condition ) then { } else { }; Enhanced Syntax if( condition ) { } else { } While Original Syntax: while { condition } do { }; Enhanced Syntax while( condition ) { } -- or -- do { } while( condition ); For loop Original Syntax: for[ {i = 0;}, {i < n;}, {n = (n + 1);} ] do { ... }; // -- OR -- // for "_i" from 0 to n do { ... }; Enhanced Syntax for( int i = 0; i < n; n++) { ... } Foreach loop Original Syntax: { _x doSomething; } forEach units grp; Enhanced Syntax foreach(Unit u in grp) { u doSomething; } Just a little preview of the type of syntax enhancements I think would be a major win. Makes things a bit more C-like, which I think is a good thing. The C-family syntax is ubiquitous for a reason -- it's elegant, concise and powerful. Plus, programmers like me don't have to relearn basics to script ARMA, and newbies can pick it up just as fast and walk away with basic knowledge that could be employed in learning programming. :cool: Language features, on the other hand, are a different story and can be tough to implement. So I won't whine about there being no true OOP yet. :D -
Various questions on scripting and the engine...
ryfle replied to ryfle's topic in ARMA 2 & OA : MISSIONS - Editing & Scripting
This was originally an edit appended to my last post, but more and more language questions keep popping into my head. :D 1) No 'continue' keyword? I have another question now though... Is there no "continue" keyword for loops, as found in most every C-family language? If not, how do we get a loop to skip to the next cycle, like this: for(i = 0; i < count; ++i) { if(myArray[i] >= 10) continue; myArray[i]++; } FYI, this loop would iterate through the members of "myArray". If the item at index 'i' on the current iteration is greater than or equal to 10, the loop would go back to the top and start on the next cycle. If not, it runs to completion and increments myArray. If myArray held the following integers: int[] myArray = { 1, 5, 6, 3, 11, 4, 15, 9, 21 }; Then the loop would modify these values to: { 2, 6, 7, 4, 11, 5, 15, 10, 21 } ...just wanted to clarify, in case someone is not familiar with C-like languages. But how do we achieve this in ARMA script? :confused: 2) Array indexing... I really, really, really hate the array indexing operator syntax in ARMA scripting... being forced to type the word 'select' followed by the index. Like this: _x = myArray select 3; To me, that's just unnecessary verbosity and breaks the readability of what is a rather simple and understandable language. I'm used to (and like) the C-style index operator: _x = myArray[3]; Much shorter, less typing, easier to read... and also consistent with array indexing form in mathematics. So I'm wondering, has anyone come up with a good preprocessor trick that will allow me to use the C-style syntax in my own code (so long as I #include my macros file)? Basically I'd like to come up with a good macro shortcut so if I write this in my script: _weapon = _items[3]; The preprocessor would expand it to this: _weapon = _items select 3; Just an "aesthetic" syntactical difference, but one I would thoroughly enjoy. Knowing how to accomplish this, if possible, would let me invent a few more scripting syntax shortcuts. My more complicated scripts are just a pain to read (and type), so this could be a huge help! 3) Objects in ARMA script I'm not sure I quite understand how objects (reference types, like classes) work in ARMA script. I've seen some scripts where people define their own classes, and I see the language has some notion of inheritance/polymorphism, but my understanding is insufficient. In a language like C# or C++, declaring a class type is syntactically similar to what I've seen in AS (ARMA script): class Dog { ... }; And classes can have members -- variables and methods. Consider this in C#: public enum DogSize { Teacup = 0x00, Toy = 0x01, Small = 0x02, Medium = 0x04, Large = 0x08, Giant = 0x16 }; public abstract class Dog { /* Constructors: */ public Dog( string Name ) { this._name = Name; } public Dog( string Name, int Age, DogSize Size ) : this(Name) { this._age = Age; this._size = Size; } /* Private Fields: */ private string _name; private int _age; private DogSize _size; /* Public Properties: */ public string Name { get { return _name; } } public int Age { get { return _age; } set { _age = value } } public DogSize Size { get { return _size; } } /* Instance Methods: */ void increaseAge() { _age++; } internal abstract void Bark(int volume); public void Sleep(int time) { // ...some sleeping code } /* Static Methods */ public static void ChangeSize( Dog dog, DogSize newSize ) { dog._size = newSize; } }; The above code demonstrates many features of classes in C# (most of which come from its C++ heritage). I threw in the enum example because I want to know if enums, or something like it, exists in AS? But anyway, I'll describe what you're seeing above for those who don't know C#, Java, C++ or something similar (just ignore the enum bit in that case -- it's basically just a way of having a type constrained to predefined constants)... What we have here is a brand new type, called "Dog". The code above is not a Dog in and of itself, but rather the definition of what a Dog is. Just like "int" is not actually an integer, because it's a type. 10 is an integer. And we can create variables of type int like this: "int i = 10;"... Likewise, we create instances of classes in C#. That's where those constructors come in handy! Dog myDog = new Dog("Rover"); Constructors, which look similar to a method or C function, return a new instance of the class type and the code within performs initialization logic. But what about in ARMA scripting? All the class definitions I've yet seen seem to be more of a "configuration" type of thing, rather than OOP object types. Can we create instances of classes? Can we have constructors, destructors, etc? Skimming further down, we see the private fields. These are just variable fields that every instance of Dog will have. All instances of type Dog will have a name ("_name"), age ("_age") and dog size ("_size"). Like this: Dog myDog = new Dog( "Rover", 2, DogSize.Medium ); Dog yourDog = new Dog( "Spot", 3, DogSize.Large ); Now we have two instances of type Dog: myDog and yourDog. myDog goes by the name "Rover", has an age of 2 and a dog size of Medium, while yourDog goes by the name "Spot", has an age of 3 and is Large. AFAIK, ARMA script classes certainly have variable fields. That is the bread and butter of classes. But how does it compare to a language like C#, C++ or Java? How do we access instance fields? static fields? Well, are static fields even possible, or is everything static because there is no instancing concept at all? The next thing is the incredibly powerful feature called properties. Properties act as accessor methods for fields within a class (instance or static). Just by looking at the code, you should understand what it does. All of the fields I declared, _name, _age and _size are private... they cannot be read or touched by anything other than the instance of Dog itself. They're not exposed to the outside world (if I'd used the 'public' scope they would be, but that's considered bad practice). So we use properties, which are quite like methods/functions at heart. Properties can have two parts: a 'get' accessor and 'set' accessor, which are like sub-functions of the property. A get accessor returns a value, while a set accessor modifies a value. Which one is called simply depends on the context we use the property in: string s = myDog.Name; // calls Name >> get, which returns the field '_name' myDog.Name = "Rex"; // calls Name >> set... details below.. The second line triggers the 'set' accessor in the Name property, which contains the code: "_name = value;". The 'value' keyword is a special keyword, used only in property set accessors. It stores the value given when an assignment operator (=) is used on a property implicitly (yes, the C# compiler and CLR are quite smart). To the outside world, the property "Name" works just like a regular string variable. But we can not only control access to it better, but we can do other things in our code every time the property is accessed to read or modify it. Let's say we change the definition like so: public string Name { get { Console.WriteLine("_name has been read..."); return _name; } set { Console.WriteLine("_name has been changed to '{0}'...", value); _name = value; } } Now something cool will happen any time Name is used. The following code: string str = myDog.Name; myDog.Name = "Rex"; Would not only copy the literal "Rover" into the variable 'str' and change the underlying field '_name' to "Rex", but would generate the following output to the console: A contrived example, which has little real-world application (save debug logging), but you hopefully get the point: it's an incredibly powerful feature. Furthermore, you can define just a 'get' accessor or just a 'set' accessor in the body of your property (as you see in the others), to constrain the property to being read-only or write-only. You can also modify accessibility by preceding the keyword 'get' or 'set' with a modifier like 'public', 'private', 'internal' or 'protected'. And as you might have guessed, properties can also be virtual (allowing overriding implementations in derived classes) or abstract (no default implementation and requires implementation in derived class types). But what about ARMA script? It doesn't appear there is such a feature, but do we have anything remotely close to it? Now we come to the methods. They are quite similar to the free-standing functions you see in C/C++ and ARMA script. However, they are members of a class. They are accessed, like variables, by using the "dot accessor", the "." operator. And all members of the class, such as other methods, variables, properties, etc are local in scope within a method body. In other words, to access _name we can just write "_name"... we don't need to use "this._name" (or something like myDog._name, which is invalid) unless it's to disambiguate (e.g., distinguish a field from a parameter with the same identifier (name)). The first method, "increaseAge", can only be called inside of the class itself. "myDog.increaseAge();" would be invalid, as it's private. But in any (non-static) method, property or constructor within Dog, it can be used as simply "increaseAge();" or "this.increaseAge();". The public method "Sleep" can be used inside of Dog the same way, but since it's public it can be used by external code... in another class you may call it with "myDog.Sleep(1);". I won't get into a lengthy explanation of the one above that, "Bark", but it is different. You'll notice it has no actual body/implementation, but is merely a declaration of a method (its signature). This is because it is an abstract method. Abstract methods have no implementation. They are similar to virtual methods, which can be overridden and reimplemented in derived classes that inherit from the base class. But abstract methods: A) have no implementation B) must be overridden and implemented in any class that inherits from the defining parent class. So if we wanted to make a class called "Beagle" that inherited from Dog, the "Bark" method must be overridden and implemented: public class Beagle : Dog { }; // does not compile! Error! // This is correct: public class Beagle : Dog { public override void Bark(int volume) { // ...implement logic to actually do something here } }; Now if we'd made that method virtual instead of abstract, there would be some differences. First of all, we could drop the "abstract" modifier on class Dog, and overriding Bark in type Beagle would be optional, not required. And it would need a body inside of our Dog definition: public virtual void Bark(int volume) { } ...instead of public abstract void Bark(int volume); And inside the body, we could have an implementation. As a contrived example, let's say we made it like this: public virtual void Bark(int volume) { Console.WriteLine( "Dog.Bark( {0} ) called!", volume.ToString() ); } ...then we override it inside of Beagle, like so: public override void Bark(int volume) { Console.WriteLine( "Beagle.Bark( {0} ) called!, volume.ToString() ); } Then we write a simple program with this in our Main() method: Beagle myBeagle = new Beagle( "Jackson", 4, DogSize.Small ); myBeagle.Bark(1); We would just get "Beagle.Bark(1) called!" printed to the console. But C# has a special feature. What if we want the implementation with Dog to run too? Then we can change our Beagle.Bark implementation to: public override void Bark(int volume) { Console.WriteLine( "Beagle.Bark( {0} ) called!, volume.ToString() ); base.Bark(volume); } Now the above program would generate this output: Cool, eh? Again, these are quite useless, contrived examples I made up for simplicity's sake. But you can probably see how this puts immense power in a programmer's hands! The only other thing to remark on is the "static" keyword you see in the original Dog definition, which is used to mark the "ChangeSize" method static. What does it do? Well, it makes the method static, lol. In other words, it's a member of type Dog itself rather than a member of Dog instances. Consider this: Dog myDog = new Dog("Rover"); myDog.ChangeSize( myDog, DogSize.Small ); //! Error! That wouldn't work. ChangeSize is static, and not a member of the myDog instance but is a member of Dog itself. The correct way to use it is as follows: Dog myDog = new Dog("Rover"); Dog.ChangeSize( myDog, DogSize.Small ); Now that's pretty much everything... I think... I've demonstrated most of the Object-Oriented (OO) features of classes in my favorite language, C#, and I'm very curious how these concepts and syntax can be paralleled in ARMA script. And I apologize for the deep C# OOP lesson, but I wanted the things I'm asking to make sense to non-programmers so they'll know what on earth I'm talking about. :) So what do I need to know about this to be a better ARMA scripter? What features do we or don't we have at our disposal? What key differences might I need to be aware of? Every little bit of info helps. And if someone could mirror back my C# above in ARMA script with some explanations, that would be a godsend indeed! :D Thanks again for your time and help! P.S. -- I'm pretty sure ARMA script has an #include directive? How to use it? Just like in C/C++? Wiki page? Can't find it... -
MSO Team are recruiting!
ryfle replied to tupolov's topic in ARMA 2 & OA : MISSIONS - Editing & Scripting
These jobs all concern MP mission and module scripting? If so, I don't suppose I'd be of use. I can't even play multiplayer because I'm stuck with crappy HughesNet at home -- talk about l... a... g... :P So I've never done any MP scripting for that reason. But if you're doing anything non-MP, maybe I could do a little. -
Various questions on scripting and the engine...
ryfle replied to ryfle's topic in ARMA 2 & OA : MISSIONS - Editing & Scripting
Very useful information! :) Most programming languages, afaik, work this way too. To be technical, arrays are nothing but an abstraction to represent a contiguous piece of memory storing a series of elements of a known size (even if we don't know the size, the ARMA engine does)... just as a string is an abstraction for a char array and time, as we know it in the non-scientific sense, is an abstraction for the position of the sun over our part of the earth. ;) In C, C++ and many other languages an array actually is a pointer. It is the address of the beginning of the block of memory which stores the elements we allocate. Consider the following: // Create an array of chars... char myName[] = { 'A', 'a', 'r', 'o', 'n', '\0' }; // Allocate block of memory... char* myName_ptr = (char *) malloc( (sizeof(char) * 6) ); /*---------------------------------------------------- * Here we treat a pointer like an array to copy chars *----------------------------------------------------*/ for( int i = 0; i < 6; ++i ) myName_ptr[i] = myName[i]; // Print the result... cout << myName_ptr << endl; /*---------------------------------------------------- * Now we can treat the array like a pointer... *----------------------------------------------------*/ // Like this... for( char* p = myName; *p != '\0'; ++p ) cout << *p; cout << endl; // Or this... int n = -1; while( (n++ < 6) && ( *(myName + n) != '\0' ) ) cout << *(myName + n); cout << endl; The result of this code is that my name, "Aaron", is printed 3x's to the console: Maybe you already knew this, but surely someone else didn't. But the point is that arrays actually are pointers, in a technical sense and very real sense in most languages. The indexing operator "[#]" is really a "shortcut" for dereferencing (pointer + offset). So this: myArray[2] ...is the same as this: *(myArray + 2) Cheers! :cool: -
Various questions on scripting and the engine...
ryfle replied to ryfle's topic in ARMA 2 & OA : MISSIONS - Editing & Scripting
Thank you both for your posts; very helpful and informative. :) @ columdrum: For #3, disregard my use of a pointer in the C example. I didn't even write the function correctly anyway, haha. :D Should've been more like this: int clamp(int* value, int min, int max) { int a = *value; a = ( (a > max) ? max : a ); a = ( (a < min) ? min : a ); *value = a; return 0x00; //! success } Not sure what I was smoking when I wrote it the first time. Lol, I must have been tired if I used the address op instead of dereferencing the pointer to "value" and then modifying the underlying value. Sometimes the code in my head doesn't map so well to my keyboard... thank God for Intellisense, lol! :o But anyway... I suppose ARMA script also has no concept of references, as in: C++: void myFunc( int &a ) { ++a; } C#: void myFunc( ref int a ) { ++a; } ? Again, thank you both and if anyone has more to add I'm all ears! :) -
Various questions on scripting and the engine...
ryfle posted a topic in ARMA 2 & OA : MISSIONS - Editing & Scripting
Hello everyone, I've been playing around and doing lots of testing to figure out how to do everything before I start serious work on some rather ambitious mods I want to do. And I've run into a few more roadblocks and questions, as expected. So I'm hoping one of you ladies and gentlemen can help... 1) waypointAttachObject (and unit-follows-unit...) I'm experimenting with some different ways of getting one unit/group to follow another without a jerky "stop-start" over and over. From the sound of it, waypointAttachObject may be helpful. From what I understand by reading the Wiki, it attaches the waypoint to an object, right, like when you set a waypoint on a house or unit in the editor by double-clicking it? If not, what exactly does it do? And where the heck do you get the objectID from? Searching for the answer has yielded nothing beyond the vague Wiki text... It seems like there should be a command like "objID <obj>", but apparently there is not. So...? And has anyone come up with a good solution for following behaviour? doFollow is no good because it only works locally within a group. And I've already found, downloaded and tried several example scripts, and found all of them unsatisfactory (the unit stops and starts, often at a sprint, over and over). I really need smooth following behavior... 2) Programatically created waypoints I cannot figure out (or find out) how to detect when a waypoint I've assigned programatically is completed, or how to capture the waypoint activation/completion as is so very easy to do in the editor. After banging my head against the wall, scouring the forums and the net at large and trying random things I'm fresh out of ideas/leads. Any ideas on this? One reason I ask is because some scripts I'm working on are going to generate waypoints over and over on-the-fly. AFAIK, when a unit completes a waypoint it does not delete or discard it from the inner array of waypoints, and I worry about wasting memory (as well as keeping track of indices). Sure, a waypoint seems to be the equivalent of a DirectX Vector2 type or float[2] (two 32-bit floating-point values), which isn't a lot of memory in and of itself, but I'm sure the engine allocates more than just the coordinates. So I want to delete waypoints upon completion for the sake of RAM budgeting, just to be safe. Any ideas/info on that? 3) Functions I'm going to implement a few functions, but I'm still not sure how to do it and can't find a decent example of the nuances of ARMA script functions. I'm quite familiar with functions in C/C++ and object methods in C++, C#, Java, etc... For example: int clamp(int* value, int min, int max) { int a = &value; a = ( (a > max) ? max : a ); a = ( (a < min) ? min : a ); return a; } What might the equivalent to this simple C function look like in ARMA script? The Wiki page on functions has given me a good idea of how to "compile" my function and call it, but hasn't made the syntax of writing my own functions so clear (or maybe I'm missing something). All I know is I can do something like this: // my_fn_hint.sqf comment "Blah, blah, blah..."; _text = _this select 0; hint _text; And then use it, per the directions, in client script. But I'm not understanding how to do more complicated functions that have to return a value, as there is no "return" keyword like I'm used to in C/C++/C# (and of course we can't pop/push memory on the stack, lol). Can anyone illuminate the subject? I really need a clearer picture of function syntax, usage, etc. I've looked at some examples of other people's functions which look nothing like the very basic examples on the Wiki, and it's just confused me even more, lol. 4) Script Execution Questions... I'm also curious about some of the inner workings of the ARMA scripting engine: A) Concurrency: It's my understanding that scripts are executed by the engine concurrently, rather than synchronously. So something like this: nul = ["hello"] execVM "printText.sqf"; nul = ["hi there"] execVM "printText.sqf"; ...as far as I know, the engine will begin executing an instance of printText.sqf when the first execVM line is run. Then it will initiate and run another, totally separate, instance of it when the second execVM runs immediately... it does not wait for the first instance to return control or complete. Right? But this begs the question: How is it done? Does the engine actually run scripts on their own OS thread? And if so, does it take advantage of multiple cores or allow us to control processor affinity? Or does it sort of "simulate" true concurrency through some clever TSS (task-state switching) or cooperative multitasking (e.g., scheduling time slices and yielding control between executing instances)? And one other thing... Are scripts executed with some form of time synchronicity? In other words, let's just say I made a loop like this, that does nothing: while{ true } do { }; Is that loop executed as fast as possible? Or is it run every frame? Or is there something else to it? B) Script "thread" synchronization? I've probably overlooked this, but just thought of it and wanted to ask. How can we synchronize script instances? Let's say I use execVM to spawn two script instances that begin running, and I need them to be synced. Now it's my understanding that execVM returns some sort of "thread handle" you can use for just this purpose, right? But how, exactly? Let's say my "thread handles" are named hThread1 and hThread2. In C#, I might do something like this in the code executing in hThread1: Thread.CurrentThread.Join( hThread2 ); ...to make my code wait for hThread2 to complete. It may be quite important, such as synchronizing access to non-thread-safe variables or waiting for important calculation results. How are such things accomplished in ARMA scripting? And is there a Wiki page or something for this, which I'm sure I've missed? I can accept that in lieu of an explanation. C) Variable instances I still don't have a good grasp on the way variable scope, instancing, etc works in ARMA scripting. Any Wiki page or other resource that can help me? Or do you have some info which could illuminate the subject? Better yet, I'd really love to see a full language specification for the ARMA scripting language and execution engine. It's kind of an "oddball" to me, and unlike anything else I've ever played with, so I still have lots of unanswered questions... 5) External Code / API? For starters, I'm still curious as to whether or not BI has provided us any sort of programming API... a good C or C++ API? A portal to writing our own DLLs to do all sorts of amazing things? Ways to "talk" to the engine, and even accomplish low-level tasks? Well, I don't have my hopes up for such a thing, but just wanted to ask. My curiousity has been peaked after seeing a Wiki page about custom memory allocators/managers. But what exactly is the purpose of it, and what can be done with such a thing? And in the abscence of any kind of true programming API, is there any known "open door" to have the engine load/run external code -- or go so far as to communicate with it (maybe through shared memory or LAN?)? Or is it just completely impossible? Conclusion... Sorry for this being such a long post. But I'll stop there, even though I have a million more questions, heheh. Your time and help is greatly appreciated! Regards, P.S. -- I'm always very hungry to learn more about how the engine and game ticks at the very lowest levels, and appreciate being pointed to any resources which cover such topics. :) -
Not sure what you mean... I get your first remark, but not sure what exactly you're implying in the second. Please explain... We actually can't afford anything as of now. US fiscal policy is a disaster, monetary policy an atrocity. Maintaining our present course we will have a financial meltdown quite soon, the likes of which we've never before seen. But... oil prices will not quadruple because of Iran. NYMEX Crude futures are trading at $99.29/b as of now. So you're basically asking "what if oil goes to $400+/b?" Not going to happen... at least not because of Iran (if it does ever happen, I'm going to liquidate everything -- all my stocks, my car, my home and land, my dog, everything -- to put all on oil futures and I'll just become a billionaire overnight and buy a private island lol). Only the Federal Reserve's dollar destruction campaign could cause such a thing... :o True. And it's our own faults, not Iran... The choice is quite clear... We need to have sweeping, fundamental changes at all levels of government...
-
:cool: <3 lol! What's the location?
-
Really!? :eek: You must tell me where to find them! My squad and I are sore and aching from running around the mountains all day, and want to go chill in a nice poppy field for "relaxation". :D
-
Don't be so hard on him, PuFu. :) I'm not sure what he means by that, but shaders are how everything gets on the screen nowadays, since FFP (Fixed Function Pipeline) has become obsolete. Thanks for the info thus far, and if anyone knows more I'm eager to here it. And thanks, T_D for that link. I made a post to try to get in touch with oktane and bring the discussion of it up again. Regards,
-
Shader discussion [Technical]
ryfle replied to oktane's topic in ARMA 2 & OA : ADDONS - Configs & Scripting
I know this is an old thread, but someone directed me to it after I asked a question about modifying ARMA shaders and adding new shaders. This is a very interesting thread, and deserving of some more of my time. Though I've been up to par with HLSL and ASM for years, I'm relatively new to playing/editing/modding ARMA and don't know much about its inner workings yet. I'm curious, Mr. Oktane, if you're still around and have made any more progress on this front? I'm very interested in finding out more about it. -
Has the US and Europe never supplied weapons and political support to shady organizations, including terrorists? Installed brutal dictators in other countries because they were "US-friendly"? Are we not pouring out billions in "foreign aid" to dictatorships and repressive regimes? Yes, we've done it all and we're still doing it. Meanwhile, we're pointing the finger at everyone else and telling them what to do... :o Ok, so they want to destroy Israel. They've wanted to since day one. But they're obviously incapable of doing it. Egypt and Syria, for instance, tried and epically failed... twice... And these little rag-tag groups of Arab paramilitaries have been trying for ages, and have accomplished virtually nothing. Why do these people hate Israel and want to destroy it? Could it be that Arabs' homelands were taken by western governments to found a new state in their front yard? Yes. And could it be that Israel is aggressive, forceful and uncompromising? Yes. And we pour billions into Israel every year, which they employ in their efforts to kill and terrorize Arabs. So I'm not surprised they've taken up arms against the Israelis (and us). In America we tend to fail at being able to put ourselves in foreign shoes and look at the world from their perspective -- we're stuck inside our ethnocentric box, and can't see the forest through the trees. How would you feel in their shoes? If your home state was seized by foreign governments and turned into a new country that was hostile toward your people, well-armed, well-financed and well-connected? Show me someone who says that wouldn't piss them off and I'll show you someone who's lying. And then it comes down to this... why is Israel our concern? Israel can handle its own business. They've already showed us that, by not only winning wars but through their expertise for their own flavor of espionage, assassination and terrorism. The United States shouldn't be Israel's bodyguard or servant. We're not their tool. Israel needs to handle its own business. Give me one good reason why we should be up Israel's a** and constantly backing everything they do... $400M is chump change in the context of governments. It may seem to be a lot of money for an individual who's not wealthy, but not for a state. I'm not saying Iran is a bunch of "good ol' boys" we should embrace. Just that going to war with them is stupid, as they are a minimal military threat to the US. The Iranian government is a bunch of punks with rotten attitudes, but we're not the world's police. And everything we accuse them of we've also done or are currently doing in a slightly different manner.
-
I've been wondering if implementing or modifying existing shaders is possible. I'd really like to tweak out some of the "default" shaders and potentially add some new ones. For instance, I'd love to change the spotlight shader that is run for things like gun lights, flashlights, vehicle headlights, etc. The thing I don't like about it is that it provides "hard light"... it projects a cone of light value which properly fades/spreads over distance but has hard edges, whereas a real light shining in the dark has falloff towards the edges of the cone. Hopefully you catch my drift... So is this at all feasible, or has it been done/attempted before? Well... of course it's possible, so maybe I should ask if it's possible without RE'ing the game and breaking the rules. And what sort of reception might such a thing have? My above idea seems totally benevolent, but there is a risk of shader modding being used for evil (e.g., rendering transparent bushes/walls or rendering enemies as glowing red objects easy to pick off).
-
I've got a nice little collection here at my fortress. :) AK-47 (Romanian WASR-10 w/ underfolding stock) M-1 Carbine GSG-5 (a 1:1 scale clone of H&K MP-5 in .22LR) Mosin-Nagant (WWII relic) Hungarian Makarov Taurus Millennium .40-auto Marlin 30-30 Mossberg .410 Winchester pump-action .12-gauge Ruger 10-22 RG .22 snub revolver ...and I did have a beautiful hunting/sniper rifle, which got stolen while my brother had it. It was a Mossberg ATR-100 30-0-6 with a very pricey Burris Ballistic Compensation scope (forget the exact model). :'(