PDA

View Full Version : NOTE TO MAPPERS: Usage of JBInfoJail - Thingy with Shared Jail Addon


Jrubzjeknf
4th Sep 2005, 08:21 AM
To all mappers: in case you're defining the boundaries of multiple jails with one volume, please use one volume a team or one a jail).

The reason for this is that my addon detects shared jails by looking if both EventReleaseRed and EventReleaseBlue have entries. If so, the addon recognizes a shared jail and registers itself. If only one entry is found, the addon doesnt find a shared jail and doesnt register. So if the boundaries of multiple jails, belonging to both teams, are defined with one volume (thus both EventReleases have entries), the addon thinks there's a shared jail in the map and registers itself.

So, if your map does not have a shared jail, please dont enter something in one of the EventReleases.

Whilst looking through some maps, I noticed that Heights, IndusRage2 and NoSense have entries for both EventReleases. I hardcoded a check that looks at the current map's title and if it matches, the addon doesnt register. I cannot do this for future maps though. It's up to you guys to make sure that the addon doesnt register when your map is loaded.

Just wanted to let you know that :)

PS. Spoondogg's maps Heights and IndusRage2 has both entries filled in at both JBInfoJails. They dont seem to have any use, or do they?

PS2. Sticky?

tarquin
11th Sep 2005, 07:31 AM
The reason for this is that my addon detects shared jails by looking if both EventReleaseRed and EventReleaseBlue have entries.

Wouldn't it be better to examine all the PlayerStarts contained in that jail? ( Use JBInfoJail.ContainsActor for all PlayerStarts.)

Then you'd be certain, because you're not relying on mapper input.
Mappers (like Spoondog :D ) may find it easier to select ALL their Jail actors & set the events in one go. It's quicker & that way you are certain of having everything set up.

Jrubzjeknf
11th Sep 2005, 09:58 AM
Wouldn't it be better to examine all the PlayerStarts contained in that jail? ( Use JBInfoJail.ContainsActor for all PlayerStarts.)

I've thought about that. Take NoSense for example. It has two jails located next to eachother, has one big volume around it and a single JBInfoJail.

JBInfoJail's ContainActor function description:
// ============================================================================
// ContainsActor
//
// Returns whether this jail (including attached zones and volumes) contains
// the given actor. -snip-

If I understand this piece of text correctly, it'd mean the two jails in NoSense would be seen as one, right?

tarquin
11th Sep 2005, 10:43 AM
One JBInfoJail actor, therefore one jail.

Basically, what NoSense has is a single jail that happens to be segregated.
There's no way you'd be able to detect that in any case.

Jrubzjeknf
11th Sep 2005, 11:40 AM
That's what I mean. I needed to detect it in some way and your way still has its errors.

I've been thinking about another way btw. Playerstarts are pathnodes, so they'll link when placed in a way that bots can walk (and within radius, blablabla). Would it be possible to iterate through all red playerstarts, see if they link with a blue playerstart and if so, allow the addon to register itself?

tarquin
11th Sep 2005, 12:01 PM
That's what I mean. I needed to detect it in some way and your way still has its errors.

Fewer errors though.

I've been thinking about another way btw. Playerstarts are pathnodes, so they'll link when placed in a way that bots can walk (and within radius, blablabla). Would it be possible to iterate through all red playerstarts, see if they link with a blue playerstart and if so, allow the addon to register itself?

Not entirely sure if that would work.
Would you be checking for a direct link, or an indirect?
I can imaging a shared jail in a U shape where the starts are on opposite sides, and don't link directly.
If it's indirect, would the Door actor let the linking go all the way round outside the jails?
You'd need to investigate the code that lets you test for paths between nodes.


Maps with a "segregated shared jail" are going to be a problem, basically.

Jrubzjeknf
11th Sep 2005, 01:12 PM
Not entirely sure if that would work.
Would you be checking for a direct link, or an indirect?
I can imaging a shared jail in a U shape where the starts are on opposite sides, and don't link directly.
If it's indirect, would the Door actor let the linking go all the way round outside the jails?
You'd need to investigate the code that lets you test for paths between nodes.

I'd like to check for an indirect link, using pathnodes (playerstarts/doors) within the jailvolume. I assume that shouldn't be that hard. Anyways, I posted a little thread on INA here (http://www.ataricommunity.com/forums/showthread.php?s=&threadid=493050) to get some more backup on this one.


Maps with a "segregated shared jail" are going to be a problem, basically.

Well, assuming that they're linked (else it wouldnt be a shared jail) using a teleporter or such, the 'find indirect path'-methode should do the job. If not, the two parts of the "segregated shared jail" can be surrounded by one volume for each with the same tag. When a single JBInfoJail then has this tag set in TagAttachVolumes, the "segregated shared jail" is considered a shared jail.
Example: if the teleporters in NoSense would point to eachother, you'd have a shared jail, since it's already being considered as one, even though it's not ^^

tarquin
11th Sep 2005, 02:42 PM
basically, your flow is:

- playerstarts in the jail all of one colour? yes -> single team jail
-- No -> path between playerstarts of different colours in the jail? No -> segregated jail
--- Yes -> shared jail

You need to wait for 2004c's fix to the llama code anyway to release this add-on properly, don't you?
if so, perhaps the above functions could be added to the JBInfoJail class, if Mych agrees.

Jrubzjeknf
12th Sep 2005, 01:40 AM
Might as well add a bSharedJail (default value False) variable. That way you dont even need to use a check. And while you're at it, you could add a Name variable called SplitSharedJailTag. My addon currently checks for all objects existing in the map with a certain tag, and makes them either visible or invisible depending on if the option to split shared jails is ticked. Might as well make it dynamic.
It won't break the JBInfoJails of the existing maps btw. You can always add variables to already existing custom actors :)

tarquin
18th Oct 2005, 04:05 PM
I think the first check at least is simple to implement.
The second check is worth investigating at least. I think it's always better to obtain information directly from the environment rather than counting on the mapper to do the right thing. Easier for the mapper too :)

The only problem is with mappers who have made segregated shared jails :stick:

It would indeed be interesting to add a tag to JBInfoJail for objects that should only be present to segregate a jail.
But would there be lighting problems if you remove static meshes on map load?

Vatcilli zeitchef
18th Oct 2005, 04:14 PM
I'm afraid so, Unlike actors (like staticmeshes and terrain)
BSP does not use dynamic light, It only really adapts itself during rebuild resulting in black spots on places that used to contain a mesh.:eek:

Jrubzjeknf
18th Oct 2005, 04:41 PM
well, if a mapper wants to make a shared jail an optional segregated one (to other who dont get that word: two jails using one volume), he should make it actually working.

Perhaps it's possible to modify meshes in a way that they dont show up in UEd, do a rebuild, then make them visible again? There shouldn't be a black spot then.

NEW IDEA (based on The_Head's new map with weapons in the shared jail): The_Head would like one team to blow the asses of the other team to pieces when they're being released. I could code support for that by recoding JBGameRulesProtection (with permission of the author of course), but I don't want all shared jails to have this feature. Having a variable bNoProtectInSharedJail (or something shorter :P) would making this feature optional, which would be perfect. My request is to add this variable to the JBInfoJail as well.

Sums up: new variables in JBInfoJail: bool bIsSharedJail, bool bNoProtectInSharedJail, name SplitSharedJailTag (maybe)

The_Head
18th Oct 2005, 05:01 PM
NEW IDEA (based on The_Head's new map with weapons in the shared jail): The_Head would like one team to blow the asses of the other team to pieces when they're being released. I could code support for that by recoding JBGameRulesProtection (with permission of the author of course), but I don't want all shared jails to have this feature. Having a variable bNoProtectInSharedJail (or something shorter :P) would making this feature optional, which would be perfect. My request is to add this variable to the JBInfoJail as well.
You say blow the asses off, more I want to be able to hit them with just momentum from a shock rifle but Same coding just a different weapon ;)
This is more a map specific thing, as my map is designed with this sort of idea in mind [I'll point out the version I have released at this point is quite different in respect to jail as the version Jrubzjeknf has at the moment, final version will have bits of both]

I would like to see an option for damaging people in jail incorperated to the original jailactor, but can be overiden by this addon.

On the point of Segregated jails, I don't recall seeing any jails that use this? which ones do?
I really can't see why a mapper would make a segregated jail, there are no benefits that I can see atleast.

INIQUITOUS
18th Oct 2005, 06:47 PM
you know i think thats why NoSense has that bug, that if one team is being released, you cant release the other team. i think its to do with the shared jails. ....

tarquin
19th Oct 2005, 02:30 AM
you know i think thats why NoSense has that bug, that if one team is being released, you cant release the other team. i think its to do with the shared jails. ....

You can't release one team while the other's being released? Sounds like a bug in the JBInfoJail to me.