I've been working on adding support to the stock Strategy02.dll for several BZC specific items. The biggy is using a Player life limit instead of Recycler existence to end the game. I've got this working but don't know how to handle Teamplay when a Player hits the end of his life...
Right now when someone dies I'm doing the following to 'NewPerson', the newly created Player.:
if((m_PlayerLifeLimit > 1) && (m_TeamLifeCount[Team] >= m_PlayerLifeLimit))
{
//move them, change them, forget them
Where.x = 5000;
Where.z = 5000;
Where.y = TerrainFindFloor(Where.x, Where.z) + 1.0f;
SetVectorPosition(NewPerson,Where);
SetAsUser(NewPerson, Team);
AddPilotByHandle(NewPerson);
MakeInert(NewPerson);
Unfortunately the part I like, the 'MakeInert', brutally assigns the person to Team 0 and a FIXME error is generated because there's nobody on Team 1. I'm pouring over the rest of the DLL but I don't see how the game handles something like someone leaving, which is basically what I want to do.
I'd prefer to just dump the player on Team 0, maybe give him a rubber band shooter for a weapon, and let him run around as a ghost, but not if it's going to generate an error.
Any of you DLL wizards have any ideas on how to handle this?
-Av-
Just kick em! :-D
Can you ban them just for the rest of the game?
I like the sound of this, one of the things I loved about bz1 was the staying alive, in bz2 dying is just a quick way to get back to base.
kicking/banning doesnt really work. What if the host dies first in a 3 way? that would ruin the fun for everyone else.
Trying to get the player removed from their command ability/team but still kindof a spectator.
How about giving him a new pilot body that makes it impossible to get in a ship? Or put him in a spectator body (invisible, powerless, untargetable, comes and goes like the wind).
And a zombie skin and sound FX :-D
Lots of such things have been considered (tombstones, angels, ghosts, etc..) It's the mechanics of making them inert that causes trouble. I don't want to generate any errors or such.
The 'dedicated server' part just makes them inert and calls it good, but for some reason it seems to cause errors for me...
-Av-
You can put them in a spectator body on your team and still have their player life expired.
Again, it's not the philosophy of what to do with them that's the problem, it's the code.
For example this doesn't seem to work right:
SetAsUser(NewPerson, Team);
AddPilotByHandle(NewPerson);
MakeInert(NewPerson);
As it is I get a FIXME error stating that a team just lost it's human. I don't want any FIXME's...
Maybe all I should do is make them inert and call it good...
-Av-
Maybe make them inert and then move them back to the correct team? Commanders would be problematic.
Kick them unless they are server?
Having a server on team 0 works for dedicated DM servers.
I believe MakeInert is for players joining a server to be made a spectator, not to be used in-game. Just spawn them an invisible spectator model that they can't hop or bail out of. I posted one awhile back.
It is a very strict command in my experience. It is used on the server if the server is dedicated. Not sure what sets that flag, perhaps a command line.
in theory u dont HAVE to make them inert. Just move/make them immobole/deadpeople, and remove their ability to command anything.
Oh is THAT all??? Well, why didn't you say so? :roll:
Seriously, it's harder to lock somebody down than you might think...
Any real solution ends up with them on Team 0, which is part of what "makeInert" does. Doing this to someone who had a Recycler is what generates the FIXME. I originally was just blowing up their Recycler and letting the stock code handle who wins, but this was shot down as it still uses the Recycler death to end the game.
So...
The real issue is what to do to get rid of the FIXME, which is going to be generated no matter what if the person who died had a Recycler. To me it looks like I have to get rid of that Recycler at the very least...
-Av-
I remember (and have) the first DLL copy with lives u gave me, it makes the player inert, so they cant command. You were weaponless and couldnt command, ur stuff appeared blue on radar, and u could still move around.
Doesn't help if I don't have the source code... which I don't. I haven't found a way to keep various variations of these CPP files. I guess I could copy them off to another folder, as they still open if I access them directly.
Anyway, blowing up the Recycler doesn't stop the FIXME, although it's kindof neat to watch...
***
As I said, if you take an active player and make him inert, or change his team, the "FIXME Active Team1 couldn't find user" error appears. I can't figure out what it takes to get rid of this error...
Making them Inert works great for the 'lockdown' part, and it can be done manually by putting them on Team 0 and taking away their sniper rifle, but the error is the big thing and I can't seem to get rid of it.
-Av-
Don't use MakeInert. Just make them impotent through other means, like I mentioned.
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 :P ), would be bad if they were the host, but the dll can detect that too.
There are lots of possible things.
(http://www.overminddl1.com/image_scripts/image_sig.php?type=ODL1signitures&image/sig.gif)
Generated by OvermindDL1's Signature Auto-Add Script (http://overminddl1.com) that OvermindDL1 did manually since Greasemonkey does not work in Firefox 3.1 yet...
BZ2 DLL can kick as of pb4a.
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. :evil:
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-
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.
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.
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... :evil:
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-
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.
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 :evil: ), but maybe a sissy ballerina in a pink tutu to give them added incentive to stay alive. :lol:
Hmmm, maybe as a Boid so they can fly above everything and watch. Just have to make them untargetable, etc.
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-
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.