tk422

NPC's which have drops have them listed in drop groups.
 
- Each drop group has a chance to be selected as the one that drops.
- Each item within the drop group also has an associated chance of dropping.
 
So in your example:
{[scrl_of_ench_am_s];1;1;0.047}};54.1847}}
 
{[iTEM-NAME];MIN-QTY;MAX-QTY;ITEM-DROP-CHANCE-WITHIN-GROUP}};GROUP-SELECTION-CHANCE}}
 
There are three rules i follow:
- All items within a group must have a total of 100% chance.
- Group selection chances may be less (but never more) than 100%.
- The total chance for all drop groups does not need to balance / add up to 100%.
 
Note: (In my personal experience and without criticizing anyone else's work)
Every "public" drop editor i have ever used does NOT handle drop chance correctly.
Each tool simply multiples the drop chance for all items in a group by some value.
This does absolutely nothing as it preserves the ratio for all item drops within a group.
 
I recommend instead of messing with drop chance, simply increase the quantity of items that are dropped.
Remember that if you do this blindly any NPC that drops big things (like whole A grade) will start dropping multiple of those big items.
To me that's bad but your server may be different.
Either way make sure to decide which items specifically should have their quantities multiplied.

I can't speak for VG pack specifically but you should not need to install any additional roles onto the machine.
Just make sure you have all the latest updates and security patches for MSSQL and the OS.
MS seems to only release SQL updates purely as service packs so just grab the latest.
Install all the .Net's manually though, then just grab the updates and security patches though WU.
 
General security advice:
- Disable Windows Firewall and get a real piece of gear to handle protection. Mikrotik is great though there is a bit of a learning curve if you're not familiar with networking.
- Block all inbound ports to the server except Auth and L2Server.
- Allow RDP access but only from specific IP's. Better yet use NAT to change the port to something silly.
- Log all outbound connections from the server.
- Do NOT run the registration system on the machine. Run it somewhere else and filter / proxy the connection.

An L2 server is made up of a few different parts.
 
- CacheD:   Functions as an intermediary between L2Server and the MSSQL database.
- AuthD:      Authentication server which authenticated client logins. AuthD has been "replaced" by a third party (non-NCSoft) application called hAuthD.
- L2Server: The actual game server.
- L2NPC:    The NPC server responsible for processing NPC >< player interaction.
 
As far as i know all communication for L2 is done purely using TCP sockets. If i had to GUESS why it would be that TCP was easier to work with for something like L2 because it's not exactly "real time".
 
Here is a teriffic article on the subject: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
 
The lifecycle for login goes something like this:
- Player types credentials into input boxes on the screen.
- Client generates a packet with those credentials and sends them to the auth server.
- Auth server validates them, then replies with a list of available game servers.
- Client makes a request for the selected game server.
- Auth sends back the connection info for the game server.
- Client then makes a direct connection to the game server.
 
For more detailed information check out this project:
https://code.google.com/p/l2packets/