DLL wizards? OM in the house?

[Red Devil]

Don't use MakeInert.  Just make them impotent through other means, like I mentioned.

[OvermindDL1]

First of all, a Fixme needs to be reported to GSH as that means it is a known bug and needs to be fixed, if it is something that should not be done then it should actually error out in some way, either way that needs GSH to fix.

Second, every player has to have a valid team number, and no team number can be used by multiple humans at the same time, thus you cannot have 'real' spectator type people as they will always be taking up a teamslot that may be required for main gameplay.

Third, I would say to just replace them with some kind of dummy odf, a spectator ship or something with infinite health, no ammo, and no collision.  In the dll you can easily flag that team (until the player leaves, then clear the flag, maybe record their name in case they rejoin, or IP or something) who is a spectator and just kill them if they somehow bail or what-not their vehicle and etc... recreating them.  Or you could just kick them from the game nice and simple (probably a console command for that or something).  I could certainly think of a dozen ways to irritate someone enough to leave otherwise.

Fourth, you could just do something like have the dll bounce them a few tens of thousands of feet in the air and keep them there, spinning or something (just to make them sick enough to leave), while having the dll keep their ammo at zero and health at full, while just keeping that happening anytime they bail or something, that would make them rather non-game affecting.

Fifth, if you really want someone to be kicked from the game, could always just kill it with exit(), abort(), or std::terminate() (depending on how ugly you want the programs death to be ), would be bad if they were the host, but the dll can detect that too.

There are lots of possible things.
Generated by OvermindDL1's Signature Auto-Add Script that OvermindDL1 did manually since Greasemonkey does not work in Firefox 3.1 yet...

[Nielk1]

BZ2 DLL can kick as of pb4a.

[Avatar]

I think in this case the FIXME isn't something necessary for GSH to fix, as it's me doing something incorrectly in the DLL.  There are tons of things a newb like me can do via DLL to break BZ2 and we can't have GSH trying to fix them all...  it'd be a lifetime job.   

So, you can't have more than one human on the same team?  Does that mean co-op modes are done through allying?  When the game shows four people on Team 1 and four on Team 2 they're actually all on different team numbers still?  That hadn't occurred to me... 

Kicking was considered but that just has them rejoin with a fresh set of lives.  I don't know how to track people coming/going, and so far are just going by team slots.  If Team 3 uses up his 2 lives and leaves the next guy that comes in on that Team is also used up.  Rather than kick them immediately I'd rather just let them run around without being able to affect the game...

The big drawback concerning leaving them on their team number is they could still be handed units from an Ally.  Hmmm....   well, I'll try it the long way around...

-Av-

[mrtwosheds]

It would be acceptable to lock the game at start to prevent rejoining, (assuming the little bug that lags players out is fixed),
Then those who are in it at the start fight until 1 team has 0 players, command could be passed by dll to the next man down in the player list.

[shane ward]

Why not just have the player spawn in the area that he died, then if he is half way across the map, and gets killed instead of him having a easy way home, he gets spawned in the location he died and has to walk home. With just a pulse gun like before.

[Avatar]

First off the intent of this is to duplicate BZ1 style within the limitations of the BZ2 engine.  That means for the most part it's intended for up to 4 on 4 play.  No need to worry about handing off Command, although the server model BZ2 uses means the Server shouldn't be booted from the game.  Sure, it'll hand off the server but you want the best internet host for the game, not somebody on dialup... 

I started from scratch and have a working model, one that actually works while giving me a chuckle.

I pretty much took a page from the Pandemic programming methodology...   subtle and minimal is better...

If you leave the lives limit at 0 the win is the BZ2 way, the Recycler being destroyed.

If you make a lives limit it counts by Team how many times you die.  When you exceed the limit you're respawned as a 'deadperson', the odf of which is team specific.  That way the ODF maker can determine what happens when you die...  (angels, anyone?)

If that ODF doesn't exist you become a Jak Killer.  Works slick and, as I said, gives me a chuckle.  Oh, and after that your Recy/Factory/Armory blow up a few seconds later.

GBD wants me to take out any silos and scavs, too, but that will come after this one is tested.

Seems to me this is the best solution.  The Player stays in the game (in case he's hosting or, if wanted, commanding) but can't make anything or snipe anyone.  With the right ODF he can't even move (back to tombstones).  He can still be handed units but again, depending on the 'deadperson' odf, he probably can ONLY hold them (might have to clear navs, also).

-Av-

[General BlackDragon]

Right. The reason I wanted to clear their silo's is because allied scavs can still dropoff at them. Not sure if thats a good thing or not.

[Red Devil]

Lot easier that way, ain't it?  A pilot can be set to any ODF depending on conditions you supply.

Might not want to set them as a Jak (although it is cool ) because then they might be able to kill other pilots (which would be cool for you  ), but maybe a sissy ballerina in a pink tutu to give them added incentive to stay alive. 

Hmmm, maybe as a Boid so they can fly above everything and watch.  Just have to make them untargetable, etc.

[Avatar]

I couldn't get the Jak to attack while I was in one...  tried every key I could.

The Jak is just a placeholder, the idea is to have a default and then make race specific ones work if they're available.  I've been asked several times to keep the code as generic as possible, which is why it has other non-BZC specific features such as different animation support and building-specific undeployment time.

I'm partial to making them 'angels' myself, complete with white wings and harps.  The harp could be a weapon that plays music, which is as annoying as they'd be able to get...

Otherwise I have in mind locking them into tombstones and making a graveyard.  That suits my tastes as well...

The only other big issue is whether or not to try to block their being handed units.  I have in mind 'unallying' them 10 times a second to block this... as I can't think of any other way.

So, they can't shoot, maybe can't move, can't receive units, can't get in a unit, won't have Production Units, could maybe control a GT if they had any left, and will still be attacked and killed if they approach an enemy which will limit their ability to play 'spy'.  (tho this could be used to distract a GT or two...)

Best I can do, I think.  Seems to be working for GBD so he's got a new toy to test.

-Av-

[Nielk1]

OHHH, I forgot about that one!

I don't like blowing up the rec/factory at all!

I personally like having the most options, so I would have like 3 options.
I would have the lives be team set as you have them for game loss, but with a few small weeks.
#<= 0, Rec death = game over
change # to absolute value after this check
# > 0 That number of team deaths game over

Then you can easily have team deaths AND Rec loss.

Then I would put in player deaths as an option, defaulted to 0, that does the following:
Perform normal team death operations, then:
reduce the player's lives, if they are out, kick them, but allow rejoin (I think a commander can rejoin in bz1, not sure)
If the player is server, force him into a GT. Do something so when he hops out, or fires a special weapon (DLL trigger mine) or the GT dies, he gets thrown in another one.
This makes it so although the server cannot quit and rejoin as others might, he can still shoot and perhaps command some units. He should keep his normal Give/Take command abilities.

If there are no allied GTs, throw the user into either a COM (not very fair), or an invisible, un-hittable, un-killable, un-ejectable, unhoppoutable, unANYTHING! GT a short height over the REC (and if there is none the nearest ally (keep moving him) and if there is none the start point) until a normal GT becomes available.

If the above occurs and there is no one else on the team, the team should loose, since everyone has officially expired.



In the above system, the most options are provided while likely causing the least programming grief.