movenpc

[Stolao]

Ive been thinking this for a while, and have mentioned it in the forums in passing a few times.

 

I think a more advance movenpc would be very useful

 

Current movenpc

*movenpc "<NPC name>",<x>,<y>{,<dir>};

This command looks like the NPCWalkToxy function,but is a little different.

While NPCWalkToXY just makes the NPC 'walk' to the coordinates given (which 
sometimes gives problems if the path isn't a straight line without objects), 
this command just moves the NPC. It basically warps out and in on the current 
and given spot. Direction can be used to change the NPC's facing direction.

Example(s):

// This will move Bugga from it's current position to the coordinates 100,20 
// (if those coordinates are walkable (legit)).
	moveNPC "Bugga",100,20;

 

My Suggestion

*movenpc "<NPC name>",{ "mapname", }<x>,<y>{,<dir>};

 

This would eliminate having to duplicate npcs and use enablenpc/disablenpc to move one npc around more then one map.

 

Whats your thoughts?

[Euphy]

From what I remember, something gets buggy when you move NPCs onto different maps in runtime. It's already possible with 'unitwarp':

unitwarp getnpcid(0),"<map name>",<x>,<y>;

A core dev could probably explain this better, though.

[Stolao]

Ty Euphy, ill see how this work and see if its buggy still.

[GmOcean]

I want to re-suggest this command. Mainly because, unitwarp + getnpcid is still very buggy.

 

Some of things i've discovered is:

1. If the NPC has an OnTouch label, it will not activate at the new location (provided that location is outside of it's original cells).

2. The NPC doesn't recogize the new location as it's NEW location. It still holds all data to the original location marked in the script structure.

3. If a player walks over the cells where an NPC used to be, that has an OnTouch label, it will try to activate that label and fail, by sending errors to the map server, stating that the corresponding NPC is no longer there.

 

I'm sure there are a few more problems out there, but these are the ones i've found in the past couple days.

So again, I would like to re-suggest an updated command to move an npc across maps without these bugs.

 

This should be 100% possible, as I've had a src mod for eA a few years back that allowed me to create NPC duplicates on the fly as well as move the NPC across maps if I so choose to.

[Azura Skyy]

I want to re-suggest this command. Mainly because, unitwarp + getnpcid is still very buggy.

 

Some of things i've discovered is:

1. If the NPC has an OnTouch label, it will not activate at the new location (provided that location is outside of it's original cells).

2. The NPC doesn't recogize the new location as it's NEW location. It still holds all data to the original location marked in the script structure.

3. If a player walks over the cells where an NPC used to be, that has an OnTouch label, it will try to activate that label and fail, by sending errors to the map server, stating that the corresponding NPC is no longer there.

 

I'm sure there are a few more problems out there, but these are the ones i've found in the past couple days.

So again, I would like to re-suggest an updated command to move an npc across maps without these bugs.

 

This should be 100% possible, as I've had a src mod for eA a few years back that allowed me to create NPC duplicates on the fly as well as move the NPC across maps if I so choose to.

 

You shared some really good information here. I do hope they get an opportunity to look into an improved movenpc and incorporate your ideas if/when they do. It'd be fun to see what it could be used for in quests after a rework.

Regards,

~Azura Skyy

[Zasura]

+1

[SBK_]

From what I remember, something gets buggy when you move NPCs onto different maps in runtime. It's already possible with 'unitwarp':

unitwarp getnpcid(0),"<map name>",<x>,<y>;

A core dev could probably explain this better, though.

 

 

But does not work in random coordinates =/

Boarded the warp of the code, you can arrive at a possible solution since it checks if the cells are valid.