OSMT Beta Testing

[SuperApe]

I had to fix a couple things with regard to monster team member navigation. I also broke some stuff in Patroling and Ambushing while cleaning the controller code, so I fixed that. I also noticed IceSkaarj wear armor and that SkaarjScouts needed more armor than 5 points to be effective at all. (AssaultRifle rounds do more than that) So, both have 10 armor now.

Full details and download link are on the development thread.

[SuperApe]

All team stuff looks ironed out, but needs testing. Check out the details on the development thread. There's a few neat suprises in these new features.

[SuperApe]

While helping Lord_Simeon with Wangara, I found a bug, that was actually in the original UT99 ScriptedPawn code as well. I remember seeing it and thinking it looked out of place, but I kept it just in case. Now I know it's just a bug. EDIT: Fixed.

Creatures set to Orders "Ambushing" should be associated to AmbushPoints, but unlike every other AI NavPoint, AmbushPoints were associated by matching it's Tag with the creature's Tag, instead of the creature's OrderTag. I know now that this is a bug because a) the OrderTag property is meant to associate the creature with the AI NavPoints it's Orders need, b) the OrderTag property is not being used by anything else in instances like this, and c) the Tag property on creatures is used all the time for other things, like triggering the creature.

So next update this fix will be included. So far, this is the only update I have to offer, so I'm not inclined to make a supplemental update just yet. But, it will be done.

In the meantime, the workaround is to match both the creature's Tag and OrderTag to the Tag of the AmbushPoint. You only need one, but later when I make the change, it will still work on your creatures. If you need to use the creature's Tag, like Lord_Simeon does, we can work something out.

[SuperApe]

This is an issue I've had to deal with in Gauntlet: trying to determine if monsters (or a specific monster subclass) are lurking around. In Gauntlet, I end up using this more and more as part of a technique to determine if it's safe to call an Objective "completed". Now, I'm thinking this will probably become a very common desire on part of the OSM mapper, if not in any other gametype.

Let's say you've got the Player entering a room and baddies jump out to attack. Further, let's say the mapper would like all the baddies killed before the Objective will be considered "complete" and the OSMObjectiveManager is triggered. This should be a fairly common situation in OSM. If all the monsters involved are placed, the mapper *can* simply set up the Event of all the monsters to match the Tag of a Counter. When the Counter reaches the last monster killed, it can trigger the Objective. I do this in the Krall "gong" room and in the Fly room in Gauntlet.

But, what if the number of baddies is unknown? For example, what if there is a good chance that baddies have chased the player to this area from another, or what if you are spawning the monsters (as I do in the Puzzle Contraption room in Gauntlet)? The Big Fire Pit room has a GiantGasbag that spits out smaller Gasbags at will; how do I account for all those baddies to be cleared?

My initial thought, and the way it has been designed to this point, is that I have a ScriptedTrigger scanning two TriggeredConditions. These conditions are bTriggerControlled and listen to two separate Triggers: one to see if a Player is around and one to see if Monsters are around. The ScriptedTrigger loops while checking to see that a Player *is* around and Monsters are *not* around before moving on and triggering the Objective as "complete". This part should be working fine. The problems start when I try to determine how to detect Players and Monsters.

To detect the Player, I need to know if a Player Pawn (xPawn) is around. However, because 'Monster' is a subclass of xPawn, I needed to get tricky otherwise both Monsters and Players count. I'm using a new Trigger in the OSMT toolset called the ExclusionTrigger. It will fire its Event unless the Instigator (the Actor that's Touching or Triggering the ExclusionTrigger) is of a class that matches the ExclusionClass setting. I set the ExclusionClass to 'Monster', and now the ExclusionTrigger can tell me if a Player is in the area. This seems to work fine.

To detect the Monsters, I've attempted a few different things, but have had no luck. This is where this design breaks down, but I'm not sure why. I have tried setting up a simple Trigger, set to ClassProximity with the ProximityClass being 'Monster' (I've also tried 'ScriptedMonster' and various subclasses of that). For some reason, this fails. In the code for Trigger, specifically in the ClassProximity code, I believe there is some mention that Pawn classes are checked to see if they are Controlled, are actual Players, or something like that (the code is not in front of me atm). I don't think that's the cause of the problem, but I really can't think of what *is* the cause of the problem.

This should be pretty simple: Tell a Trigger to turn on if a particular Class (or subclass) is within the CollisionCylinder. But, the fact that this isn't working, combined with the thought that this would become a very common query on the part of OSM mappers, leads me to wonder if I should make a custom Trigger to deal with this situation. So, I'm thinking about making either a MonsterTrigger, that specifically detects Monsters or a particular subclass of ScriptedMonster, or try to go ahead and make a "one-stop-shopping" PlayerOnlyTrigger, one that activates if a Player is around but is prevented from activating if a Monster is also within the CollisionCylinder.

Thoughts? Suggestions? Ramblings?

EDIT: PlayerAloneTrigger now available.

[outpt.co.uk]

Sleeping Skaarj - You can hit them from a distance and they won't wake up. They jump up and back down to sleep in a split second. Damage should wake em up. (There's always the argument that you can knock them unconcious! )

Monster Shield - Doesn't seem to work.

More soon

[SuperApe]

Originally Posted by outpt.co.uk

Sleeping Skaarj - You can hit them from a distance and they won't wake up. They jump up and back down to sleep in a split second. Damage should wake em up. (There's always the argument that you can knock them unconcious! )

Monster Shield - Doesn't seem to work.

More soon

Thanks.
I just saw the same thing happen with Krall Sleeping and Skaarj pretending to be dead. It's a fairly quick fix for both.
The Shield properties are xPawn (player) stuff. Maybe I'll try to take out a bunch of miscellaneous xPawn property groups so that ScriptedMonsters have more clean looking attribute editors.

EDIT:
I just went through the Unreal Creature Care and Feeding Guide and found several more things I can do before public release. Added all this stuff to the ToDo list at the top post. This will keep me busy for a little while.

[SuperApe]

There is a supplemental update (v0.993b) I released yesterday that addresses these issues and several other minor ones. A couple cool things in this update:

- Carcasses can be made pushable and damagable, if desired.
- A new PlayerAloneTrigger
- DrawScale automatically alters Mass, Health and CollisionSize.

Check out all the changes on my latest post on the Development thread.

Also, check out the current discussion going on at the OSM Map Pack thread regarding the scheduled public release date.

[Lord_Simeon]

Got the latest, i like the changes.

Here's a few ideas for the next.
Is there a way to disable the time limit alltogether?
Every now and then, i'll be in a matinee and i'll hear "5 minutes remaining" which is a bit annoying. I haven't messed with the obj times yet, they are all defaulted to 0, wondering if putting in 999999999 for each will fix this?

[SuperApe]

Originally Posted by Lord_Simeon

Is there a way to disable the time limit alltogether?
Every now and then, i'll be in a matinee and i'll hear "5 minutes remaining" which is a bit annoying. I haven't messed with the obj times yet, they are all defaulted to 0, wondering if putting in 999999999 for each will fix this?

There was some discussion about this early on on the public thread. First, that is a Player-configured game setting, a timelimit for the match, it is separate from the Objective timelimits mappers set. You can disable that by setting it to zero in the game menu. Setting Objective timelimits will not effect the overall timelimit of the match.

Earlier I wondered if we should allow the mapper to disable the timelimit altogther and the discussion finally let to the basic notion that if a Player *wants* to set a timelimit, the toolset should'nt prevent them from doing so. IOW, we should'nt take away a Player's game menu config item unless there's a good reason. Likewise, if a mapper has designed a whole map to be a timed adventure, this match timelimit should be available. At least, that's how I remember the discussion resolving itself.

Still, I understand your situation and would like things to be as clean as possible. As of now, the recommendation to mappers is to include a little info in the map description like:

Suggested MaxLives : 4
Suggested Timelimit : none

Having some time with the gametype and the OSMObjectiveManager's features, I'm wondering if we still need the game menu Timelimit. (IOW, will a
Player miss that setting if we take it out?) It seems all OSM could have no time limit and then mappers are free to set up Objective Timelimits as they see fit.

Btw, a "whole adventure" timelimit in that case would probably have to be a series of Objective timelimits when added together equal total timelimt, if one wanted to set up something like that.

[Lord_Simeon]

Sounds good mate, BTW i'm on track for another version before i go to work.
I haven't touched on Wangara1 much, but have Wangara2 almost finished and the level transition working well.
I'll YouSendIt later and provide a link before i go to work (damn)

[SuperApe]

After a little thought, I'm thinking that if we did take the game config Timelimit out of the options menu very few Players would complain (that's just my guess). And if mappers wanted to have a timelimit, as their adventure requires it, they can use the Objective timelimits or not or in some Objectives and not others; however they want.

If we took it out, the matches would always count *up*, as they are counting the ElapsedTime of the match. Once an Objective timelimit kicked in, it would start at the limit and count *down*, until either they ran out of time and the match ended, or they completed the Objective. When no Objective timelimit is in effect, the clock returns to counting *up*, as total ElapsedTime of the match.

Taking the match Timelimit out is no problem technically; it's just simple edit in the gametype code. I was just worried about taking away Player config options and getting complaints about that, but it seems that's a minor issue now that we have the OSMObectiveManager.

[Blitz]

How about this? Remove the TimeLimit as it is now and replace it with a percentage. Let them go from something like 25% up to 500% and then "scale" the objective times based on this number. That way the user can still control the pace of the game, but the time limits that were chosen by the mappers are preserved.

EDIT: Option 2 would be a "difficulty" setting that would let mappers adjust the time limits based on difficulty (as well as other things, like number of creatures, pickups, etc).

[SuperApe]

Interesting ideas.

Originally Posted by Blitz

EDIT: Option 2 would be a "difficulty" setting that would let mappers adjust the time limits based on difficulty (as well as other things, like number of creatures, pickups, etc).

Btw, right now, ScriptedMonster -> OddsOfAppearing (default 1.0 or 100%) will cause placed monsters to be omitted (random pct adjusted by game difficulty). I don't have any special control over pickups atm, but perhaps that's a good idea too. EDIT: Maybe that could be a good addition to ThingFactory? To spawn Pickups (or anything) or not based on Game Difficulty setting.

(This probably should continue on OSMT Discussion and Ideas)

[outpt.co.uk]

Originally Posted by Blitz

How about this? Remove the TimeLimit as it is now and replace it with a percentage. Let them go from something like 25% up to 500% and then "scale" the objective times based on this number. That way the user can still control the pace of the game, but the time limits that were chosen by the mappers are preserved.

EDIT: Option 2 would be a "difficulty" setting that would let mappers adjust the time limits based on difficulty (as well as other things, like number of creatures, pickups, etc).

First idea sounds excellent. The mapper would have his default time limits for objectives. If the player finds the game too paced or slow, he can bump them up a bit.

Difficulty settings forces a little additional work for the mapper - he'll have to test his objectives more to match the difficulty levels.

[Boreas]

Due to being very busy, I haven't had any time to beta test or map voor OSM. I will be very busy until the end of the month, and even after that, I'lll have a lot less spare time than I did before. I hope my spare time allows me to work with OSM somewhere during this summer