Not only by throwing smokeShell but simply logging on server like Epoch or Wasteland.

confirmed happened to me too. ANNOYING !

I was unfortunately unable to reproduce the issue. Are you running mods by any chance?

Yes and no. EPOCH is mandatory when joining EPOCH servers. But no mod at all when playing on wasteland servers. That doesn't mean, there's no function triggered from server while JIP.

Beyond smokeshell, there are more and more unrecognized classes thru mods and/or servers, which didn't display such error before this version.
Perhaps I'm wrong but I guess several major mods are impacted with weird functionalities which worked before then fail or generate errors now. By chance, there is a "close all" button to continue starting JIP.

At a far lower lever, my personal addon is corrupted since 1.48. I didn't change anything and my addon turns weird while displaying a custom GPS. See: http://feedback.arma3.com/view.php?id=24851 . Why engine is now waiting for display instead of control (if error report makes sense)?

So, Adam, you can wait in a "need more info" attitude, or be proactive and ask in BI team, what changed between versions. Perhaps, YOU (BI) changed something in classes and generated such problems.

Lack of compatibility becomes your (our) major problem. We lost inputAction "adjust" http://feedback.arma3.com/view.php?id=23636, even if you're satisfied to mark it "resolved". It's not resolved at all!

I hope someone could be more explicit than I can, aiming the "smokeShellWhite" problem. But please, think "wider" about how things changed between versions. With little chance, some other class problems could be resolved, btw.
Thanks

You've hit the nail on the head, in my opinion, PiepMGI! BI were informed that the onDrag EH (CT_ListNBox) was broken in the development branch three weeks before the public release of 1.48 and failed to fix it. It is arguably the most important EH for that CT, I know of several missions and modifications that rely on it. Modifications were obviously made to the CT because there are references to them in the changelog, but instead of asking the developer who made the changes to take a quick look and see what could have broken it they decided to simply release the patch with the bug and throw the developers that rely on it into the wind. The development branch is there to avoid these exact issues from occurring. You cannot simply break, to the point of complete failure, previously working commands/features in the development branch and then ignore the reports (or assign them to developers and forget about them) and release them into the public domain. Community developers spend hundreds of hours of their own time developing missions/modifications for Arma 3 and it is completely unacceptable to ruin their work through pure laziness!

If something that was previously working breaks in the development branch then obviously a modification has caused this and it should be fixed BEFORE the public release. Contact the developer that was working on any related issues and ask them to take a look! It's common sense and basic professionalism!

could you please try to switch to Steam Dev and see if the problem is still present?>

You can find how to change to Steam Dev here:
http://forums.bistudio.com/showthread.php?149411-How-to-change-Arma-3-branches-between-STABLE-amp-DEVELOPMENT-versions-STEAM-client

I confirm that "error". Thing is, the script really does what it is supposed to, but that no entry error occurs as soon as I run it for the first time (has lots of iskindof and typeof "smokeshell" in it.. I recognized it on July 28th for the first time. Since Adam´s post is from 21st and there have been several updates inbetween I doubt that it works with the DEV branch - and YES of course ths is part of one of the mods i made

This was caused by the 1.48 update and was addressed in Epoch 0.3.1.0 so this issue should be closed as it is not an Arma issue.

https://github.com/EpochModTeam/Epoch/blob/release/Changelogs/0.3.1.0.txt#L11