Hello

I recently installed FreeDroid Dialog Node Mapper and it crashed when I tried to
render some files to PNG:

* Chandra
* Spencer
* TutorialTom

I also tried to render Chandra on dot format but it also crashed.
Console output: “Segmentation Fault (core dumped)”

FDDNM "MUST" be built locally.
Please see: http://www.freedroid.org/doxygen/tools/fddnm.html
in FD doxygen page for instructions to build.

Note dialog node actions/behaviour has been made more complex with Dev's writing
more involved code for user actions. This makes a rendering tool such as FDNNM
difficult to maintain.

I will verify fault and if possible offer a fix, but no promises.

Observations so far...
Changes:
2016Apr19 - Fluzz made minor change to accommodate data directory changes.
2015Apr03 - Me - bug fix to regex and add other flags to command line
2015Mar04 - Me - initial release

Errors/Discrepancies:
Doxygen page - link to diagrams broken
Building - observations
- first execution of autogen_fddnm.sh produces numerous warnings about
overwriting m4 files (ax_boost_{base,filesystem,program_options,system}.m4,
ax_cxx_compile_stdcxx_11.m4)
- autogen fails at ax_require_defined.m4 with "too many loops" errors
- second execution produces successful configuration.

Execution:
Chandra works (attached using fddnm -Tpng -G -H Chandra).
Output of Chandra attached.

Spencer and TutorialTom results in segmentation fault.
Tested fddnm with both gcc and clang

Made several attempts executing Spencer.lua dialog file.
With fddnm built with heightened debug mode, I was able to parse Spencer.
However, it was apparent that nodes were missing. Another debugging method
employed was to use Lua comment block markers to isolate which node(s) were
problematic(fddnm would fail with a segmentation fault).

General problem...
Dialog nodes with involved if/elseif/else structures or compound if clauses will
cause the fddnm to fail.
fddnm is structured using regular expressions to find "consistent patterns" in
the dialog files and go from there.
As dialog complexity has increased, defining a regex pattern for every
conceivable use case in the dialog files is not supportable.

Parsing dialog code and produce a graphical output was a "nice idea". However,
without resorting to something like boost::spirit or bison/yacc, I do not feel
fddnm will be able to handle all use cases going forward.

Recommend removal of fddnm from source tree.
RB to follow.

Yes, I had similar problems in past with compound if clauses...

Maybe you're right and fddnm is not up anymore to the whole task, however, I do
not think it is necessary to remove from source tree, if you can prevent the
segmentation fault (probably using try:except statements) and skip such files
printing to console “file x cannot be rendered.”

After all, fddnm have its uses. Specially testing new dialog submissions...

If you edit Spencer dialog and use lua block comments taking out everything
after about node 52, FDDNM works fine. I did quite a bit of this block
commenting to narrow down problematic nodes.

What doesn't help are line like:
    hide("nodeX") show("nodeY")

I don't think the lua interpreter appreciates those two commands on the same
line and the behaviour IMO is undefined. Probably the hide command gets executed
but the show command -- maybe.

FDDNM was never meant to be a syntax checker for lua. If the code is bad, FDDNM
will fail - period. The segmentation fault is not always because of it's code.
Sure the error handling could be better, but I still make no promises in parsing
bad code.