DFHack
build-now crashes DF when building roads
paved roads usually (but not absolutely always) cause a heap corruption exception shortly after the road is built, when something else (most likely not related) attempts to free memory. the cases where a crash did not immediately arise involved roads with only one item in their construction. the crash only occurs reliably when running on true windows; in wine the crash does not arise, which could be because wine's heap manager is less strict, or because the crash is due to a wild write which happens to hit a heap management structure with ntdll's implementation but hits something else in wine. the crashes sometimes occur immediately, sometimes a tick later, and sometimes some time later even while the game is paused
also unpaved roads, while not causing a crash, simply disappear when forced with build-now instead of being "built"
Reports also of windmills causing this issue, strengthening the multi-item connection
Another report: don't know if this has been mentioned, but build-now works sometimes, but will crash the game shortly later if you build screwpumps. also when building walls, the tile above it will become "deconstructed". if the tile was a natural block, building a wall where it was then deconstructing it will make any natural terrain reappear. wasn't sure where to put this but i figured it's good to know for people wanting to use the command until it's re-done
it did even after the major realignments we did last week. i haven't tested it again since then but i don't think there's been any changes that are pertinent
i do remember testing windmills and finding that while it "successfully" builds the windmill (in that the game does not crash and something that appears to be a windmill appears in the world), the windmill's machine components are not properly initialized and the built windmill does not work as a windmill. this is probably also true for all other buildings that have machine components. in this case, it's because build-now doesn't call machine_handlerst::machine_handlerst_anon_vmethod_0 or otherwise initialize the building's machine_info pointer
i'm not at all confident that we can reliably implement build_now without either imposing a recurring reverse-engineering burden to ensure that nothing in the "finalize construction" function (currently at 1403a2a00, about 1800 lines decompiled) has changed (and thus our reconstruction of what that function does is correct), or alternatively using RE techniques with each new version to locate this function in each new release and make it callable. ideally we'd talk bay12 into virtualizing this method so we can find it with RTTI, but until them we have to choose between having a method that is unreliable and potentially dangerous (especially whenever df changes) or a method that simply doesn't work after a release until the necessary RE work is done
ok. I'll keep it tagged "untested" for now and I'll add that method to the list in our "vtable wishlist" (edit: yeah it's already there, with a link to the gist you posted)