Bug #9590

post initialization processing

Added by MrCaptainBravo about 5 years ago. Updated over 4 years ago.

Status:Closed Start date:03/13/2010
Priority:High Due date:
Assignee:Sickboy % Done:

100%

Category:XEH
Target version:v0.4.0
Component:extended_eventhandlers Affected Version:88
Close Reason:

Description

An issue have been having after v1.0: "*post initialization processing*" screen that seems to go on for ever before mission start.

It happens sometimes when you add units in editor, mission goes through loading screen then another screen comes: post initialization processing and it goes on forever where you have to shut down arma.

Is this a known bug? Again, I am only using ACE units and CBA.

extended_eventhandlers.pbo (52.9 kB) Sickboy, 03/24/2010 22:19


Related issues

related to Community Base Addons - Feature #8392: Add loadingscreen to pause simulation/time, and process d... Closed 01/22/2010

Associated revisions

Revision 5046670b
Added by Sickboy about 5 years ago

~ Changed: Removed delayLess processing from initPosts, they are covered by the loading screen anyway. fixes #9590. Endless loadscreen.

Revision 5046670b
Added by Sickboy about 5 years ago

~ Changed: Removed delayLess processing from initPosts, they are covered by the loading screen anyway. fixes #9590. Endless loadscreen.

History

Updated by BTK about 5 years ago

Hello,
this happend to me too sometimes. But only if the mission has errors.

Check your RPT file to solve the mission errors which are causing this.

This always solved it for me. But it sucks anyway if you haven't saved your mission before!

Updated by Sickboy about 5 years ago

If you could make some examples of how you broke it, and how you fixed it, we can probably work around it.
RPT/specific messages could be useful.

Updated by Sickboy about 5 years ago

  • Target version deleted (1.0.0)

Updated by rocko about 5 years ago

  • Category set to Script
  • Target version set to 395

Updated by mr.g-c about 5 years ago

Just Had the same Problem.... its indeed a bug in a mission script whats causing this. RPT full of errors of my crappy scripting when this issue occurs.
However is there no workaround as indeed you have to restart your Arma2 which really is bad.

Updated by rocko about 5 years ago

  • Target version changed from 395 to 1.2

Updated by Sickboy about 5 years ago

We use already:

    [] spawn
    {
        private["_time2Wait"];
        _time2Wait = diag_ticktime + 10;
        waituntil {diag_ticktime > _time2Wait};
        endLoadingScreen;
    };

But this does not seem to work properly.

Your rpt would've been useful.

Are you using XEH in your description.ext, or what condition does the bug occur exactly in?

Updated by Sickboy about 5 years ago

  • Status changed from New to Assigned
  • Assignee set to Sickboy
  • Priority changed from Normal to High
  • Component set to cba

Updated by MrCaptainBravo about 5 years ago

Personally, I am not using anything. Just a bunch of plain ACE2 units in editor. It usually happens when you add/remove units to map. It used to happen perhaps 50% of the time in editor.

This happens with any plain mission I am making in editor.

I can get an rpt when it happens next.

The only observation I have which might help (or not)is it used to happen 50% of the time for me, now only 25% of the time if use GL4 with ACE2. GL4 has some initialization of its own and maybe that has something to do with it?? Just an observation.

Updated by Sickboy about 5 years ago

Hm. The loading screen should stay maximum for 10 seconds, while usually much shorter.

Does the attached PBO resolve or have any effect on the problem? (Belongs in @CBA\Addons)
(please backup your the current file)

Updated by MrCaptainBravo about 5 years ago

It seems the extended_eventhandlers.pbo has resolved the issue based on limited testing.Will test more this weekend in editor and mp. But so far so good (knock on wood!)

Updated by Sickboy about 5 years ago

  • Project changed from A.C.E. for OA to Community Base Addons
  • Category deleted (Script)
  • Target version deleted (1.2)

Updated by Sickboy about 5 years ago

  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 100

Updated by Sickboy about 5 years ago

  • Category set to XEH
  • Target version set to v0.4.0
  • % Done changed from 100 to 80
  • Component changed from cba to extended_eventhandlers
  • Affected Version changed from 1.0 to 88

Updated by Sickboy almost 5 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 80 to 100

No news is good news I suppose :D

Updated by MrCaptainBravo almost 5 years ago

Update: After heavy testing, I have not had any issues with the initialisation after I have installed the extended_eventhandlers.pbo by sickboy. That seems to have fixed the issue for me and a couple of other people who were having same issue. I would imagin everyone else with same issue will benefit from this update.

Thanks for the quick fix! :)

Updated by Sickboy almost 5 years ago

No worries, glad it's resolved!
The fix has been included in the official ongoing development of CBA (available on the Six Updater network).
Will prime for a new CBA official patch release in next days.

Updated by Gnat over 4 years ago

Hmmm .... now I'm getting this error.
Calling some sqf scripts from the INIT field of an addon. Starts to load then this message stays up forever.
Got XEH loaded (whole CBA mod folder) but this particular doesn't use XEH/CBA

Updated by Sickboy over 4 years ago

Gnat wrote:

Hmmm .... now I'm getting this error.
Calling some sqf scripts from the INIT field of an addon. Starts to load then this message stays up forever.
Got XEH loaded (whole CBA mod folder) but this particular doesn't use XEH/CBA

My first guess would be the usage of sleep or waitUntil, or an endless loop, used directly inside or called from an Init (/client/server) EH (either on a vehicle, or as InitOnce), if hanging is at the loading screen, it should be in a PostInit.
All XEH eventhandlers behave like ordinary eventhandlers when it comes to 'suspending not allowed in this context', however during postInit this is simulated, rather than Engine provided, which is the only real difference.
You could either use spawn/execVM or perhaps adjust the script logic so that waitUntil/sleep isn't required; PostInits are executed from a spawn, running the code after the unit has fully initialized.
If non of the above applies, perhaps you've ran into a XEH/CBA bug; it would be useful to be able to review the code to reproduce the problem etc.

Ah, I just noticed you were speaking of an addon that doesn't use XEH, but native EventHandlers?
If that's the case and there is no situation as described above with another loaded addon, then perhaps you have either directly or called, a while/for loop which would halt the engine and process until either done or 10.000 iterations have passed, at which it will abort the loop.

Also available in: Atom PDF