wolffy.au

Yeah, probably.

The demo's probably require Combined Arms. I don't believe the MSO code itself requires them, as everything is compiled form the configFile, so it would vary depending on what you have loaded. I have had an editor tell me he got it working on A2 no issues, so I'm pretty sure its possible to work on A2, OA or Combined Arms - but never confirmed it.

So I've continued work on this profiler. I've created two new files, crbprofiler-on.hpp and crbprofiler-off.hpp. I have used mso_core_fnc_profiler as the function name, but you can use whatever you wish. crbprofiler-on.hpp #define CRBPROFILERSTART(name) private ["_profilerid"]; \ _profilerid = ["start",##name] call mso_core_fnc_profiler; #define CRBPROFILERSTOP ["stop",_profilerid] call mso_core_fnc_profiler; crbprofiler-off.hpp #define CRBPROFILERSTART(name) #define CRBPROFILERSTOP These files are preprocessor macros, or shortcuts. This allows me to modify my files with minimal text, to insert the profiler. To make it even simpler, I rename the "active" crbprofiler.hpp so I don't have to change my code everytime. For example: [b]#include <crbprofiler.hpp>[/b] // Code by Tupolov private ["_pos","_radius","_units"]; [b]CRBPROFILERSTART("mso_core_fnc_getUnitsInArea")[/b] _pos = _this select 0; _radius = _this select 1;_units = []; { if(_pos distance _x < _radius) then { _units set [count _units, _x]; }; } forEach allUnits; [b]CRBPROFILERSTOP[/b] _units; The next thing I did was continued improving the Nou caching system. Here are the results of the improvements found by using this method to identify inefficiencies in code. In the graph above, I changed the function Nou Caching triggerUnits to instead of iterating through every unit and check if they're a leader (allUnits), to iterate through every group (allGroups) and check leaders. You can see almost 4x improvement in the speed. When this same system is applied to the MSO, I gained what appear to be substantial improvements, but found it did not equate directly to a Server FPS improvement. The improvement is still identifyable (some players have said its at least 3x faster than the previous version, but the numbers do not correlate exactly for the 5 minutes testing that was performed. The graph below shows % improvement, for example Wild dogs take up 42% less CPU time than they did previously. This image below shows profiling results when applied to MSO 3.40. The FPS Avg & FPS Min are scaled on the left side, while the rest are scaled on the right side. What can be seen is, as max units hit the 330 mark, average server FPS hit around 24, while minimum server FPS averaged about 5 for the duration of the test. In comparison, the image below shows profiling results when applied to MSO 3.41. Again, the FPS Avg & FPS Min are scaled on the left side, while the rest are scaled on the right side. What can be seen is, as max units hit the 30 mark, average server FPS is again around 24 (which appears to be less efficient than 3.40), but the minimum server FPS averages around 8 for the duration of the test. Conclusion: Well, the improvements in the functions appear to be statistcally there but until a more thorough testing is performed on server FPS, I'll have to be satistfied that the perceived improvement is true.

No, this is a release candidate. If it works fine, we can release an ACE version in a day or two.

Yeah, I'm really sorry guys - RL has been killing me. I've uploaded a 3.41 release candidate. AAF and I have been testing it seperately and it appears to be working fine. See here: http://dev-heaven.net/projects/mso/files I've tentatively set v3.41 to be officially released 31 May 2011.

Yeah, its good to go. Will try to do official release tonight! Was hoping to back it with some performance improvement figures, which although look awesome, may not reflect a true performance improvement. Will try for tonight!

Yep, that is exactly what I love about it also! I'm content just to watch the ambient civs drive and fly around, and crash and maim each other! Love it, so rewarding after months of hard work from the team! :bounce3:

Nice work Dave. I'll double check the distances in RMM Enemy Pop and see if what you've done is a better solution. ---------- Post added at 10:59 ---------- Previous post was at 10:20 ---------- I seriously need a volunteer to help update the players guide https://docs.google.com/document/d/1uONmMRBQ3Nc2jEcxinRhZred7wVniAQkZxiYp6e08a0/edit?hl=en_GB&authkey=CNW9s-MO PM me if you're interested!

No unfortunately. Yeah, for sure. We did a quick test last night with the new and improved code. Personally, I didn't see much difference, but the AAF boys (on their speedy server) said it was looking good. I'm going to profile the v3.4 and v3.41 missions, so that I have documented timings and proof that it has made a difference.

Thanks for all the great feedback guys. Well I have excellent news from myself. I've been performance profiling all the scripts and modules in MSO, and I think I've made some great progress. I will try to finish ENEMY tonight (CORE and AMBIENCE are already optimised) and it should be ready for release.

I think the difference highhead, is that I'm making it a module that you just turn on and it works, rather than implementing revive the normal way, where you have to name all your units, modify the revive-init.sqf, put down the gamelogic, etc.

Ok guys - I'm putting a request out for any good coders. I am halfway through making a module of Norrin's Revive, but there is an issue with it using references to player object names instead of just unit objects. If any coders out there want to give it a crack, I'll give them what I have and they can get the credit for making it work! :) Secondly, in the SR5 Reezo's IED Detect thread, its been stated that Ambient bombers does not work on dedicated server. I've merged all that code, but if that is the case, then it is useless for MSO until its fixed. Any volunteers willing to give it a crack? Happy to help anyone who wants to try fixing either of these, with real-time support over Skype chat. PM me if you're interested.

Whoops - wrong thread!

Ahh, interesting. Well, I will need to fix it for MSO, so I'll post back here if/when I do.

I have a new caching system in the next release. We'll reassess and see what the results are. Was hoping to release Sunday past, but as usual there are certain items that are taking longer than expected.

Thanks Knight31. The flags are: White/Black = neutral or not ready Red = a civilian has hurt themselves and they are angry/scared Green = happy! The hatching is: If civilians or BLUFOR spot enemy = RED BLUFOR have "seized" an area (this may not necessarily mean you've killed all OPFOR, just that you outnumber them) = BLUE White hatching just means its unknown.

Yes, NOMAD the module that tracks players keeps all its data in RAM, not disk. Maybe one day.

What is that figure? I have set parameters in the next release to be: 1 recruit per cell per - 15 mins, 30 mins, 1 hr, 2 hrs and 3hrs.

A question for you. I've noticed that if I drive from Loy Manara to Rasman, the search time is never quick enough to put an IED down in front on me. Is this something I can fix from the parameters?

Just a heads up - I've added an SR5 Reezo's IED module to MSO, which I'll release this Sunday. Works beautifully I must say - job well done. I've made some small changes, if they prove to be error-free, I'll let you know.

Yes, performance has significantly dropped in the last month or so. I am testing as we speak and hope to have an update by Sunday. Yeah, there is a test mission that has it. I think its something like: this setVariable ["Construction", true]; this setvariable ["cnstrct_supplies",10000];

I think this is what you're after: http://ace.dev-heaven.net/wagn/Breaking_out_of_the_scheduled_scripting_prison No, the game engine won't loose track of the script. Have a read of the article and let me know if it makes sense. :)

Depending on what you're trying to do, it may work. As stated on the MIP FAQ (http://dev-heaven.net/projects/mip#FAQ):

I have ZoneKillers build module (which is a Construciton variation) and long term I'd like to be able to pack a container or truck with equipment and have the construction module use the contents in its listing. If anyone is interested in pursuing this for me, please let me know.

The difference between the two execution methods is execVM will spawn a process of and continue with the current SQF in parallel. BIS scheduling, as I found out recently is a little broken in that the more parallel processes you run, the worse the performance gets exponentially. The second method will not continue through the existing script until the called script has finished. The allows you to wait for it to complete before trying to give more work to the scheduler. Your second question is a BIS bug I have noticed previously. To get around it, I had to create the unit and then re-add them to the gruop for their side to be correct. I suspect with the future changes of this script, I won't be deleting/recreating units anyway, so it shold go away.