Random Objective Bongs.

[Radamanthus]

IT sounds like a great idea, mach! I believe something of the sort has been implemented already. It's called something like.. lag :p

No, seriously, though, it sounds awesome! promotes vigilant guarding (takinga leaf from Judge's book) as well as promoting thievery skills.

[Machine]

Would it be possible as a mutator FT? Have any of the Devs got any thoughts on this?

As for "not changing much" Of course it would, I would ghost far more if I knew I had the advantage of a little extra time to get away, I could wait until the guard looks the other way, grab and sneak off. I wouldn't be subject to the "Firebomb the objective pedistal".

At the moment It appears better to actually wipe out the guards than to outwit them :/

I'm glad so many people are in favour, Maybe we should get a dev in here to take a look over it?

[The_Judge]

Hey, if the delayed sound will make people ghost, then I say do it! It's getting kind of tiring to play CS instead of TUT.

[immortius]

You can do almost anything with a sufficiently complex mutator. Of course, that mutator may not be compatible with other mutators. Certainly adding a delay to the objective complete announcement would be possible.

I'm not going to do it though.

[Machine]

Where is mortal monkey when you need him?

[Firetiger]

The problem is when you can't access the struct that holds all the info about the objectives. Apparently there's no way to get around that. Here's a quote from the unreal wiki:

Variable is too large (xxx bytes, 255 max)
These occur when you try to access a data structure that is greater then 255 bytes from another object.You might only be trying to access a little bool but if that bool is part of an array of structs whose total size is bigger than 255 bytes then you're not going to be able to code stuff like:

bMyvar = otheractor.bigarray[i].bTheirVar ;

Without the compiler choking and giving that "context: variable is too large" error.

To work round this you can code a method into the object that contains the large structure that returns the element you're after.

Now, correct me if i'm wrong (and please do, because i've been stopped by something similar), I can't see how coding it this way is possible. There might be another ridiculous method, involving editing other things not even related to achieve the same result. But then, wouldn't it be easier to modify the original code?

Alright, about it not changing much, I still stand to my descision. I think the reason why DM is taking over, is not only because people need to in order to get by the camping, but because they can, it's easy, and it's definitely beneficial (and in lots of cases, fun, but i'm not going to get into that). I certainly wouldn't DM any less, because it doesn't change the fact that I can use one arrow, and permanently remove one guard life from the game. Not only that, but I can do it from a distance as well as from the safety of a dark shadow or a rooftop. Also I don't have to worry about getting in rooms packed with 3 guards, traps galore, some aimbot ai's, the doors blocked with objects+more guards, and the objective buried under a mountain of household objects. What happens if you run out of items? Sometimes it's hard enough just to get into the room (with people standing in front of the door and repeatedly closing it when you try to enter), much less getting the objective and escaping. Honestly, do you think a delayed objective sound would help thieves on gerome?

With good guards it's almost necessary to DM at least a little, but even when the opposing team is of average skill, it's too easy to wipe out the lives and finish off the humans.

And also, not long ago I was asking why everyone plays on brodys challenge, because there's no frob wakeup. I was told they PREFER no FWU "because it's easier to DM". It's obvious there are plenty of people who like the DMing, and this change is not stopping them from doing it anyway.

[Hybrid]

BNT and I were talking one time, and he found a nice way to at least lessen this problem, in a different way.

Remove the ability to pick up household objects. Seriously, what do they do? The only USEFUL reasons you pick them up are to stack on something, or to block an AI from going through a doorway (which is sort of like an exploit of game mechanics). It may add "immersion" and you could do it in Thief, but this is Thievery.

He even went so far as to say you shouldn't be able to pick up corpses. I disagreed about KO'ed guards, since it's favorable to carry them to safety (whatever that means for the team you're on), but what about the others? Only useful for more stacking.

Of course, I personally have no problem with DMing. It's usually a case of powerful players getting onto the same team.

[PhaeThorn]

Salsa, objective bling blang bong and stacking. They don't quite have a relationship in my opinion. The subject of the thread is the objective bong, not the stacking. Or am I wrong here?

Anyway firetiger, this will indeed help the thieves on maps. Maybe not on gerome, but that's not the objectives fault. That is a map design flaw.

[Hybrid]

No, you're right. But they're solutions to the same problem.

[Firetiger]

Not to hijack the thread, but a few months ago, I made an "antistak" mutator that causes any household items to bounce off the objective if they come into a certain radius (with twice the velocity). Bolts would disappear only if they were shot into a surface.

It never worked out because I couldn't access the objective list to find out which actors are objectives. It is available as a standalone actor if anyone wants to use it.

Anyway, back to the topic...

Anyway firetiger, this will indeed help the thieves on maps.

I didn't say it wouldn't help the thieves, but it's ridiculous to think that suddenly there'll be more ghosting and less DMing just because the objective alert is a little delayed. Heck, what are the chances that out of 3 guards camping an objective, not one of them will notice the objective suddenly disappear?

Now you might say this is for the guards who roam the map and ignore the objective, waiting for the alert. If guards can't know when the objective is taken, they'll probably stay near it, which means more camping, more DMing.

[Machine]

Heck, what are the chances that out of 3 guards camping an objective, not one of them will notice the objective suddenly disappear?

Errr, quite a large chance, maybe you play with more vigilent people. I think Judge and Bluerocks are the only 2 who would notice in my timezone.

I don't know the code for this at all, I've never really looked into it, but from experiance from other coding projects commercial and otherwise, there is ALWAYS a way, it might take a bit of doing / recoding but at the end of the day it's a computer... it can do whatever you tell it too if the value exists it can be read. Computers just do shit quickly. End. Nothing more to say.

Deathmatching is fun, it is useful, I'm talking about empowering the ghoster a little, no, you might not see a mass exodus of ex-deathmatchers hanging up the bow for the ghosters life. But the option is there... the game becomes deeper and more complex.

You know the best games I've played are the ones which are easy to get into, but when you look behind the scenes, theres so much complexity it's difficult, nigh on impossible to master...

[immortius]

Now, correct me if i'm wrong (and please do, because i've been stopped by something similar), I can't see how coding it this way is possible. There might be another ridiculous method, involving editing other things not even related to achieve the same result. But then, wouldn't it be easier to modify the original code?

How does the objective gui classes access the strings in the face of this problem?

[Aggamemnon]

Technically won't make a difference to any of the teams a hardcore DMer is on, since, they are gonna DM anyway, the timer will be back to basics.
Unless of course the ghoster just asks for a favour while they get in and out.

[Machine]

So, like the Guards, the thief operation becomes a team effort.

[Firetiger]

How does the objective gui classes access the strings in the face of this problem?

Aha I missed that function. In that case, it shouldn't be hard. (gee I must look stupid now)