This is still WIP.
The difference at this point is only the format of the size attribute which I changed in 6f063bdb1c316d31d108d2d609de36a0e4461db5.
But in a few minutes I'll be pushing more changes, which for instance add support for drawing velocity and acceleration data as colors in the shader.

This is not a feature. Particles are simply ignoring the modifier options when doing the lattice computation. Disabling the lattice modifier should stop it from having any effect on anything on that object.

Oh yeah, forgot to close. There are still some possible optimizations, but it is all working, so this is finished.

2fed99ad9f1a

My bad, fixed a7388d650a8

Added ensure BM dvert, and rebased.

Fixed one last corner case where the draw cache wasn't updated (different object with same mesh).

Fixed all crashes and memleaks. Weight cache invalidation is a bit hacky, but is the simplest way to do it for now, and can be changed later.

Added all drawing options (Wire, shading, face mask and vert mask), did some minor style fixes, and added support for the custom weight color setting (debatable usefulness).

Ok, indeed there is something wrong with texture handling when emitting from verts, but the texture coordinates seem to be doing fine. Without looking at the code, I think the color of the first emitted hair is just being applied to all hairs, but the I see nothing wrong with the texture coordinates.
I'll take a look at this.

Are you talking about the direction the hairs point to? If so, yes, that is the intended behavior, as hairs are emitted in the normal direction of the emitter, be it a face or vert or whatnot.
I am not sure how this is related to texture coordinates, could you clarify?

This is not a bug, but rather just the way Blender was designed.

Ok, this makes sense. So we actually have a horrible case of misnaming, lacking documentation, and terrible code design.
I can look for a better way to handle this in the code at some point (when I start working on particles), but for now, I think it is a matter of fixing the docs. (And maybe coming up with a better name, as the field does not introduce any kind of "boyd behavior", but rather influences existing boyds particles...)

I didn't look at boids.c, but since the code in do_physical_effector does nothing, and pdDoEffectors has no special case handling for boid (no calls to boids.c stuff), I can only see this force field being a noop.

I really don't think this is the way to go about this. There is no point in slightly increasing the limit, as you can just as well find the new limit to be too low at some point in the future. I would be for keeping the 50 limit, but replacing it with a soft limit, that way, new users don't accidentally freeze their sims, but you are free to increase the the segments to whatever you want.

No idea why this stayed open so long...

I have completely removed Bullet's plNearestPoints from the new cloth collision system in the cloth-improvements branch. I have instead implemented a brand new and more reliable function, tailored specifically for the new collision response system.

Hey, glad to hear that you are using cloth. All the development in that regard is happening in the cloth-improvements branch: https://developer.blender.org/diffusion/B/browse/cloth-improvements/

Hey, that is an odd behavior you are getting. No parameters changed between 2.76 and 2.78. The UI was just reorganized a bit, and the speed multiplier and dynamic base mesh features were added, but all the parameters are still the same.

It seems that @ronan ducluzeau (zeauro) clarified the issue, and that there is no bug here after all. Closing.

Like @Alex (SpectreFirst) said, the issue is the scale. Particle distribution is calculated in local coordinates, thus distribution will be off when the object is scaled unevenly in global space. Applying the scale fixes the issue.
No bug here, closing.

Like @ronan ducluzeau (zeauro) said, each object can only be one smoke type. Switching between types will reset the settings.
This is expected behavior, so no bug here. Closing.

Yes, that fixed it. Thanks @Brecht Van Lommel (brecht) :)
Just for reference, I'm running Arch with OpenBox.

Hey @Brecht Van Lommel (brecht), something did indeed break, hehe.
For me Blender is segfaulting on startup (linux). Here is an asan log:

=================================================================
==15131==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f4392681d36 bp 0x7ffc21efaa80 sp 0x7ffc21efa1f8 T0)
    #0 0x7f4392681d35 in strlen (/usr/lib/libc.so.6+0x81d35)
    #1 0x7f4397ecbe3b in __interceptor_strlen /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cc:577
    #2 0x7f4393633b34  (/usr/lib/libX11.so.6+0x48b34)
    #3 0x7f4393634e8a in XrmGetStringDatabase (/usr/lib/libX11.so.6+0x49e8a)
    #4 0x4ab41bf in GHOST_WindowX11::getDPIHint() /home/luca/Blender/blender/intern/ghost/intern/GHOST_WindowX11.cpp:1686
    #5 0x4a97d3b in GHOST_GetDPIHint /home/luca/Blender/blender/intern/ghost/intern/GHOST_C-api.cpp:920
    #6 0x1f1388d in wm_window_set_dpi /home/luca/Blender/blender/source/blender/windowmanager/intern/wm_window.c:380
    #7 0x1f144a8 in wm_window_ghostwindow_add /home/luca/Blender/blender/source/blender/windowmanager/intern/wm_window.c:486
    #8 0x1f149d6 in wm_window_ghostwindows_ensure /home/luca/Blender/blender/source/blender/windowmanager/intern/wm_window.c:565
    #9 0x1eb1128 in WM_check /home/luca/Blender/blender/source/blender/windowmanager/intern/wm.c:395
    #10 0x1ed8cd4 in wm_homefile_read /home/luca/Blender/blender/source/blender/windowmanager/intern/wm_files.c:834
    #11 0x1ee36ac in WM_init /home/luca/Blender/blender/source/blender/windowmanager/intern/wm_init_exit.c:195
    #12 0x1ea7786 in main /home/luca/Blender/blender/source/creator/creator.c:431
    #13 0x7f4392620510 in __libc_start_main (/usr/lib/libc.so.6+0x20510)
    #14 0x1ea6f49 in _start (/home/luca/Blender/build_linux_debug/bin/blender+0x1ea6f49)

Just a little update to fix a blenderplayer linking error, and a minor UI issue.
I'll be committing as soon as I get around to writing docs for this...