15 réponses à ce sujet

[adoado13]

Well the title really says it all. I remember in NWN there was an "encounter" setup that allowed you to make an infinantly respawning encounter for you to fight. I see nothing like that in the DA:O toolset. I want to make a dungeon that I can grind through repeatedly but I cannot figure out how to do this. Any help would be greatly appreciated.
Thanks.

[Dmuse]

You can likely do this with triggers to spawn the encounters. That way each time you hit the trigger the encounter is spawned.



I would suggest having a plot setup with the dungeon so you can toggle on/off each trigger. This will stop your party from walking and triggering a trigger, then backing it up and triggering it again thus spawning 2 of everything -- which could be bad! Have the trigger check the toggle, then spawn if the toggle is on, then toggle the plotline for that trigger off so it can't be triggered again until you go back to the first trigger of the dungeon which sets all of the toggles back to on.

[adoado13]

Is there a way that you could point me in the right direction as far as which script I would need to use? I'm still pretty lost.

[EmeryQuinn]

http://social.biowar...hp/CreateObject

Start here, bioware shows you some code for spawning monsters.

[mackeyz]

http://social.biowar...hp/CreateObject>>>>>>tutorial's confusing????any simple tutorial plz?????

[giskard44]

Thanks Leopard73.



I seem to be having to dig deep in to some relatively simply areas like lighting just to get them to work so it may be some time before i am able to get on with the scripting and questing.



In the mean time here is a link to a spot where me and a guild mate of mine started talking about this very issue. I showed him your script, he is pretty good with scripts him selve but is still learning DA script.



http://www.theengine...772

[Craig Graff]

If you destroy a trigger it is gone (though if you use the trigger to save the game the game will be saved before the trigger is destroyed, meaning that loading the save causes the trigger to return).



It is generally better to either set a local variable or use SetObjectActive(oTrigger, FALSE) and then check for the variable or if the trigger is enabled in your script before running the code.

[hannahb]

Im going to hazzard a guess here and say that this:



object oNewObject = CreateObject(OBJECT_TYPE_CREATURE, R"yours.utc", lLoc);



instantiates a new block in memory. As such doing something like this:



for(i=0; i<3; i++)



{



object oNewObject = CreateObject(OBJECT_TYPE_CREATURE, R"yours.utc", lLoc);



}



could cause a noticeable slowdown (aka Lag spike) when you hit the trigger especially if the number of iterations is high. Thus tipping off the player that something was coming.



As an alternative you might consider PRECREATING the creatures and keeping them in an inaccessible area of the map and then moving them where you want on the trigger event. Just an optimization trick.

[Craig Graff]

Just a note that it would generally be much better to have the above code as

object oNewObject;
for(i=0; i<3; i++)
{
    oNewObject = CreateObject(OBJECT_TYPE_CREATURE, R"yours.utc", lLoc);
}

Also, it is worth noting that if you are going to be creating creatures instead of activating them, it is a good idea to use the CreatePool function.

Modifié par Craig Graff, 07 décembre 2009 - 09:39 .

[Sunjammer]

Much better if social didn't eat part of your for clause!

The [code] and [/code] tags are your friends!

Modifié par Sunjammer, 07 décembre 2009 - 09:30 .

[Craig Graff]

Nah, we never really seem to get along.