Sorry, hijacking a thread about EQLive for a moment.
A interesting quote from a person (Elidroth) who lurks these forums about custom content generation:
Both the zone editor, and scripting tools are readily available if you're willing to buy them.
Zone Editor - 3DS Max. Currently $3,675 from Autodesk.
Script/NPC Tools - Microsoft Office (Access actually). Currently $399 from Microsoft.
I also use Textpad as my text editor, which cost me $27.
Making content for EQ is not as simple as people seem to think it is.
I'm not sure if you're trying to tell people that it's difficult for a specific corporate reason, but it's really not from a technical perspective.
-Zone Editor - 3DS Max. Currently $3,675 from Autodesk:
This I can understand if it's all geometry/textures/pathing files you are talking about being generated. It's quite overpriced - BUT, in the context of your quote, people are asking to submit content to SOE. Legally, it shouldn't matter where they get their version of 3DS Max as long as you provide the methods to get their content in the game. SOE can even hold the keys to generation if you're scared of people hacking zone geometry. EQEMu has been having the option for people to hack zone geometry for years on the emulator and nothing bad has happened, though. If it does, oh well, we call send_message on entering a zone and send data with a crc16 of the zonefile like you guys do with spells/client exe/skillcaps/basedata.
-Script/NPC Tools - Microsoft Office (Access actually). Currently $399 from Microsoft:
I understand EQ is a very large game and that systems may not be optimal for making a second NPC scripting system/NPC database.. but at what point do those systems become impractical for rapid content development and why hasn't moving to a new backend system instead of Access been done sooner? Surely it's not impossible as we recently moved from Perl to LUA on PEQ, and still have support for both. You could have some zones loaded with MySQL and some loaded with Access if you needed to.
Though, Microsoft Access seems like the worst possible choice for scripting when compared to SQL Server/Oracle/MariaDB/MySQL combined with Perl/LUA/Python. Using EQEmulator's base, we are able to make a pre-existing zone's geometry into an entirely new instance with its own mechanics, quest scripts, and NPCs in a matter of minutes, not days, and it certainly doesn't cost any money and the possibilities are endless on what can be done. Why wasn't that identified as a bottleneck sooner, or considered a legacy feature of the server code like S3D was depricated on the client when you guys made the move to EQG?
I can almost guarantee if I had the clientside source/database portions to EQ that I could implement an EQEmulator server that runs on the data in a matter of weeks/months using the data provided. If the code is an issue, why not just take EQEmulator's features from their github and use them in SOE's codebase? After all, you'd only have to contribute code back of what you've changed due to GPL, and it could only benefit the emulator and SOE - and the end goal, the players.
Hell, I'd go as far as to write an EQEmu-style quest editor inside the EQ client if I were you guys. You could set it up so that a very limited permissions-wise perl parser could be embedded into the server and parsed from the client's side. There's countless ways to approach this but I am curious as to why SOE is sticking away from the idea of player-made content - unless, of course, they are betting on EQNext and developers have no say in the matter.
-Textpad, $27:
Notepad++ Home<-- free & almost everyone uses it, has tons of plugin support. I'm sure everyone has their reasons but I am genuinely curious as to why you are using Textpad compared to NPP.