Well, not quite sure why it would be removed, but you could try a prop_dynamic_override in case there is some sort of model issue.
There are many methods of doing the same sort of thing, before making a lot of changes, maybe make a backup just in case you want to go back to the method it is now.
Since it is being spawned, you might as well be using the engine to handle the properties of the coin:
Code:
SetEntPropFloat(iCoin, Prop_Send, "m_flModelScale", 0.7);
becomes:
DispatchKeyValue(iCoin, "modelscale", "0.7");
SetEntityRenderColor(iCoin, 255, 215, 0, 255);
becomes:
DispatchKeyValue(iCoin, "rendercolor", "255 215 0");
DispatchKeyValue(iCoin, "renderamt", "255");
and it wouldn't hurt to ActivateEntity(iCoin); and possibly AcceptEntityInput(iCoin, "Enable"); as well.
You could try teleporting the trigger before DispatchSpawn(iTrigger); there is a minor potential that it could be triggered at origin "0 0 0" just before it is teleported. The trigger could still be functioning because it is a trigger_multiple, could test if it is all still working with a trigger_once perhaps.
If the issue is that a trigger_once could give a starttouch at the wrong time, dispatch the key spawnflags 1 and possibly run it by a:
Code:
HookSingleEntityOutput(iTrigger, "OnStartTouch", Hook_StartTouch);
Then change the callback to:
public Action Hook_StartTouch(const char[] output, int caller, int activator, float delay)
Where the caller is the trigger, and activator is the client, it will only work if spawnflags 1 is set.
Other than that, it could be another plugin doing it.
It is a bit spammy, but if you want to see a lot of inputs/outputs, you can set the CVar developer to 2 on the server, and see if your coin is receiving inputs from somewhere else. To make it a bit easier to find in the inputs/outputs, dispatch a targetname for the coin.