A direct mob spawn and a group spawn do not necessarily interpret their final identifier as the same kind of object. Before changing coordinates, identify whether the line targets a mob, a group or a group collection in your server's regen format.
Follow the references
For a direct spawn, check the mob definition. For a group spawn, resolve the group identifier and then every member mob. If a group-collection mode is used, resolve that collection to its groups before inspecting members. The exact tokens and extra fields belong to the parser in your branch.
Conceptual reference chain, not a ready-to-install regen row:
Direct spawn -> mob definition
Group spawn -> group definition -> member mobs
Collection -> group collection -> groups -> member mobsA narrow investigation
On staging, first confirm the map loads and one known direct mob appears at a known usable location. Next test one known-working group from that same serverfiles set. Then test your changed group at the same location. This helps separate reference problems from coordinate or terrain problems.
Inspect duplicate group identifiers, missing member VNUMs, malformed boundaries and the exact data files loaded by the running process. A similarly numbered mob and group are not interchangeable just because both are integers.
Verify after the edit
Keep the original files, change one reference or group definition, and compare the diff. Confirm the expected members appear, not merely that one entity appeared. Record the spawn mode and resolved chain in your support question.
Reference
A community spawn-file introduction describes distinct spawn modes. The reference-chain model and controlled comparison here are M2City additions. Consult your own parser for the complete row layout rather than pasting a row meant for another server.
Share one sanitised spawn line, the relevant group definition and its member IDs if you want another builder to reproduce your result.