ACE3 - A collaborative merger between AGM, CSE, and ACE

[jonpas 289]

Hi Jaynus,

Sorry I'm not trying to be a dick or anything but I can't work out from your github page where the "Thou Shall Nots" are.

I checked here:

https://github.com/acemod/ACE3

But it wasn't apparent where they were to me. (not familiar with GH format).

I ask as an indy code guy. I'd like to make sure what I'm doing doesn't break the work of others etc.

Thanks.

http://acemod.github.io/ACE3/wiki/index.html

[das attorney 857]

http://acemod.github.io/ACE3/wiki/index.html

Ah cool thanks.

I'll give that a good look over.

EDIT:

Actually,

From that link, I still have no clue as to what they think is important to execute instantly or queue up in the scheduler or w/e so nvm, I'll work it out from here. But thanks for the linky anyway. :)

Edited April 11, 2015 by Das Attorney

[jonpas 289]

As much as I know, this is the page that describes that: http://acemod.github.io/ACE3/wiki/dev/arma-3-scheduler-and-our-practices.html

I don't know of anything more about scheduler handling, one of the Core Devs will have to tell more.

[Takoda 10]

From what i've tested so far... The ragdolls seem to fall the exact same way per pose. Kinda... idk, in Vanilla Arma 3 the ragdolls seem to go down depending on where you shoot them and it's always different.

This hasn't been the case for me. In Vanilla Arma3 I found that the ragdoll would often fall into this common pose where both the knees were up in the air and the upper body was twisted to one side, for example I could shoot a dozen guys from in front and they would all fall into the exact same pose, and they would often fall into this exact same pose even if they were blown down by an explosion. It was really annoying seeing this same ragdoll pose over and over. I will try and post some videos soon to highlight the differences.

[das attorney 857]

As much as I know, this is the page that describes that: http://acemod.github.io/ACE3/wiki/dev/arma-3-scheduler-and-our-practices.html

I don't know of anything more about scheduler handling, one of the Core Devs will have to tell more.

No, that's totally cool for linking me there.

Thanks man.

As far as I can tell, it's saying "don't be a dick" when it comes to scripting, which is fair enough.

It's easy to fuck other peoples shit up by hogging the scheduler, so from what I can see, ACE are against that and with good reason. What I was really interested in is ACE asking for no spawn (which I use due to timing some scripts). I guess I could use an FSM to check for a timeout, but I can't think of another way to run delays/sleeps off the top of my head.

"Thou Shall Nots" in the code (spawn, execvm, non-pfh, etc)

[noubernou 77]

No, that's totally cool for linking me there.

Thanks man.

As far as I can tell, it's saying "don't be a dick" when it comes to scripting, which is fair enough.

It's easy to fuck other peoples shit up by hogging the scheduler, so from what I can see, ACE are against that and with good reason. What I was really interested in is ACE asking for no spawn (which I use due to timing some scripts). I guess I could use an FSM to check for a timeout, but I can't think of another way to run delays/sleeps off the top of my head.

PFHs work just as well for that. Just do something like...

_fnc = { _time = _this select 0; if(time >= _time) then { doWhatever; [_this select 1] call cba_fnc_removePerFrameHandler; }; };
[_fnc, 0, time+30] call cba_fnc_addPerFrameHandler;

This will check every frame if time is greater than or equal to the time you passed in, execute whatever, then remove the PFH.

[Jastreb 69]

Where can we get an up to date documentation about modules? The one present is from AGM it seems. I am a bit confused with medical system setup. Is this CSE inherit, cause its not AGM medical as it seems.

About translations. Does that include only officially supported languages by game itself or we can add just any language there?

edit:

This seems to be a CMS from CSE reworked and cluttered. To put it short you would probably want two modules, advanced and basic, or even three, advanced , medium and basic, where only one can be active at the time, where advanced will have those advanced things that are planned, medium has bandage, epi and morphine, and basic would be basic revive module. Ie FAK heals, Medkit revives, uncon time, number of lives, anyone or just medics. ATM its quite confusing, even though it works for the most part.

What happened to repair module? I want to be able to change tires and tank gasoline. Its gone? Logistics too.

Edited April 11, 2015 by _MaSSive

[-PzGrenBrig37-commy2 10]

What happened to repair module? I want to be able to change tires and tank gasoline. Its gone? Logistics too.

It's not done yet.

[Takoda 10]

Some footage of the improved ACE3 ragdoll physics in comparison to the vanilla ragdoll -

https://www.youtube.com/watch?v=vrQgo4Q7sn4

https://www.youtube.com/watch?v=q1axDHhbA28

https://www.youtube.com/watch?v=Edm4yJAu6Vc

https://www.youtube.com/watch?v=0zuvKkm00TU

[das attorney 857]

PFHs work just as well for that. Just do something like...

_fnc = { _time = _this select 0; if(time >= _time) then { doWhatever; [_this select 1] call cba_fnc_removePerFrameHandler; }; };
[_fnc, 0, time+30] call cba_fnc_addPerFrameHandler;

This will check every frame if time is greater than or equal to the time you passed in, execute whatever, then remove the PFH.

Cool ok, from what you're saying (or I'm hearing), then it's a new scheduling system?

So if I've got scripts to introduce in an ACE compatible way, then I use the cba_fnc_addPerFrameHandler framework for handling delay, and then my scripted stuff and ACE should play nice?

(Pls let me know if correct or bollocks. Interested in how you guys are working stuff out and would like to make what I'm doing work with what you're doing) :)

[noubernou 77]

Basically by using a per-frame handler you are guaranteeing when things will execute, and that when you execute code in it, it will execute all the way through before the next frame is processed.

That being said, it is blocking the next frame from rendering, so you need to take performance into consideration a lot more than if you were using spawn/execVM, where the execution is performed over potentially multiple frames.

The reason ACE tries to do everything in the PFH/non-scheduled realm is because we want to leave the scheduler open for everyone else and NOT be affected by it ourselves.

[naizarak 4]

from what i read and pieced together in the wiki, the problem with running code in a scheduled environment is that "sleep x" is not a reliable metric. the game engine runs in frames, not seconds. using real time as your timing standard in intensive code execution will fail when the server comes under heavy load and begins to lag to the point of distorting time. if im not mistaken, under heavy load in-game time will in fact slow down behind real time.

also from what i've pieced together, the entire scheduling environment is shared equally between scripts. spawning too much code will overload it and lead to peformance problems, which is why everything should be called by default unless absolutely necessary

this low-level stuff is interesting but i feel there's a lack of documentation, particularly regarding CBA's functionality. its wiki hasn't been updated in years. hopefully someone decides to address that at some point...

[das attorney 857]

Basically by using a per-frame handler you are guaranteeing when things will execute, and that when you execute code in it, it will execute all the way through before the next frame is processed.

That being said, it is blocking the next frame from rendering, so you need to take performance into consideration a lot more than if you were using spawn/execVM, where the execution is performed over potentially multiple frames.

The reason ACE tries to do everything in the PFH/non-scheduled realm is because we want to leave the scheduler open for everyone else and NOT be affected by it ourselves.

No that's totally cool man. I think I see what you guys are doing and agree. :)

I hope that it could become the defacto frame handler for scripting and stop race conditions from happening.

Am I talking shit or on the right tracks?

[james2464 176]

Awesome ragdoll physics! Nice work ACE team :D

[noubernou 77]

No that's totally cool man. I think I see what you guys are doing and agree. :)

I hope that it could become the defacto frame handler for scripting and stop race conditions from happening.

Am I talking shit or on the right tracks?

Not so much race conditions (though they can occur in the scheduler) but guaranteeing execution. The entire PFH concept came because of ACRE in A2. We needed super accurate, guaranteed results every frame to do positional audio and the scheduler would lag behind execution in heavy scripting environments, because the scheduler only allows 3ms of SQF execution per-frame before it stops and continues rendering the frame, and the scheduler can get greedy, new calls to spawn/execVM get priority, push old code down, persistent loops, sleeps, etc, begin to lag out. So this is a way to make sure we execute code when we want and for as long as we want.

[Jastreb 69]

commy2;2918404']It's not done yet.

Fair enough. I almost forgot its alpha.

:: patient bear ::

PS: Lot better physxâ„¢

[das attorney 857]

Not so much race conditions (though they can occur in the scheduler) but guaranteeing execution. The entire PFH concept came because of ACRE in A2. We needed super accurate, guaranteed results every frame to do positional audio and the scheduler would lag behind execution in heavy scripting environments, because the scheduler only allows 3ms of SQF execution per-frame before it stops and continues rendering the frame, and the scheduler can get greedy, new calls to spawn/execVM get priority, push old code down, persistent loops, sleeps, etc, begin to lag out. So this is a way to make sure we execute code when we want and for as long as we want.

Very cool :)

So then everything in it's scope (on a per-frame basis) is protected from other users doing their scheduled things?

Edited April 11, 2015 by Das Attorney

[b00ce 160]

The year is 2035, I'm pretty certain that by this point the nightvision technology would have evolved significantly to rid of just such inconveniences as having to constantly adjust the focus on the goggles. Not shooting down the idea, but it wouldn't seem logical to base the nightvision effects on outdated equipment functionality.

However, I'll be more than happy to shoot you down. ;) In the real life; noise, clarity and the amount of amplification are the primary differences between the generations. I find it hard to believe that in the future there will be an auto-focus for NVGs, currently (With even the latest generation of goggles) you need to manually focus to a certain range by twisting the objective and eyepiece lenses. For there to be an auto-focus system, you would need to add a LOT of weight for the moving bits, computer chips and whatnot. I don't know if you guys have ever worn nightvision goggles, but they get heavy (especially if you have a weight bag on the back of your helmet to counter the goggles) even though they're essentially aluminum tubes with glass lenses sandwiching three platters of light-weight electronic bits and some fiber-optic shenanigans. Practically speaking, it would be cost and weight prohibitive. NVGs are already straining on your poor eyeballs, I can't even begin to imagine what an auto-focus would do... Especially if you're in a confined space with windows (like an aircraft), auto-focus would get confused and switch between close and far away.

Imagine walking around with the screen of a camera an inch from your face and auto-focus constantly changing, trying to tell you what to look at. I don't know long y'all have used NVGs, but I've got a little over 60 hours using them (The fancy military aviation ones to boot) and the mere thought of an auto-focus makes my eyes bleed.:j:

What would be awesome is having an effect similar to BWmods scopes that would have a proper DoF effect that started about 50 meters and got blurrier as it got closer (including your weapon).

[CaptainObvious 95]

hence the gen1,2,3 models of nvgs

I don't think gen1 devices are being used even today, not to mention 20 years from now, correct me if I'm wrong.

[Takoda 10]

Some more ragdoll physics testing. You guys have really done an outstanding job.

https://www.youtube.com/watch?v=Y-dfUwnsqGg&feature=youtu.be

[CaptainObvious 95]

Nice one! What happens when you open the door that has a corpse lying against it? Will the corpse tumble over, i.e will the ragdoll "stay alive"?

[enex 11]

Takoda thanks for making videos, truly amazing when ace team eliminated twitch effect when person get shot.

Edited April 11, 2015 by enex

[laxemann 1673]

I'm actually learning shittons just from the wiki and the source code.

Thanks for that! :)

[EnigmaticallyEerie 10]

However, I'll be more than happy to shoot you down. ;) In the real life; noise, clarity and the amount of amplification are the primary differences between the generations. I find it hard to believe that in the future there will be an auto-focus for NVGs, currently (With even the latest generation of goggles) you need to manually focus to a certain range by twisting the objective and eyepiece lenses. For there to be an auto-focus system, you would need to add a LOT of weight for the moving bits, computer chips and whatnot. I don't know if you guys have ever worn nightvision goggles, but they get heavy (especially if you have a weight bag on the back of your helmet to counter the goggles) even though they're essentially aluminum tubes with glass lenses sandwiching three platters of light-weight electronic bits and some fiber-optic shenanigans. Practically speaking, it would be cost and weight prohibitive. NVGs are already straining on your poor eyeballs, I can't even begin to imagine what an auto-focus would do... Especially if you're in a confined space with windows (like an aircraft), auto-focus would get confused and switch between close and far away.

Imagine walking around with the screen of a camera an inch from your face and auto-focus constantly changing, trying to tell you what to look at. I don't know long y'all have used NVGs, but I've got a little over 60 hours using them (The fancy military aviation ones to boot) and the mere thought of an auto-focus makes my eyes bleed.:j:

What would be awesome is having an effect similar to BWmods scopes that would have a proper DoF effect that started about 50 meters and got blurrier as it got closer (including your weapon).

Um, I'm not sure if YOU'RE aware but we already have cameras that operate by automatically adjusting focus and recording. They're by Go-pro and work rather wonderfully in capturing clear imagery. Honestly, we already have the tech that can commit to auto focus. Hell, my cell phone camera auto focuses, and seems to do quite well in identifying glass. If you're not aware of these small technologies, maybe you need to rethink your attempt of 'shooting down' my minor post of auto-focus.

PS - We already have auto adjusting nightvision goggles. - http://www.staples.ca/en/Night-Owl-Optics-5X-Nexgen-Night-Vision-Binocular-with-50-Mm-Lens/product_1491656_2-CA_1_20001?kpid=1491656&cid=PS:SBD:GS:n:n:SBD:58:21800&kpid=1491656&gclid=CjwKEAjwjKOpBRChjsTyicbFy3QSJADP1gTNdVENFbyuNKi5MBwfl28HCFXLf5HM7XcjkoT-jZZNtBoC3x3w_wcB

So I guess I just shot you down. GG - get good at arguements, and maybe get some facts before you bother speaking.

Edited April 11, 2015 by EnigmaticallyEerie

[soulis6 24]

Some more ragdoll physics testing. You guys have really done an outstanding job.

https://www.youtube.com/watch?v=Y-dfUwnsqGg&feature=youtu.be

Cool stuff!

off topic, what is that other map? the second one. Really cool looking