Don't think the game itself is buggy..its the scripting

[BeerHunter 0]

I haven't played the campaign (started but it fell apart quickly) but have been playing strictly custom made scenarios and through the editor.

So far I haven't come across any "game breaking" bugs. Sure there are SOME coding errors and the entire thing seems it could use some optimizing , but for the most part , all the "bugs" I ran into while attempting the campaign appeared to be nothing more than scripting errors.

Completing an assignment without actually doing anything? Must have activated a trigger somewhere that didn't bother to check whether or not I had actually done what I was supposed to do.

Doing something a little out of the ordinary? Confused the script as whoever wrote it didn't bother to error check or verify parameters so the script simply carried on through.

I've been studying the scripting language trying to make sense out of it (it seems to defy all the known standards for a programming language such as C++,Basic,JAVA etc.) and have the feeling that the "scripting language" has become a white elephant , outdated and barely capable of handling the requirements of module developers for ArmA2.

I can be learned,that I know , as I did manage to learn C++ and C# after years of Basic and JAVA , but it's akin to trying to learn Mandarin after studying French and English.

Easy enough to see how logic errors could creep into the script undetected , which leads me to the conclusion that the vast majority of the "bugs" players are complaining about are scripting errors , not the actual game code.

Correct me if I'm wrong...:D

[EDcase 87]

I agree but its a very complex system and so free for the player that its very hard to cater for every possible problem that might come up.

[Langnasen 10]

Sounds about right.

[dmarkwick 261]

You can't really compare scripting to coding, in the same way you cannot compare printing to drawing. C++ et al are all fairly low-level languages whereas any kind of scripting is a structured high-level language of compound commands parsed INTO the actual engine. It's clunky, but then so is every scripting language compared to low level language. What it also is however is easy to visualise and implement. Relatively ;)

As far as bugs vs scripting goes, I would say that errors in scripting represent bugs ;)

Edited October 13, 2009 by DMarkwick

[KeyCat 131]

My personal guess is that there are code/script/config/3D model bugs/issues (minor and major!) that needs attention and I'm sure BIS are working on them.

/KC

[CarlGustaffa 4]

You normally don't run into that many scripting/mission design bugs in your own missions, since you play them out as intended. Give the mission to someone else, and a whole new world of bugs usually appears :)

[Herbal Influence 10]

You normally don't run into that many scripting/mission design bugs in your own missions, since you play them out as intended. Give the mission to someone else, and a whole new world of bugs usually appears :)

Yeah - that's so true.

Once I had a boss and we had to broadcast messages at a weekly routine to more than a 300 "intellectuals".

He said then said unto me: :D

We have to read our messages six times before sending for you can be sure that

1. if there is a possibility to misunderstand something, about a 10 % will chose this possibility and blame us hard for writing "rubbish" :o and, worst of all,

2. they will never allow you to state the fact that 90 % of the receivers understood it correctly.

Was a lesson to me for the effect took place also after reading it six times before sending. Sure a little less but ... seems like some of "Murphy's laws".

Herewith I don't wanna critizise people claiming to have found bugs, but to show how immensely difficult it is to adress a big heterogene community with a complex message ("mission").

[Trapper 0]

For sure it's the scripting. When you know about OFPEC you'll have seen the big boards over there which mostly cover mission editing, scripting and beta testing.

Even most of the new hardcoded features like obstacle climbing, first aid actions, conversation options totally look like being based on scripting to me. Maybe that sounds like a contradiction with the word hardcoded but that's how I would describe it.

Using that features in the engine doesn't really "feel" new. It feels like playing with top notch custom OFP addons that use heavy scripting.

EDIT: Ok, thinking about the automatic bounding over watch of AIs in combat mode, that does feel new and not like scripting I would understand.

The same goes for the campaign. The original OFP and even Resistance focused on missions of small scripting complexity like "Delaying the bear" now. The fun and immersion was supposed to be generated by the still new open battlefield game.

Now in Harvest Red almost every mission includes massive scripting, like only a few and best custom OFP single player missions did before. And this is necessary to present a special forces campaign in an engine which without scripting is only able to simulate cold war like skirmishes of combined arms (symmetric warfare) by now.

Those big custom OFP missions spent months to almost a year in beta testing on the OFPEC boards before being called final. I don't believe that a closed and pushed mission testing of BI with few participants can beat that. Although they could have known that.

Edited October 14, 2009 by Trapper

[wamingo 1]

Scripts are meant to be used where circumstances changes often so you don't need to recompile.

The steerable parachute must be one of the best example of inefficient scripting implementation. Clearly such a thing ought to be hardcoded.. into.. every.. parachute. (where applicable)

There's no way you can possibly polish that thing in a script. It feels like a hack. And it probably is.

I love arma2 and it's miles ahead of everything else, but most of what arma2 has that is good is hardcoded. The modules and such... leaves a lot to be desired. The medic/carrying system especially is really cool, but oh so unreliable.

[Second 0]

I've been studying the scripting language trying to make sense out of it (it seems to defy all the known standards for a programming language such as C++,Basic,JAVA etc.) and have the feeling that the "scripting language" has become a white elephant , outdated and barely capable of handling the requirements of module developers for ArmA2.

Correct me if I'm wrong...:D

I disagree somewhat. It's easy grasp by mundane mind. I've "coded" with C-64 bit less 20 years ago, then i got lazy. By OFP i started to learn scripting and in year or so i was able to create pretty complicated scripts, not pretty or cpu friendly, but things which altered gameplay experience some deal. Info was there and language's basics were easy to learn. So even if it's bad in coding standards then again it's easy to understand with zero background (at least i think it is) and that means you have much bigger masses which starts to mod things and eventually someones (more the merrier) will publish something innovative and new, someone (more the merrier) will look into it and things gets more polished and thought out in the process. As a result you then will have SLX and it's kinds.

That is what i think, right or wrong. I don't know.

Yeah. I was talking about modding with that. Overall i think that missions should be as script free as possible. It will just makes mission more strange. Extreme examples could be scripts affecting AI behavior, vehicle performance, kit restrictions etc. Scripting which runs mission are naturally okay, if missions haven't been overcomplicated by use of scirpting. Keep it simple stupid, as the saying goes. I prefer plain and simple triggers which forces me to keep mission structure simple, but that doesn't make me pro at making missions.

Edited October 14, 2009 by Second