Scripting Rant

[xx-Cougar-xx 0]

I know a few scripting languages, back in the day I wrote the GTF's for Ghost Recon and released a mod called "Evolution" , I also did work on an UT2K4 Conversion, to bring Atari's BattleZone game to the Unreal Engine, I am also currently involved in a project making a new game Engine.

When my teammates came accross this game, I was hoping to pump out a few missions, heck it is advertised to have it's own mission editor, so for the last few days I have been tooling around to see what it can do.

The Information is scattered accross every part of the Web, conflicting with each other, even on the Wiki, an example is camCreate, it has a global Icon, but yet in the additional info, under multiplayer it says it is only Local. Some of the Multiplayer information say Unknown!

The whole Local and server determination on a mission level is obscene, when an engine has a function(called command here), it should be predetermined that it is a server or client.

The mission maker should never have to check "isServer". Something like making a vehicle should only be a server side event, triggers that are global but lose their args? Nuts!

Then testing, they have a preview, but it only works for some of the functions? You have to start a MP server to really test....DUH that means you should have had a seperate Gui app in the first place to edit, and create.Then I started to think of making my own GUI App to create missions, but I would still have to do all the testing and figure out the mombo jumbo of information out there.

It really seems as though they just added to the OFP eng, where as they should have takin some of the functions and adopted it into core eng (prob c++), rather than in the lang they devolped, this would also result in faster execution, cpu ticks etc, they should have also takin care of alittle more of the work, rather than leave it to the mission devs.

In short:

My hat goes off to the people who write missions in this game, you must spend hours upon hours testing and rewriting , just to get something a little more complicated than the editor can provide to work...a luxury I do not have.

[[frl]myke 14]

hmm...and the question is?

Sorry, but i can't follow this post? You know a few scripting languages and have problems with scripting? Well, i know not a single scripting language except ArmA's, and my scripts usually works very well.

Quote[/b] ]The mission maker should never have to check "isServer".

Well, the "Mission maker" hasn't to check if isServer or not, but the scripter has to. Depending on what a script is intended to do, it has to be run on ClientsOnly, ServerOnly or both. So you have to chekc if the actual machine IS the Server or just a Client. Or do you want all scripts running on all machines, regardless what they're doin?

Quote[/b] ]Then testing, they have a preview, but it only works for some of the functions?

The only function that doesn't work in Preview is the respawn afaik...correct me if i'm wrong.

Quote[/b] ]My hat goes off to the people who write missions in this game, you must spend hours upon hours testing and rewriting , just to get something a little more complicated than the editor can provide to work...a luxury I do not have.

You don't have the time for creating Missions for ArmA? Then i would say, for you and the community it seems to be a win-win situation.

[xx-Cougar-xx 0]

there was no question (that's why it's called a rant dumbas*), and if i had the time i could do it...

the point was that BI should have better tools and info...

and i take my hat off to those that work with this lang....

why you flaming with the "win win " comment, just wanted to commend the people who work in this lang and you gotta go be a JO.

[Jester_UK 0]

What's missing regarding scripting in ArmA is a single easy to follow manual that takes a user from the absolute basics to the more complex levels in a single logical path.

The OP comments on there being masses of information available on the net, but that the available information is badly laid out and at times contradictary in nature.... And speaking as someone that's been trying to get into scripting and mission building since buying ArmA when it was released in the UK, I agree with him 100%.

ArmA has a very flexible and powerful mission editor thanks to the user being given direct access to the scripting language.... But without giving those new to scripting the right guidance it's useless, apart from to a select few who are naturally gifted with coding and have previous experience of code writing.

I'll bet that if BIS released a comprehensive manual that went from the absolute basics upwards, and did so in clear and easy to follow language it would sell in large numbers, thus boosting their income...... And the community would benefit greatly from the work produced by those who are at present unable to get the results they want in ArmA, but who with the right guidance would be capable of producing extremely good missions.

[[frl]myke 14]

@xx-Cougar-xx

my first post was to harsh, i apologize for that and ask you to forgive me. It wans't my attention to flame on you.

What i coldn't understand was, i'm far away from being a really smart guy with knowledge of any scripting/programming language, therefor i couldn't understand how someone with scripting/programming knowledge would have problems with the ArmA scripting language.

And to another point: indeed, i spent a lot of time ti finish a Mission but i guess 20% of the time goes off for scripting issues. Most of the time i spent on balancing the mission so it's might be hard, but not impossible to fulfill it.

Also there's a lot of "ready-to-use" scripts all around. But i apologize, they are sometimes hard to find. Maybe pointing you at www.ofpec.com and www.armaholic.com could change your opinion about it.

I also agree as the documentation is...well, let's say "minimalistic". But there's a great community, everytime willing to help (you might have seen my other post in your other thread) and this is IMHO really priceless.

Once again, i'm sorry for my first post, no intention to start a flamewar or something similar.

Myke out.

[fasad 1]

I really think a dev provided list of the required locality of arguments and the effects is the most needed addition to the wiki. Finding these out by trial and error is very laborious, and the wiki had (the last time i compared) less info on this than the old OFP lists created by the guys at OFPEC and CoC.

[misinformed 0]

I don't think you'll get much argument from most people that go that little bit further to provide additional elements to maps in that most things, especially in an mp environment are very time consuming to get right. For the most part i keep finding myself doing new things that ive never done before at almost every turn. From synced, server client weather and time, to custom actions, UI's and AI and approaching more highly random and replayable missions in mp. And ive been at this, well since the UK release. Having initially started with OPF.

Luckily theres a lot of other people at this as well, and chances are if your stuck they will at least have an idea of what your trying to do or point you in the direction of a completed script you can use, as long of course as you do give credit where credits due.

And the quicker you get a basic working knowledge of locality going the better off you'll be. Few things ill just chuck your way, you probably know this all ready.

Gamelogics are local to the server/host.

The player is local to the client, obviously.

A vehicle is local to its driver, if unoccupied is local to the server.

AI is local to its leader. So that would be the server in most cases unless a player was the leader.

Triggers are global/is a global space.

Some commands in themselves have global effect, even if they are executed locally. Ie Createvehicle being a good example.

Createvehiclelocal obviously will only create something local to where its executed and will not show up on any other clients.

Publicvariables are quite powerful in that they are broadcast over a network, but have to be re issued if changed, so they can be broadcast again. Ie west=true; Publicvariable "west"; west=false; Publicvariable "west";

[xx-Cougar-xx 0]

@myke np

it's not that I have problems, it's not that you need to be smart, it is that you shouldn't have to go through all the BS to make a mission for a game, the editor is laxed, I started two days ago and already need to write my own scripts, you should have a better tool to script. It is only a mission, not an application. The lang is powerful, and wide open, but they did leave to much out of the core, there should be no way for a mission dev to have to worry about if he is going to spawn a unit/object/event for each player on the server or if it is only going to be seen by one as an effect, the core should handle that, then you should have a function with options for the choice you desire, one unit/object/event, or an effect for one player, this being an param of each function.

[ArmaVidz 0]

Without user-made content ArmA would sell even less than it already has. A fine example of user-made content increasing sales is the video by Dslyexci. One can only imagine the intrigue and sales it generated.

I myself have been told over YT that a person bought ArmA because of my video and the possibilities-three times; none of which could have been achieved without the help of the community and forums.

Dev's assisting the community with documentation is paramount if they want to sell even more, not to mention those that bought the title would be even happier with their purchase aka will buy the expansion packs.

You really can't forgo the bottom line: money. Money is the key motivator in all things that reside in what I call 'reality.'

[fer 21]

Stuff

I'm sorry you have had such a frustrating time. If you really want to 'pump out a few missions', then can I point you towards BAS f (link in my sig below)? This won't generate missions, but it should help you focus on mission development, rather than hunting for scripting knowledge on the web. It also has a 60-page manual (available in Russian too), which whilst not a replacement for a decent 'HOWTO' for scripting in SQF, should still help you.

[UNN 0]

Quote[/b] ]It really seems as though they just added to the OFP eng, where as they should have takin some of the functions and adopted it into core eng (prob c++), rather than in the lang they devolped, this would also result in faster execution, cpu ticks etc, they should have also takin care of alittle more of the work, rather than leave it to the mission devs.

Out of curiosity, which do you think would be easier to learn for someone who has never done any programing before. C++ or the Arma\OFP script language?

P.S You would'nt by any chance, have been previously banned from these forums?

[mtlgd 0]

I feel your pain Cougar. I just discovered that, if your testing a script and die, if you select play again, some of your scripts may still be running from the first instance. Rather confusing to say the least.

[Homer Johnston 0]

More flexibility = more complicated... too bad--what you may hate, someone else may have been able to utilize to their advantage.

For example, I would be pissed if making stuff on client vs. server was forced by the game engine. The reason OFP/ArmA is awesome, is because they left a lot of stuff open-ended, such as that. Smart mission makers are able to take advantage of the freedom and produce amazing things. If you're not one of those people, then... too bad (I'm not one either)

If you can't learn it, then maybe making "interesting" missions isn't for you... but the majority of it isn't too hard, it just takes time.

I do agree that BIS would do well for their community, to spend one day going through the scripting commands in the wiki and filling stuff out. Sucks being on our own there  

In the end, you'd have been better off asking a few questions in the editing forum, then telling everyone "I CAN'T LEARN THIS!" ... many people already have, and instead of helping you, now they're just asking themselves "sheesh, what's wrong with him?"

[baddo 0]

Quote[/b] ]It really seems as though they just added to the OFP eng, where as they should have takin some of the functions and adopted it into core eng (prob c++), rather than in the lang they devolped, this would also result in faster execution, cpu ticks etc, they should have also takin care of alittle more of the work, rather than leave it to the mission devs.

Out of curiosity, which do you think would be easier to learn for someone who has never done any programing before. C++ or the Arma\OFP script language?

P.S You would'nt by any chance, have been previously banned from these forums?

It is certainly the BIS programmers he means who should have put more functionality directly into the game engine itself, rather than left implemented in the scripting side. So this means, user scripters would not need to know anything about C++. He is saying things that need to be done by the mission designers, could have been implemented directly into the game engine. I am neither against or for his opinion.

This is a flexibility versus ease-of-use question. As it is now, we have more freedom. But it is harder to use for the basic stuff, especially as the documentation given to us by BIS is appalling, as I see it.

Maybe one way to tackle the locality problem could be to put the scripting engine do things by default more like what xx-Cougar-xx is saying. In my mind this could mean that for example all vehicle creation would have to be done from the server and the client would not have a word in that. The clients could not create anything by default. Then a mission designer could change this behaviour if he wants by setting a server-side variable like allowCreateFromClient = true; in a mission initialization file. Then a createVehicle command would work from any computer in the session, but not before. This could even have some effect into the 'cheats' in which some very stupid and immature people spawn vehicles as they wish into multiplayer sessions.

I think what we would need from BIS regarding documentation, would be a scripting reference and a manual. But not in the Wiki! In a Wiki there are always people who are going to "fix what are errors in their opinion", and the trustfulness of the information is thus compromised. I would gladly take a scripting reference and a manual, two separate documents, from BIS, in for example Portable Document Format (PDF). The task of making a scripting reference and a manual has been left to the community by BIS, which is a disappointing move from BIS in my opinion. I hope it changes some day.

[benreeper 0]

I must say this. My first foray into modding was the unreal engine. They all said it was easy. Well it probably is easier for people who are already programmers but OFP is far easier for non-programmers. I did not understand the concepts with UT (games/scripting of this ilk). It was foreign to me.

In using OFP sqs what could be easier for a novice than:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">object do this

It's clear and simple. It's not as efficient and streamline as OOP but for people who do not know what OOP is it makes sense. It's like writing a sentence and everyone can do that.

BIS could (should) clear up some scripting mysteries but in no way is making a mission/map whatever in UT is easier than mission making in ArmA.

--Ben

[xx-Cougar-xx 0]

Quote[/b] ]It really seems as though they just added to the OFP eng, where as they should have takin some of the functions and adopted it into core eng (prob c++), rather than in the lang they devolped, this would also result in faster execution, cpu ticks etc, they should have also takin care of alittle more of the work, rather than leave it to the mission devs.

Out of curiosity, which do you think would be easier to learn for someone who has never done any programing before. C++ or the Arma\OFP script language?

P.S You would'nt by any chance, have been previously banned from these forums?

It is certainly the BIS programmers he means who should have put more functionality directly into the game engine itself, rather than left implemented in the scripting side. So this means, user scripters would not need to know anything about C++. He is saying things that need to be done by the mission designers, could have been implemented directly into the game engine. I am neither against or for his opinion.

This is a flexibility versus ease-of-use question. As it is now, we have more freedom. But it is harder to use for the basic stuff, especially as the documentation given to us by BIS is appalling, as I see it.

Maybe one way to tackle the locality problem could be to put the scripting engine do things by default more like what xx-Cougar-xx is saying. In my mind this could mean that for example all vehicle creation would have to be done from the server and the client would not have a word in that. The clients could not create anything by default. Then a mission designer could change this behaviour if he wants by setting a server-side variable like allowCreateFromClient = true; in a mission initialization file. Then a createVehicle command would work from any computer in the session, but not before. This could even have some effect into the 'cheats' in which some very stupid and immature people spawn vehicles as they wish into multiplayer sessions.

I think what we would need from BIS regarding documentation, would be a scripting reference and a manual. But not in the Wiki! In a Wiki there are always people who are going to "fix what are errors in their opinion", and the trustfulness of the information is thus compromised. I would gladly take a scripting reference and a manual, two separate documents, from BIS, in for example Portable Document Format (PDF). The task of making a scripting reference and a manual has been left to the community by BIS, which is a disappointing move from BIS in my opinion. I hope it changes some day.

finally someone who understands what i am saying

[zaphod 0]

i agree that there are just a few problems caused by the fact that commands like setpos, createvehicle, setdammage ... can be executed by a client in a MP game.

requesting these things at the server side script (for example with an implemented tx/rx set by scripting language! instead of publicvars this time..) might be the better solution avoiding most cheats and console actions...

[ArMoGaDoN 0]

@Zaphod - very much in agreement re: tx/rx, some level of encryption/encoding in that could be useful as well, and to compliment that we need basic string-handling/slicing to really help us secure stuff from our side of the scripting equation.

[zaphod 0]

i implemented a tx/rx solution and request my actions from client to serverside script with it (done in berzerk map pack v2.0 coming soon)...

so dont need this support affected by client side setpos / createvehicle actions to the network. as it still works for cheated scripts and console actions makes it senseless, yes, but so far i can use it to control deletevehicle / respawn actions for my point.

a suggestion might be leaving the current states implemented in the sqs parser .... and develop the sqf parser to a higher server based level. or copy the sqf parser to something new like sqx, and leave sqf as it is an develop sqx to that point, using same syntax with MP limitations.... but who nows what's best...

[Young Eagle 0]

What's missing regarding scripting in ArmA is a single easy to follow manual that takes a user from the absolute basics to the more complex levels in a single logical path.

The OP comments on there being masses of information available on the net, but that the available information is badly laid out and at times contradictary in nature.... And speaking as someone that's been trying to get into scripting and mission building since buying ArmA when it was released in the UK, I agree with him 100%.

ArmA has a very flexible and powerful mission editor thanks to the user being given direct access to the scripting language.... But without giving those new to scripting the right guidance it's useless, apart from to a select few who are naturally gifted with coding and have previous experience of code writing.

I'll bet that if BIS released a comprehensive manual that went from the absolute basics upwards, and did so in clear and easy to follow language it would sell in large numbers, thus boosting their income...... And the community would benefit greatly from the work produced by those who are at present unable to get the results they want in ArmA, but who with the right guidance would be capable of producing extremely good missions.

well said!