Jump to content
Sign in to follow this  
Maio

Arma 3: Confirmed features | info & discussion

Recommended Posts

You'll have to forgive me but,,,just so I know what all the hype is about, am i correct in thinking that Java will

a.Be an easier scripting language to use (once learned)

b.Has some sort of handy debug function

c. Be much less taxing performance wise w/ alot of scripts running?

If I am correct in all these at least, then I can have smething to be excited about :)

Share this post


Link to post
Share on other sites
a.Be an easier scripting language to use (once learned)

I don't think it will be easier to learn for a beginner, but once you've figured out what object oriented programming is good for, you will never want to go back. ;)

b.Has some sort of handy debug function

As stated by the devs, you can actually start writing scripts in a proper IDE like Eclipse, which will give you better debugging possibilities, yes. :)

c. Be much less taxing performance wise w/ alot of scripts running?

Yup, apparently the performance improvements on larger scripts is massive.

Share this post


Link to post
Share on other sites

I might be biased because I know C++ and it has plenty of functionality but...

I think Java is the easiest to learn of the three most popular (C++, C# and Java). It was a language for webpages. Never heard anyone say Java and optimized in one sentence so this raises my brow. VBS used C++ apps afaik.

C++ has plenty of libraries and performance is proven. C# is more platform specific (which is not an issue) and from what I have heard mixes the functionality of other two and is easy to get into. I have only used C# for simple things in the past and it did seems slightly simpler compared to C++ but it did not have some features like recurrence.

You can do object oriented programming in all three.

Share this post


Link to post
Share on other sites

I thought we were comparing Java to SQF here. :confused:

Where do C++ or C# come into that?

Share this post


Link to post
Share on other sites
I thought we were comparing Java to SQF here. :confused:

Where do C++ or C# come into that?

VBS2 has hooks for C++.

also: when discussing something you do look at alternatives.

Share this post


Link to post
Share on other sites
Apparently not as much as you suck at reading, considering I said nothing about Arma 2. But you could have just as easily informed me that such an obvious flaw that most certainly DID exist in both OFP and Armed Assault had been fixed.

But I suppose responding to me like somebody half your age would is also appropriate considering your ability to read is about on-par.

:yay:

Funnily enough i posted an arma1 vid 2 posts down my first post which shows the exact same thing. :yay:

Anyway the choice for java is interesting (As in, why Java over some type of C), i wonder how that is going to work in practice.

Edited by NeMeSiS

Share this post


Link to post
Share on other sites

okay, how about performance, I know nothing about arma code, how much is scripted, missions, configs, AI? Would it have any impact on overall performance?

Share this post


Link to post
Share on other sites

Java sounds really cool from the bench, especially because it is scripting language that is NOT limited to BIS games (lots of free resources and examples around the net), but as panda said, i feel it is a bit weird to choose java over other languages(object oriented that is). Anyhow, until one can actually see it in use, i cannot comment further.

okay, how about performance, I know nothing about arma code, how much is scripted, missions, configs, AI? Would it have any impact on overall performance?

Not really no, it shouldn't

there could be improvements for missions and mods running a lot of scripts at the same time. But that it's about it. I would NOT be expecting additional performance improvements in any case.

ps: configs and the AI will most likely have nothing to do with java.

Edited by PuFu

Share this post


Link to post
Share on other sites
Not really no, it shouldn't

there could be improvements for missions and mods running a lot of scripts at the same time. But that it's about it. I would NOT be expecting additional performance improvements in any case.

It's too early to even speculate, the only information so far that we have from DnA is "Using generally much higher performance script execution".

We don't have any ingame comparison points between the two, besides the above, like the speed of completion on a large number of certain operations (hint, hint, whip up some quick test cases BIS!), etc. But we'll be able to test it soon on TakeOn and come up with meaningful numbers.

While certainly, Java might be a strange choice to us at this point where we have no insight on BIS's reasoning and it does not have a reputation for being super fast compared to some other languages, in my opinion we can't yet rule out or prove that it's faster than the SQF/SQS, aside from the information we've got to go on.

Share this post


Link to post
Share on other sites
While certainly, Java might be a strange choice to us at this point where we have no insight on BIS's reasoning and it does not have a reputation for being super fast compared to some other languages, ...

Sounds like a nice topic for the developers blog. :)

Share this post


Link to post
Share on other sites

i wasn't really speculating, i was following some sort logic, and as i said, there is few any one of us could say about it until we can actually get to test it

* java will be used as a programming language, working side by side with sqf/sqs - at least for TKOH, for A3, sqf/sqs might actually get dumped in favour of the (then) native one - java

* cfgs and alike would be still in the current format (.cpp/.hpp) together with the xmls from TOKH.

* the sqs/sqf does NOT dictate how vanilla AI works.

Surely, the AI behavior can be improved via scripts (sqf or fsm). The great advantage over other engines is that AI actually works by itself, without actually needing to puppet master it

all in all, as i previously said, i see no real reason for improved performance for normal missions (warfare, domination evolution and other public and popular missions that have a lot of scripts running at the same time, thing might improve drastically).

call me pesimistic if you want. Don't take this the wrong way, i really think this move makes a lot of sense, congratz for BUS are in order.

Share this post


Link to post
Share on other sites
i wasn't really speculating, i was following some sort logic, and as i said, there is few any one of us could say about it until we can actually get to test it

* java will be used as a programming language, working side by side with sqf/sqs - at least for TKOH, for A3, sqf/sqs might actually get dumped in favour of the (then) native one - java

* cfgs and alike would be still in the current format (.cpp/.hpp) together with the xmls from TOKH.

* the sqs/sqf does NOT dictate how vanilla AI works.

Surely, the AI behavior can be improved via scripts (sqf or fsm). The great advantage over other engines is that AI actually works by itself, without actually needing to puppet master it

all in all, as i previously said, i see no real reason for improved performance for normal missions (warfare, domination evolution and other public and popular missions that have a lot of scripts running at the same time, thing might improve drastically).

call me pesimistic if you want. Don't take this the wrong way, i really think this move makes a lot of sense, congratz for BUS are in order.

I think you might have misunderstood me, I was only expanding on the point of speed of execution compared to SQF/SQS. :)

I can agree with your logic for cfg's, AI, etc.

Share this post


Link to post
Share on other sites

Would it be realistic to expect dynamic loading of cfgs along this Java addition to the engine? (addition which I welcome BTW)

I might be wrong here, but AFAIK only cfgs (and related assets) are loaded when the executable launches... I stumbled onto the need to have this possibility after launching and relaunching the mods I was developing/testing on over and over again, which was slightly cumbersome.

I mentioned this before in another context.

Share this post


Link to post
Share on other sites

I have watched a video from czech GDS, there wasn't much about A3

- no rivers - they tried but the but they wont add them because they still can't make them nice enough, but there almost no rivers on limnos

Share this post


Link to post
Share on other sites
I have watched a video from czech GDS, there wasn't much about A3

- no rivers - they tried but the but they wont add them because they still can't make them nice enough, but there almost no rivers on limnos

Can you show us the video on the internet or was only cause you were there in person?

Share this post


Link to post
Share on other sites
Hi fellow scripters,

...

Why is this awesomeâ„¢?

I will tell everyone why this is awesome; because (as Marek points out two posts down) Arma3 should be able to run any code that compiles to run on the JVM. The code doesn't HAVE to be written in Java, it just has to compile to Java bytecode. There are languages that are much easier to learn and use than Java that still compile to run on the JVM.

I'm thinking of getting TOH just to test this, but if I can get Groovy code (http://groovy.codehaus.org) working with TOH then I know what my first programming project for Arma3 will be: to rock the Arma3 programming world... (ok, that may be a bit grandiose, but that is my goal).

With Groovy creating a "Domain Specific Language" (DSL) is almost trivial. For those not familiar with the term, think of a DSL as a mini progamming language designed for a specific task (domain), in this case writing Arma3 missions. Give me a weekend (or two...) and I can come up with a DSL for Arma3 that will make it trivial for non-programmers to write Arma3 scripts. For example, imagine being able to define triggers with something like:

trigger(id:'all-players-dead') {
when {
	all playableUnits are dead
}
}

trigger(id:'all-players-in-target') {
when {
	all playableUnits areIn 'target-zone'
}
}

game_state {
activatedBy('all-players-dead')
action {
	fail mission
}
}
game_state {
activatedBy('all-players-in-target')
action {
	win mission
}
}

I can get that (or something close to it) to compile and run in a JVM with not much effort; I just need the Arma3 Java API to make it actually do something. Give me a bit more time and you'll get syntax highlighting, content completion, and inline documentation in your favorite IDE as well.

Compare that to

{_x in thisList} count units playableUnits == {alive _x} count units playableUnits

NOTES

  • The above code is just an example of what might be possible. Any Java programmer that spent a bit of time with Groovy could do much the same thing.
  • I am making assumptions based on BIS's use of the trademarked name "Java". Either those assumptions are correct or BIS is going to get their ass sued off by Oracle (owners of the trademark, who defend it vigorously).

Share this post


Link to post
Share on other sites
Funnily enough i posted an arma1 vid 2 posts down my first post which shows the exact same thing. :yay:

Anyway the choice for java is interesting (As in, why Java over some type of C), i wonder how that is going to work in practice.

That is not the experience I've had.

Too many times now I have advanced toward heavy cover, my own vision completely obstructed, completely unable to see what lies ahead only to have bullets flying out from the other side and kill me.

It doesn't matter what kind of AI it is, the simple fact of the matter is that a BMP shouldn't be able to see though bushes much less hear footfalls, especially if its idling with a loud diesel engine.

In all of those circumstances the AI had not previously spotted me.

I'm not saying that in some circumstances the aforementioned doesn't apply, since I've had incidents where the AI didn't see me when it should have, however it seems to me that there are some significant inconsistencies regarding what effectively blocks AI sight and what doesn't.

All I'm saying is that there are newer games out there now that have done a much better job calculating realistic visual obscurity for AI.

Yeah, I'm totally sure you'd see them before they saw you.

This is precisely what needs to be changed, this isn't realistic, this is ridiculous.

Edited by Burnov

Share this post


Link to post
Share on other sites
I will tell everyone why this is awesome; because (as Marek points out two posts down) Arma3 should be able to run any code that compiles to run on the JVM. The code doesn't HAVE to be written in Java, it just has to compile to Java bytecode. There are languages that are much easier to learn and use than Java that still compile to run on the JVM.

I'm thinking of getting TOH just to test this, but if I can get Groovy code (http://groovy.codehaus.org) working with TOH then I know what my first programming project for Arma3 will be: to rock the Arma3 programming world... (ok, that may be a bit grandiose, but that is my goal).

With Groovy creating a "Domain Specific Language" (DSL) is almost trivial. For those not familiar with the term, think of a DSL as a mini progamming language designed for a specific task (domain), in this case writing Arma3 missions. Give me a weekend (or two...) and I can come up with a DSL for Arma3 that will make it trivial for non-programmers to write Arma3 scripts. For example, imagine being able to define triggers with something like:

trigger(id:'all-players-dead') {
when {
	all playableUnits are dead
}
}

trigger(id:'all-players-in-target') {
when {
	all playableUnits areIn 'target-zone'
}
}

game_state {
activatedBy('all-players-dead')
action {
	fail mission
}
}
game_state {
activatedBy('all-players-in-target')
action {
	win mission
}
}

I can get that (or something close to it) to compile and run in a JVM with not much effort; I just need the Arma3 Java API to make it actually do something. Give me a bit more time and you'll get syntax highlighting, content completion, and inline documentation in your favorite IDE as well.

Compare that to

{_x in thisList} count units playableUnits == {alive _x} count units playableUnits

NOTES

  • The above code is just an example of what might be possible. Any Java programmer that spent a bit of time with Groovy could do much the same thing.
  • I am making assumptions based on BIS's use of the trademarked name "Java". Either those assumptions are correct or BIS is going to get their ass sued off by Oracle (owners of the trademark, who defend it vigorously).

OMG, if you do this...:bounce3::bounce3::bounce3::bounce3: :yay::yay::yay::) Edit: BI can you please confirm if this is indeed possible?

Share this post


Link to post
Share on other sites
The above code is just an example of what might be possible.

I'm not really seeing how that's an improvement over SQF? It's basically exactly the same as SQF as far as I can tell, just a different syntax. Your comparison isn't even valid since your "so easy" pseudo code doesn't check for alive vs dead as the SQF does. :)

Share this post


Link to post
Share on other sites
BI can you please confirm if this is indeed possible?

I don't know how familiar the BI staff are with Groovy, but what I posted is a valid Groovy program. Groovy code compiles to Java bytecode and can be mixed in with Java code just like any other external library (jar file in Java lingo). In fact you can mix Groovy and Java code together in the same project. So something like the above should be possible.

I bought TOH just so I could I try this out. Unfortunately, I misread the announcement and patch 1.03 != Patch 3, the patch that will contain the scripting enhancements... and I don't even really like helicopter sims... DOH

I'm not really seeing how that's an improvement over SQF?

The only real improvement over SQF is it gets rid of that horrible (to me anyway) infix syntax. So you write

fadeMusic 4, 0
// or
fadeMusic(4,0)
// instead of
4 fadeMusic 0

However, the idea isn't to improve on SQF, the idea is to improve on Java. Java is a very verbose language and you have to do alot of typing to get not much done. While a good IDE can automate much of the process, it's still alot of grunt work. I suspect that non-Java programmers that have spent years honing their SQF skills won't like all the extra typing.

Something like this would allow people experienced with SQF to jump on the Java bandwagon without having to learn Java.

Edited by Slapstick
spelling

Share this post


Link to post
Share on other sites

@ Slapstick

They said the next patch (1.04) is planned to have it in.

Share this post


Link to post
Share on other sites
Can you take anything from this image (from the holidays banner)?

Only that the scuba guy is awesomely detailed. Beautiful. :D

Oh, and it's interesting that the flippers seem to bend realistically so that they wouldn't clip through the floor. Could be an example of improved physical interactions between objects and the world.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

×