The first error is the more informative one:

Unexpected multi-MODEL input. Use "vina_split" first?

That usually means the file being passed as a ligand is not a single ligand PDBQT. It is probably a multi-model PDBQT, often produced when a whole ligand library is converted into one output file. Vina expects one ligand per docking run. Multi-model PDBQT files are normal as Vina output, but they are a bad input for a single ligand run.

I would check the ligand file first:

grep -n "^MODEL|^ROOT|^TORSDOF" ligand.pdbqt | head -40
grep -c "^MODEL" ligand.pdbqt
grep -c "^ROOT" ligand.pdbqt

If you see multiple MODEL or multiple ROOT sections, split the file and dock each ligand separately. For a Vina-style multi-model PDBQT, try:

vina_split --input ligand.pdbqt

If the file came from a SMILES library, it is usually cleaner to create separate PDBQT files at conversion time instead of making one combined file. With Open Babel, the -m option writes one output file per molecule:

obabel ligands.smi -O ligand.pdbqt -m --gen3d

That should create files like ligand1.pdbqt, ligand2.pdbqt, etc. Then run Vina once per ligand, or make sure your Perl script reads a list of separate filenames and passes only one ligand filename to each Vina command.

The second error:

Command line parse error: too many positional options

usually happens when the wrapper script builds a Vina command with extra unflagged arguments. Common causes are spaces in paths, a ligand-list file being passed where a single ligand filename is expected, or multiple ligand names ending up after --ligand. Print the exact command that Vina_windows.pl runs, or run Vina directly once to isolate the issue:

vina --receptor receptor.pdbqt --ligand ligand1.pdbqt \
  --center_x 0 --center_y 0 --center_z 0 \
  --size_x 20 --size_y 20 --size_z 20 \
  --exhaustiveness 1 --out test_out.pdbqt

Also, a ligand showing as a single ball in Discovery Studio is a warning sign that the ligand conversion failed or produced poor coordinates/bond perception. Check that each ligand PDBQT has real 3D coordinates, one ROOT/ENDROOT block, a TORSDOF line, and AutoDock atom types at the end of the atom lines. Preparing from SDF/MOL2 with defined bond orders is usually more reliable than from a plain SMILES string unless you explicitly generate 3D coordinates and choose the intended protonation state.

I work on ProteinIQ's AutoDock Vina tool, where we validate PDBQT inputs for these kinds of malformed multi-ligand/geometry cases. But the important fix here is independent of any web tool: give Vina one well-formed ligand PDBQT per run, not a combined multi-model ligand file.