As long as you're setting the chest's tag to something unique, you should be able to GetNearestObjectByTag. Otherwise you can use GetNearestObject, but that's more error prone.
FWIW, it IS possible to spawn things in random locations and be confident that they are walkable :-) Its a bit of a hack though, and uses a lot of system resources. The trick is to create a CREATURE in the random location. The engine won't let a creature be created on an unwalkable location, it shunts the creature sideways to a walkable location. So you create the creature, then use GetLocation to save its safe walkable location, destroy the creature, and create your placeable on the saved location. I have used this for random resource placement scripts.
But other posters were correct in telling you to use manually placed scattered waypoints instead - much easier. Hope this helps :-)
Random Buried Treasure and Maps
Débuté par
JerrodAmolyan
, août 05 2013 04:43
Retour en haut
#27
Posté 09 août 2013 - 01:41
FunkySwerve
-
- Members
- 1 308 messages
ruadhri10 wrote...
FWIW, it IS possible to spawn things in random locations and be confident that they are walkable :-) Its a bit of a hack though, and uses a lot of system resources. The trick is to create a CREATURE in the random location. The engine won't let a creature be created on an unwalkable location, it shunts the creature sideways to a walkable location. So you create the creature, then use GetLocation to save its safe walkable location, destroy the creature, and create your placeable on the saved location. I have used this for random resource placement scripts.
But other posters were correct in telling you to use manually placed scattered waypoints instead - much easier. Hope this helps :-)
The NWNX function I mentioned is much simpler, but that isn't the stumbling block. Making sure that the pc can REACH the walkable location is.
Funky
#28
Posté 09 août 2013 - 02:14
meaglyn
-
- Members
- 807 messages
JerrodAmolyan wrote...
That looks good otherwise, but I'm using source chests so I don't have to write up all the resrefs, will it work with those too ?
Was this in response to what I posted? If so then, yes.. The lines I posted were modified versions of what you posted in your script. Change createobject line in the maketreasure routine to include using the stacksize for the item you are using from the chest.
Cheers,
meaglyn
#29
Posté 09 août 2013 - 07:39
Squatting Monk
-
- Members
- 444 messages
He had actually said that didn't matter to him because he was going to be working on climbing, swimming, etc. scripts for those unreachable places. However, having to set all that up just to get the treasure map system working seems like far too much work for so little payoff (especially for a novice scripter).FunkySwerve wrote...
The NWNX function I mentioned is much simpler, but that isn't the stumbling block. Making sure that the pc can REACH the walkable location is.
Modifié par Squatting Monk, 09 août 2013 - 07:50 .
#30
Posté 09 août 2013 - 10:19
FunkySwerve
-
- Members
- 1 308 messages
Yes, I read that. It doesn't make it any less a stumbling block. Consider this: for any given walkable area, you must first determine if there is a walkable path to it. That, by itself, is an enormous undertaking, since you must at a minimum track it back to an area transition, while accounting for placeables. I'm honestly not sure how I would go about doing that. Then, if there isn't one, you must then determine if there is some other way of reaching that spot - such as a climbing rope, swimming, etc. That would ALSO be an enormous undertaking, since you would have to retrofit into your system every other system that offered a potential means of ingress to an otherwise unapproachable point - even fitting in one such system, like climbing, would present serious difficulties akin to finding the initial walkable path.Squatting Monk wrote...
He had actually said that didn't matter to him because he was going to be working on climbing, swimming, etc. scripts for those unreachable places. However, having to set all that up just to get the treasure map system working seems like far too much work for so little payoff (especially for a novice scripter).FunkySwerve wrote...
The NWNX function I mentioned is much simpler, but that isn't the stumbling block. Making sure that the pc can REACH the walkable location is.
The only way I could think of that is remotely feasible would be to half-ass it, by adopting the assumption that any walkable spot in the mod will either be accessible or ruled out as a treasure spawning spot at some point in the future. You'd wind up hacking in edits for months or years as players stumbled upon new inaccessible treasures. Just not a great way to do things, when much simpler and semi-equivalent approaches are available.
Randomness mostly adds a sense of verisimilitude which is just as easily obtained by planting a sufficient number of pre-placed spots. That's actually the approach we adopted for our secret systems - pre-set spots, only a random selection of which are active on any given reset.
Funky
#31
Posté 10 août 2013 - 09:18
JerrodAmolyan
-
- Members
- 89 messages
Well the system SquattingMonk gave me actually is a bit random. I have like 100 TreasureWPs scattered all around the places And like hell will I remember where I put every one of them in the future, lol, mission accomplished (I mentioned I want a random system where even I can't know where the treasures are.) so I'm happy with it. (I have like 5 waypoints per area, and this system does count them as individual waypoints even though they are the same tag and resref. So it does make the treasures more random.)
Meaglyn: Yeah I figured out today that I can stamp those into my existing script and replace somethings, I haven't tried it out yet, but I have faith it'll work. Thanks for your help
Also yes, I plan to make some sort of climbing system in the future, not sure about swimming, but I have an underwater system already, with flying animation as swimming. I just need to figure out how to make air pockets or something, so you won't need immunities to not drown.
Meaglyn: Yeah I figured out today that I can stamp those into my existing script and replace somethings, I haven't tried it out yet, but I have faith it'll work. Thanks for your help
Also yes, I plan to make some sort of climbing system in the future, not sure about swimming, but I have an underwater system already, with flying animation as swimming. I just need to figure out how to make air pockets or something, so you won't need immunities to not drown.
#32
Posté 10 août 2013 - 09:23
JerrodAmolyan
-
- Members
- 89 messages
Oh, and just a side question:
I did some modifications to the system, now you get the X placeable instead of the chest, which you need to talk to and then have a shovel equipped to dig it up, which then does simple animations and visuals (Get from Waist and visual for chunks of sand/rock) what I need to accompany it, is some sort of shoveling sound... So far I haven't managed to figure out what do I need to add to the variables list in order to use "PlaySound" function ?
I did some modifications to the system, now you get the X placeable instead of the chest, which you need to talk to and then have a shovel equipped to dig it up, which then does simple animations and visuals (Get from Waist and visual for chunks of sand/rock) what I need to accompany it, is some sort of shoveling sound... So far I haven't managed to figure out what do I need to add to the variables list in order to use "PlaySound" function ?
#33
Posté 10 août 2013 - 09:26
Squatting Monk
-
- Members
- 444 messages
You should just be able to add PlaySound("your_sound_here"); to the script that fires the animations.
Modifié par Squatting Monk, 10 août 2013 - 09:26 .
#34
Posté 10 août 2013 - 10:15
JerrodAmolyan
-
- Members
- 89 messages
Oh... so it seems, thanks. I wonder where I got the idea that I need something.
#35
Posté 20 août 2013 - 11:07
bdtgazo
-
- Members
- 53 messages
Looks like you just about got it, but I'll float another idea anyway...
For things like this, treasure hunts or murder mysteries, I tend to use generic triggers.
Many ways to do it, but lets say it goes like this:
1) PC finds a treasure map. He uses it. The onactivate script sets a variable. I would use a level check on the PC, and to begin with just have 5 preset hidden treasures per every 5 levels, with a few unique treasures attached to unique maps set in hard dungeons.
2) So PC uses the map, the variable is set to, let's say, 6. A message is sent to the PC saying the treasure is in the northern part of the Swamp of Desolation or some such. Variable is upgraded +1. PC goes there.
3) Now in the areas close to the area where the treasure is, you have some triggers. When the PC enters the trigger, a variable check is made and a message sent to the PC. I do my best to use ONE SINGLE SCRIPT for all of my triggers that are of this nature. Keep it as simple as you can. So maybe on the variable check, which is just to determine that the PC has the map, the message says: You need to go north, or You are getting close. You need to go north.
4) Eventually the PC should be really close. Now you could have a usable placeable or another trigger, or both (I would just use a trigger myself - keep it simple), and here the PC interacts with the trigger or placeable and it spawns a chest. Maybe from a conversation, such as, "You have found some disturbed earth, do you use your shovel to dig?" "Yes, I do," or if no shovel in inventory "Damn, I don't have a shovel."
5) The chest spawns. It can be tied in to the loot system, so the player actually opens it, or perma locked and uses a script to spawn treasure right on the PC.
The beauty of the system is that you don't have to keep spawning waypoints everywhere, just place the triggers.
To avoid too many repeats for chest locations, you could add to the onactivate script a variable check that prevents a variable from being reused until all the other variables for that level range have been used up.
If you are evil, you could add in random chances for the treasure having already been dug up, or the chest holding another map.
For things like this, treasure hunts or murder mysteries, I tend to use generic triggers.
Many ways to do it, but lets say it goes like this:
1) PC finds a treasure map. He uses it. The onactivate script sets a variable. I would use a level check on the PC, and to begin with just have 5 preset hidden treasures per every 5 levels, with a few unique treasures attached to unique maps set in hard dungeons.
2) So PC uses the map, the variable is set to, let's say, 6. A message is sent to the PC saying the treasure is in the northern part of the Swamp of Desolation or some such. Variable is upgraded +1. PC goes there.
3) Now in the areas close to the area where the treasure is, you have some triggers. When the PC enters the trigger, a variable check is made and a message sent to the PC. I do my best to use ONE SINGLE SCRIPT for all of my triggers that are of this nature. Keep it as simple as you can. So maybe on the variable check, which is just to determine that the PC has the map, the message says: You need to go north, or You are getting close. You need to go north.
4) Eventually the PC should be really close. Now you could have a usable placeable or another trigger, or both (I would just use a trigger myself - keep it simple), and here the PC interacts with the trigger or placeable and it spawns a chest. Maybe from a conversation, such as, "You have found some disturbed earth, do you use your shovel to dig?" "Yes, I do," or if no shovel in inventory "Damn, I don't have a shovel."
5) The chest spawns. It can be tied in to the loot system, so the player actually opens it, or perma locked and uses a script to spawn treasure right on the PC.
The beauty of the system is that you don't have to keep spawning waypoints everywhere, just place the triggers.
To avoid too many repeats for chest locations, you could add to the onactivate script a variable check that prevents a variable from being reused until all the other variables for that level range have been used up.
If you are evil, you could add in random chances for the treasure having already been dug up, or the chest holding another map.
#36
Posté 24 août 2013 - 03:44
ffbj
-
- Members
- 593 messages
I did one where you purchase a treasure map that works in various locations..i.e. any area that has an inter Treasure set to 1 on it. This way you can it easily expand it. So each area so marked will have a
chest in it that you can locate with your map. When you are in the area and consult your map: you get:
1. Your map is dark, if no chest in area, i.e. in this case you have already found the chest since we are considering only areas where a treasure was existent.
2. Your map flickers: chest in area too far away to get exact co-ordinates.
3. A spot on your map lights up: chest detected 2-15 meters in a direction which your facing is now auto-turned to.
4. Usually whinin 3 tries you find the chest within 1 meter and you consult your map the chest appears in that spot.
With this method there is no need to place wp's except for the chest random wp and a trigger, which can be as big or small as you want. The trigger is what allows you to begin your chest search. I find a 15 meter square works well. Anyway I was very happy with the results.
Just to make it bit easier each location is given a general section of an area with a verbal description of where to start searching.
I use a decreasing range with each wp creation and destruction. So a typical result might be
There is a chest 9 meters/paces in x direction (I use the term paces in the description) 6 paces in x
direction..2 paces in x direction..etc...
I lock out future discoveries of the chest by creating and setting the id of the area on the database object on the pc and set chest found to 1.
chest in it that you can locate with your map. When you are in the area and consult your map: you get:
1. Your map is dark, if no chest in area, i.e. in this case you have already found the chest since we are considering only areas where a treasure was existent.
2. Your map flickers: chest in area too far away to get exact co-ordinates.
3. A spot on your map lights up: chest detected 2-15 meters in a direction which your facing is now auto-turned to.
4. Usually whinin 3 tries you find the chest within 1 meter and you consult your map the chest appears in that spot.
With this method there is no need to place wp's except for the chest random wp and a trigger, which can be as big or small as you want. The trigger is what allows you to begin your chest search. I find a 15 meter square works well. Anyway I was very happy with the results.
Just to make it bit easier each location is given a general section of an area with a verbal description of where to start searching.
I use a decreasing range with each wp creation and destruction. So a typical result might be
There is a chest 9 meters/paces in x direction (I use the term paces in the description) 6 paces in x
direction..2 paces in x direction..etc...
I lock out future discoveries of the chest by creating and setting the id of the area on the database object on the pc and set chest found to 1.
#37
Posté 24 août 2013 - 10:29
FunkySwerve
-
- Members
- 1 308 messages
With this method there is no need to place wp's except for the chest random wp and a trigger, which can be as big or small as you want.
Our secrets systems use only a trigger, and the system I suggested to the op would only need either a wp or a position. Both a wp and a trigger seem like overkill. The int is too, though I like the principle. Really, cleanest would be a string holding the position/s of secrets in the area, with space and comma seperators, e.g., "35.1,22.0,0.1 11.0,4.0,1.1". Then you could just set the var and run everything off the item. If GetLocalString(oArea, "Blah") != "", there's secret treasure in the area, and you can parse the string to figure out which is nearest. Also pretty easy to wipe all but one of the substrings with seperator " " if you only want one position valid per reset or whatever...
Funky
Modifié par FunkySwerve, 24 août 2013 - 10:30 .
