After playing around with the next generation of winbuilder and following this discussion its time for my feedback!
Obviously alot of work and though has been put into the new version. I appreciate the native handling of .zip, .wim and shortcut files something that has always been an issue in the previous generation...
processing speed is nice and quick. under 1min on my duo core laptop with 8gb ram and SSD! using wim XPRESS compression speed was atrocious though taking 30min to compress a 200mb wim file no wonder LZX wasn't included as a compression option in the default project. it will be interesting to see what build times are like once scripts start being added to make the PE useful.
I don't mind the command line myself, but one of the big draws winbuilder had on me over my days working with the bartPE/ubcd4win team was the nice GUI interface for tweaking script settings. the html settings offer some nice flexibility but I believe if the new generation of winbuilder is to become successful its going to need to evolve into something easier for novices to build with. plenty of time for that though...
beanshell scripting seems nice at first glance. way more powerful and mostly removing the need for calling cmd line programs or homebrewed batches/autoit scripts to process things the previous generation had issues with.
all in all a favorable first impression.... now, on to the suggestions!
lack of a proper log file. cmd window output isn't telling much of a story for developers looking to debug a build. this will become an issue in the future.
my biggest gripe at the moment is the complete lack of documentation for anything. a wiki should be top priority. even as the engine evolves this will allow us to keep syntax up to date. as of now nobody knows how or why winbuilder works and if anyone is going to start working on new scripts or porting old favorites proper documentation on how winbuilder thinks is a must!
my other suggestion is a proper bug tracker/request/roadmap. lets not make the same mistakes as the past and shut the community out of the evolution process. after all we are the ones using and developing projects & scripts for the darn thing and ultimately responsible for its future success/failure. keep us in the loop and able to suggest and track bugs and requests. this will not only encourage interaction between .script and engine developers, but also keep engine developers accountable to the community. I would very much like to avoid past issues where "its my way is the only right way" from people on either side of the fence. proper communication tools are a must and forum discussion only covers part of this process.
final words. keep up the good work. I'm looking forward to seeing this evolve.