Spawn DFN script help.

[ArgileNinja]

I'm having trouble with a Regionspawn sript and was wondering if anyone had any ideas. I'm attempting to spawn one type of mob at different regions accross the map. This is what I have thus far...

[REGIONSPAWN 0]
{
NAME=archmage
NPLIST=murderer-archmage
MAXNPCS=30
X1=5467,5422,5403
Y1=1872,1894,1928
X2=5480,5432,5418
Y2=1884,1907,1937
MINTIME=0
MAXTIME=1
CALL=5
}

Was attempting to do some sort of array, perhaps my syntax is wrong. I'm not very proficient with scripting. Any help is appreciated. Thanks

[Xuri]

I'm not entirely sure if that setup will work - giwo/Maarc will have to fill you in on whether or not it's possible to use multiple sets of coordinates for one spawn region.

The rest of your setup looks good though.

[Maarc]

Nope, multiple areas like that aren't supported. It wouldn't be too hard to do, though, especially given the fact regionspawns aren't perpetuated across worldsaves.

I'll ask two questions.

1) Do people want multiple areas supported for a single regionspawn (and if so, when a spawn comes around, is it randomly in one of the regions, or is it CALL for each physical region)

2) Provided 1 is yes, is that the format you want? Or do you want to support a different tag structure? (Say, something like RECT=x1,y1,x2,y2 instead, with support for multiple RECTs)

[Xuri]

1) Yes please That would make the spawn files a lot easier to manage. If you have 37 "farm animal spawns" around the world, for instance - and have to update each and every one of them Not sure what you mean about "randomly in one of the regions" - only spawning in one set of coordinates if there are multiple defined for a single "physical" region? If so, then I'd want them all to spawn.

2) Hm I think the format ArgileNinja used looks pretty easy to use. If you want more than one region, add the extra coordinates behind each tag, prefixed by a comma

[giwo]

Well, as for that format, I would vote for a format like RECT=x1,y1,x2,y2 as that would be more simple to load in and also easier to modify (or remove one entry alltogether).

Aside from that, there is some functionality already existant in spawnregions to allow one spawnregion entry to be used in multiple areas.

I'll have to check to be sure when I get home, but I believe the header would be [PREDEFINED_SPAWN 0]

And all the same data (minus the x's and y's).

From there, you go into regions.dfn, and after each x/y group (since regions can be multiple rectangles) that you want spawning critters, do SPAWN=0 and so on.

This is how I spawn my cities, and from there I design spawnregions for the dungeons and wilderness.

[Xuri]

*nod*

Do we still have a limit of 255 regions in regions.dfn, btw?

[ArgileNinja]

Thanks for the info, using [PREDEFINED-SPAWN] does clear up some of the mess with town spawning. It is possible to do with dungeon/map spawns as well but with the GAURD=# tag you get a heavy dose of "You're no longer under the protection of the guards!" spam. I'll go with your way Giwo and split them up for now.

[giwo]

Yeah, that guard notice shouldn't happen when you go from unguarded to unguarded regions... but it does

Xuri: It caps out at something like 65535

[Maarc]

Not sure what you mean about "randomly in one of the regions" - only spawning in one set of coordinates if there are multiple defined for a single "physical" region?

You have a spawn region. You define 3 rectangles. On each "spawn" call, do you spawn in only one rectangle (selected randomly) or do you spawn in all 3? As an extra question... does the limit to the amount of spawns apply to the whole system, or each rectangle.

I'd agree with giwo, though, that a RECT based syntax would offer more ease (adding/removing/editing), as well as being more coder friendly.

Never played with PREDEFINED_SPAWN, so you'll have to run with giwo on this one

[Xuri]

Hmm that's a good question, because you either set up seperate rectangles with nothing in common but the type & number of NPCs to spawn, or you could use the extra coordinate sets to set up one spawn area consisting of several connected rectangles.

Allowing both ways would be very nice, but how?

[Maarc]

Well, that is why developers invented extra tags

A behaviour tag could be readily added. But basically, decide on some functionality, exactly what you want, and it would take... 30, 40 mins to do, probably. Maybe less

[ArgileNinja]

While this may be slightyly off topic from the original post, I was just looking over the source code and was wondering if it wouldn't be more beneficial to consolidate the Region and the SpawnRegion sections into one. Then you could pull all the relevant information from one area, while giving the benefit of using multiple SpawnRegions coordinates, just like the regular Regions.

At that point you could add a tag for Dungeon Regions that disables the nasty "You're no longer guarded" message. In "townregions.h" it looks as if someone had this idea at one time due to a small addition "//0x08 Dungeon Region". Or mabey I'm just crazy haha

[Maarc]

Regions (or town regions, really) have a persistency beyond startup. They actually save along with the worldfile, because there is infrastructure support for things like town mayors, voting, donations and so on, and that needs to persist over time. I don't think spawnregions are persistent, and so in that regard, there is a distinct difference in the way the two behave. That's not to say they couldn't be joined together.

Yes, support for dungeon regions exist (DUNGEON=1 in the region definition). However, it doesn't look like it's used terribly often (accessible for the region from JS, and used in the call to a char's inDungeon() function, but that's only used for lighting purposes). Perhaps exposing inDungeon to JS engine, and updating the guard code to deal with it might help, though I think guards + dungeons shouldn't be tied to each other (you might have an evil dungeon of doom with evil guards with modified logic).

[giwo]

Just as I was looking at this old topic....

Xuri: there still is a limit on Regions (regions.dfn) of 255. Mostly this is a logical limit of the "regionumber" variable we store on characters and in the townregions.

Spawnregions have no real limit, though I would stick with 65535 to be safe with them.

I still wouldn't mind adding in the RECT= tag, but before doing so we would still need to decide the behaviour behind it. Do we consider that all one big region with several parts, or does each RECT represent its own region that spawns independently.

[Xuri]

Hmm. Additional tag (weee) defining whether or not UOX3 should consider specific spawnregions as big regions with many parts or multiple independent regions under one spawnregion section?

[giwo]

Personally I don't really like the tag.

The main thing I have against it is this, we parse our scripts in an order. From top to bottom we pull out information storing it as we get it. There is no real "order" for things, with a few small exceptions (the GET= tag in items/npcs, the SPAWN= tag in regions.dfn) and thus the code does not need to be too intelligent, it just stumbles apon tags and fills the appropriate variable with that data.

This would require more than a bit of intelligence on the part of the parser. It would mean doing one of two very different things when reading in the region. 1) Filling up a vector of rectangles, or 2) Creating a whole new CSpawnRegion instance and duplicating the data onto that one from our current spawnregion. This would mean that the tag would be required to be at the top of the section, else the parser would not know what to do.

I would think if we wanted something like a MultiRegion, we should possibly create a new section for that specifically. Of course, that would be a whole new pain in the ass, first looking for SECTION SPAWNREGION # then looking for SECTION MULTIREGION #.