For my new mod I am going to look at spawning assets rather than using placed ones. I am looking at workflow in general and this is one aspect of this.
I know that others spawn rather than place, but how is this done functionally? I am thinking to spawn everything of the on_enter script but do you destroy everything on exit, I guess you have to?
What are the advantages of this. Are there more beyond the fact that I can modify blueprints rather than instances?
PJ
I know that others spawn rather than place, but how is this done functionally?
I am thinking to spawn everything of the on_enter script but do you destroy everything on exit, I guess you have to?
What are the advantages of this. Are there more beyond the fact that I can modify blueprints rather than instances?
The prologue of my campaign being 90% done, I'll keep the ScriptHidden creatures and the triggers I already wrote
Retour en haut
void main()
{
int iNb = d4(1); // entre 1 et 4 adversaires
int iType = d4(1); // type de l'ennemi
string sRef;
switch (iType)
{
case 1:
sRef="c_beetlestag_tgk";
break;
case 2:
sRef="c_beetlefire_tgk";
break;
case 3:
sRef="c_beetlebomb_tgk";
break;
case 4:
sRef="c_spider_tgk";
break;
}
while (iNb>0)
{
CreateObject(OBJECT_TYPE_CREATURE,sRef,GetLocation(GetObjectByTag("WP_Beetles")));
iNb--;
}
// une seule fois !
DestroyObject(OBJECT_SELF);
}
But I'll definitely check how this spawning thing works for the second module (only 25% complete, so not difficult to update).
Yes, I spawn rather than place. I have the code for doing so in the On Client Enter script for each area, and I have it set up so that I only have to place waypoints (not ipoints) tagged or otherwise marked with a creature's resref, and a special local integer (I created a blueprint with that integer already set).
If I wanted the creatures to repeatedly respawn, that's when I might use an ipoint. I could spawn an ipoint for each of them that dies, a single ipoint for all of them, or use the area's heartbeat. I'd use an ipoint if I wanted to stop the respawning cleanly by simply destroying the ipoint, and the area heartbeat if I didn't plan to stop the respawning.
For simple event-based respawning, all I have to do is set a local variable, for instance in a conversation, and the On Client Enter script does its job again next time the player enters, or of course I can spawn them directly from the conversation at that same waypoint if I need them immediately.
The main advantage for me is what you said -- that you can alter the blueprint at any time, and not have to open up the area(s) where the NPC is placed and alter it there. This is especially handy when you're talking about large numbers of monsters. Consider appearance, gear, loot, and scripts on that NPC.
Another advantage is a minor ease on the computer, in that placed NPCs are evaluating their scripts from the beginning of the game, even when the player has never been there, while spawned NPCs only start once the player has actually been there, because they didn't exist until then.
You can spawn them whenever you actually need them, not necessarily on Client Enter.
As AGhost said, you do not need to destroy them on exit unless the area itself is a temporary area. My shopkeepers, for instance, are spawned once, and never destroyed. Most spawning scripts mark their waypoints as "done" with a local integer so that they don't spawn every time the player enters, but as mentioned earlier, that integer can be removed if you want to spawn them again.
I use colour coding on my waypoints to determine which ones are for spawning, which are for doors or other teleports, which are for AI movement, etc.
Thanks guys. I can see pro's and cons. I am not sure the save on computer assets matter that much but I am certain the modding of blueprints vs instances does. i have completed a module or two now and making changes to instances when balancing is a pain in the butt.
I think, in the end, I will likely use a mixture depending on what is happening in the area.
PJ
PS; Good to see you posting again Kaldor Silverwand.
For creatures I've been spawning once on first entry, then use SetScriptHidden with disable UI true on area exit.
I use the same as Tchos. It's really easy to get the grip. Even for me. I spawn important NPCs but I have placed commoners etc.
I am now sure that i will mix and match but spawn on a do once script as RJS and others have said.
Workflow wise I am going to use a method discussed in a thread started by Kamal with his suggestions for speed modding.
I will complete the plot and areas then stage the whole thing in one large 32 x 32 area.
Once it is tested and completed/balanced I will save all the blueprints and spawn them as needed. Effectively I will spawn encounters and plot holder npcs to an area once and leave all the filler stuff in there from the start.
PJ
I really only read the initial post so I am responding to that and hope it is not a repeat.
I simply place all my spawn triggers at the entrance or very near it to reduce the lag (lets say 1 every 2m in game). Same effect, no scripting and you can spawn the whole dungeon that way.
I really only read the initial post so I am responding to that and hope it is not a repeat.
I simply place all my spawn triggers at the entrance or very near it to reduce the lag (lets say 1 every 2m in game). Same effect, no scripting and you can spawn the whole dungeon that way.
The problem with using triggers is that there's a slight (but noticable) delay when the player runs through them and the creatures spawn. Whenever I see that sort of delay in a module, I know something has just been spawned in the area, which ruins the immersion somewhat. Caching the creature blueprints in the area can reduce the pause, but never eliminates it entirely. Also, triggers on the ground can be notoriously unreliable in this game.
Spawning from an OnClientEnter script usually happens before the area becomes visible to the player, so they don't notice anything amiss.
Occasionally I'll spawn things via a door opening though. The pause still happens, but because it's not while the player is in motion you don't notice it quite as much.
I also spawn encounters from doors via script, using a local variable on the door to define the tag of the encounter trigger (hidden in an unwalkable location). I always notice a slight lag - but then again, I *am* anticipating it. It may depend on factors like how many encounter creatures the trigger spawns (the more, the laggier), how much grunt your computer has, or whether the creatures spawned have special OnSpawn scripts (mine often do).
I use both triggers and on-enter scripts to set up areas. Advanced traps are not something I can effectively add later, but I can keep adding things to areas using these methods. Triggers are sized and numbered for the rooms, and have a switch in the generic onenter/onexit to handle each trigger. I usually have the initial setup in an onenter in a conditional, then I can set up others as "esle if"
i
if(!(GetLocalInt(OBJECT_SELF,"nRun")==1))
{
SetLocalInt(OBJECT_SELF,"nRun",1);
//insert the code to spawn stuff here
}
else if (...)
//updates based on conditions, like adding more creatures if
// a certain thing has happened, etc.
As for triggers, I give them a generic onenter and onexit script, name the trigger (something)_0001, then run this:
int nNumber = StringToInt(GetStringRight(GetTag(OBJECT_SELF),4));
switch(nNumber)
{
//room 1 trigger...
case 1:
//whatever you want to do in this area
break;
//end room 1
//room 2
case 2:
break; //saving this in case I want to add something later
}
this way, since all these are campaign scripts, I can update. Doing that with Haunted Halls....check it out, let me know how the town works, first real update already happenin.
Nice prep work, EF! I add pseudo-triggers after the fact by spawning invisible custom AoEs. The same scripts that I use for triggers work on those. But I like the idea of preemptively laying down triggers for future use, and I think I'll add that to my methods.
yeah, if you pop open Haunted Halls, play it, and debubmode 1, everything is yellow.
