OFPEC Forum
Editors Depot - Mission Editing and Scripting => ArmA - Editing/Scripting General => Topic started by: Worldeater on 15 Apr 2009, 06:04:00
-
Maruk added a few words two days ago: http://community.bistudio.com/wiki/ArmA:_Editing#Forward_Compatibility (http://community.bistudio.com/wiki/ArmA:_Editing#Forward_Compatibility)
-
Good catch, looks like some useful info :good:
-
in order to maintain smooth frame rate in real-time content, time limit for all scripts in each frame is enforced by the engine in ArmA 2. Generally speaking, in case of more demanding scripts, be prepared that their result may come way later and also there probably can suffer from significant latency. It is under evaluation if and how possibly allow user scripts to change how much time they may take from the CPU in every frame.
thats looks like something to keep an eye on, hope there sucessfull in keeping it the same as wat we have in arma .
"may come way later and also there probably can suffer from significant latency"
thats pretty damning though, but like the game itself i guess its still a WIP
nice find worleater.
-
I have to say that that is very worrying, since that sort of automatic "idiot-proofing" system is a bad thing in my view. If you have made a mistake in your code that creates an infinite loop then the game should break rather than trying to cope with it and give you a false sense of security. If you have a legitimate reason to have a lot of code running at a certain point, then you should have the freedom to do that rather than being prevented from doing this by "nanny" protection systems like this.
The comments about namespaces are too vague to be really useful to me at least (and I suspect, from what it seems to be implying, that they didn't implement namespaces properly so that we could get rid of the whole OFPEC tag workaround ::) ).
However, I can't tell you just how much I look forward to dereferencing undefined variables becoming a proper error. This alone will save me 100s of hours of debugging time on complex scripts and I can't wait for it!
-
If you have a legitimate reason to have a lot of code running at a certain point, then you should have the freedom to do that rather than being prevented from doing this by "nanny" protection systems like this.
Couldn't agree more. Things like this inevitably go wrong at some point, and stop legitimate scripts from running properly, then other scripts don't run when the CPU is under load from something else, or whatever... it's just going to cause problems left, right and centre. To me, it reeks of a poorly-implemented scripting system... they're just trying to compensate for the inadequacies in how the script interpreter links to the game engine.
I'm pretty sure this'd kill wonderful scripts like Kronzky's Urban Patrol Script. That thing puts some serious burden on the CPU, at certain points, when you have a tonne of AI using it... and now it seems we're just going to get a few seconds of lag whilst the script 'catches up'.
The comments about namespaces are too vague to be really useful to me at least (and I suspect, from what it seems to be implying, that they didn't implement namespaces properly so that we could get rid of the whole OFPEC tag workaround ::) ).
Sounded more to me like they were implementing a solution to the tag system... but I suppose it's not that clear...
The thing that does worry me is that they're "promoting" such small things. It does make me wonder if they've actually made any relevant improvements to the scripting engine, or it's functionality for scripters and mission designers.
However, I can't tell you just how much I look forward to dereferencing undefined variables becoming a proper error. This alone will save me 100s of hours of debugging time on complex scripts and I can't wait for it!
Another "couldn't agree more" moment.
-
in order to maintain smooth frame rate in real-time content
i keep looking at this and wonder if that new MicroAi that isnt scripted and uses its own core is more expensive than its worth in terms of what it costs to have this "real time cotent".
i confess i am not clued up in the mechanics of all this but , ever since i first got aquanted with the FSM system in arma i knew the ai were thick as pig shit under laggy conditions i wonder if this "micro ai system" simply wont operate if the frame rate is poor.
-
I believe that micro-ai is something that can be farmed out to other processor cores, so it is effectively free for many players and all decent servers (since ArmA1 only utilises a single core). In this case, it really won't matter how slow it is ;) Might be misinformed about this though, but I'm pretty sure I read it some months ago...
-
I believe that micro-ai is something that can be farmed out to other processor cores,
well maybe my little bit of sarcasm didn't show in my post , but you make the point i was making, if there is a core method for the micro ai /ai . then why on earth should there be a need to reduce cpu time to scripters ?
this would mean all the other cores are at near to maxed out in the default game ?
-
Oh right. Since I haven't used it (Arma2), though, I can't really say that it is a bad thing.