New mod: Elimination (Beta21)/OA 0.7.7+

[dmn_clown]

Considering that your mod is the basis for the missionpack, yes it should be in the development section.

[fromhell]

ok it's in the development section

[dmn_clown]

The missionpack menu now calls the correct gametypes.

[dmn_clown]

gcc throws out a few complaints:

Code:

code/cgame/cg_main.c: In function 'CG_RegisterSounds':
code/cgame/cg_main.c:561: warning: suggest parentheses around && within ||
code/cgame/cg_main.c: In function 'CG_RegisterGraphics':
code/cgame/cg_main.c:958: warning: suggest parentheses around && within ||

code/cgame/cg_draw.c: In function 'CG_DrawDoubleDominationThings':
code/cgame/cg_draw.c:895: warning: suggest parentheses around && within ||
code/cgame/cg_draw.c: In function 'CG_DrawUpperRight':
code/cgame/cg_draw.c:858: warning: 's' may be used uninitialized in this function
code/cgame/cg_draw.c:912: warning: 's' may be used uninitialized in this function

code/cgame/cg_scoreboard.c: In function 'CG_DrawClientScore':
code/cgame/cg_scoreboard.c:195: warning: suggest parentheses around && within ||

code/game/g_main.c: In function 'SendDDtimetakenMessageToAllClients':
code/game/g_main.c:959: warning: implicit declaration of function 'DoubleDominationScoreTimeMessage'
code/game/g_main.c: In function 'CheckDoubleDomination':
code/game/g_main.c:1547: warning: implicit declaration of function 'Team_ForceGesture'
code/game/g_main.c: In function 'CheckElimination':
code/game/g_main.c:1695: warning: suggest explicit braces to avoid ambiguous 'else'
code/game/g_main.c:1717: warning: suggest explicit braces to avoid ambiguous 'else'

code/game/g_active.c: In function 'ClientThink_real':
code/game/g_active.c:1032: warning: suggest parentheses around && within ||

code/game/g_client.c: In function 'respawn':
code/game/g_client.c:524: warning: suggest explicit braces to avoid ambiguous 'else'
code/game/g_client.c: In function 'ClientUserinfoChanged':
code/game/g_client.c:1028: warning: suggest parentheses around && within ||
code/game/g_client.c: In function 'ClientBegin':
code/game/g_client.c:1321: warning: suggest parentheses around && within ||
code/game/g_client.c: In function 'ClientSpawn':
code/game/g_client.c:1370: warning: suggest parentheses around && within ||
code/game/g_client.c:1590: warning: suggest parentheses around && within ||
code/game/g_client.c:1639: warning: suggest parentheses around && within ||

code/game/g_combat.c: In function 'G_Damage':
code/game/g_combat.c:962: warning: suggest parentheses around && within ||
code/game/g_items.c: In function 'G_SpawnItem':
code/game/g_items.c:958: warning: suggest parentheses around && within ||

code/game/g_team.c: In function 'Team_TouchDoubleDominationPoint':
code/game/g_team.c:951: warning: unused variable 'player'
code/game/g_team.c:1030: warning: control reaches end of non-void function
code/game/g_team.c: In function 'Team_DD_makeA2team':
code/game/g_team.c:710: warning: 'it' may be used uninitialized in this function

code/game/g_team.c:1030: warning: missing return value

Yes I know that "suggest parentheses around && within ||" is harmless and can be ignored but it is best to make gcc happy.  When gcc is happy everyone is happy

Some of the error messages though are somewhat serious and shouldn't be ignored.

[sago007]

Yes, some of them are not very pretty (especially 'may be uninitialized' and 'implicit defined' the last one because I don't know exactly why it isn't defined).

The only warning that I ever noticed (and did something about) was a ' does not have the mathematical meaning'

However the parentheses around && I wont add until most bugs has been solved.

An example:

Code:

if ( (client->sess.sessionTeam != TEAM_SPECTATOR) && (!(client->isEliminated)&& (!client->ps.pm_type == PM_SPECTATOR) || 
		(g_gametype.integer != GT_ELIMINATION && g_gametype.integer != GT_CTF_ELIMINATION && g_gametype.integer != GT_LMS)) )

There are already so many parentheses that I hardly can see what it does. If I add more parentheses I cannot see what it does.

Now that I look at it: The above example might even need some cleanup, some tests seems to be redundant.

Then the bugs are solved we can add those parentheses.

By the way. I have gotten player spectating to work, fixed some spectator bugs, a LMS proximity mine bug and added possibility for missionpack weapons. So expect a beta within the next 24 hours.

EDIT: One of the s might be uninitialized was actually quite serius and could be triggered by any busy server administrator bu picking a wrong LMS mode

[sago007]

Beta 9 is up.

Changelog:
Reenabled spectator following when dead, now without score bug
Spectators can now use teleporters
Spectators can teleport though doors
Added a message to the client informing of the possibility to leave spectator mode by pressing USE_ITEM
Added cvars for all weapons but gauntlet
Added chaingun, nailgun and proxy mine launcher in missionpack
Solved the bot_min_players+no humans+forcejoin bug (I have tested)
Mines now work in LMS
Some code fixes incl possible pointer problems
You cannot loose points by killing yourself/team mates in Elimination/CTF Elimination warmup any more
Fixed an unknown problem (I could just see the code was wrong)

Added these CVARs to control ammo:
elimination_machinegun "200"
elimination_shotgun "200"
elimination_granade "200"
elimination_rocket "200"
elimination_railgun "200"
elimination_lightning "200"
elimination_plasmagun "200"
Only in MISSIONPACK:
elimination_chain "0"
elimination_mine "0"
elimination_nail "0"

On to bot coding...

this is great stuff sago007. thank you so much. i've been looking for a gpl-based team elimination gametype for a while. i even considered attempting it myself despite my almost total lack of c programming skills. you're a lifesaver.  :-)

I just saw your post on http://www.quakesrc.org yesterday.

[fromhell]

elimination_granade "200"

grenade

[dmn_clown]

I fixed the spelling issue (not committed).

domination point A when controlled by blue is showing both red + blue flags

(We need three point A models and three point B models, red, blue, and white)

[fromhell]

I'll get to it

EDIT: Hows this for font (Deja Vu Sans Fixed Bold) and size? Still working on this

[dmn_clown]

That's not bad, though maybe too angular, btw for the white skin it should probably just be somwthing like this rather than being full white:

Code:

{
	{
		map textures/effects/envmapdimb.jpg
		tcgen environment
		blendfunc add
	}
}

[fromhell]

almost done, just got a nasty poly on B to sort out

[fromhell]

OK !!

[dmn_clown]

Updated the bg_misc.c with the domination points

they are in models/dpoints/

[Kojiro_S]

Looking quite good, I have to say

[dmn_clown]

yes, but there is a nasty crash in the missionpack right now...

[edit:] it appears to be player model related :$

[sago007]

Beta 10 is up.

Changes:
build on SVN 625 + instantgib ammo bug from a later version
Fixed respawning flags bug introduced in Beta 9
Bots now actively try to capture points in Double Domination. They are still not that smart, so they might all try to get the same point.
Added oneway option to CTF elimination (using CVAR 'elimination_ctf_oneway'), so only one team can attack in each round.
Double Domination points are in the mod for people who test on 0.7.x

Both Oneway CTF Elimination and Double Domination has the same problem with bots. On my test map the bots showed extreme progress since Beta 9 in DD

[dmn_clown]

Both Oneway CTF Elimination and Double Domination has the same problem with bots. On my test map the bots showed extreme progress since Beta 9 in DD

Yes, but you've only addressed 2 layers of the 4 layer ai, so those problems should be expected.  You have botlib which is compiled into the client/server portion of the game, there is the portion in the vm, there is the fuzzy logic, which hasn't been touched, and the bots themselves which also haven't been touched.

Mr. Elusive's thesis on the ai might be useful for you:  http://www.kbs.twi.tudelft.nl/Publications/MSc/2001-VanWaveren-MSc.html

btw - I'll handle the bots and fuzzy logic

[sago007]

Mr. Elusive's thesis on the ai might be useful for you:  http://www.kbs.twi.tudelft.nl/Publications/MSc/2001-VanWaveren-MSc.html

That is interesting reading, I get a lot more understanding of the bot code just by looking at figure 5.2 compared to reading the code

[dmn_clown]

Yeah, it helped a lot when I was working on the fuzzy logic.

I am kinda hoping, however, that his comments in the code are far more helpful in Doom 3.

Also updated experimental binaries (that include your additions to botlib) will be in the svn soon.

[next_ghost]

I'm trying to make the warnings go away. Somebody please shoot the guy who made those damn

Code:

if( foo ) {
    if( bar ) {
        if( baz ) {
            do_something;
        }
    }
}

conditions. Is it really so hard to do this?

Code:

if( ( foo ) && ( bar ) && ( baz ) ) {
    do_something;
}

Edit: YEEEEAAAAAAARGHHH! STOP USING #ifdefs IN SO CRAZY WAY!

[dmn_clown]

//For double domination
   if (bs->ltgtype == LTG_POINTA &&
            bs->defendaway_time < FloatTime()) {
      //check for bot typing status message
      if (bs->teammessage_time && bs->teammessage_time < FloatTime()) {
         trap_BotGoalName(bs->teamgoal.number, buf, sizeof(buf));
         BotAI_BotInitialChat(bs, "defend_start", buf, NULL);

defend_start conflicts with another bot command, I'm changing that to dd_start.

[next_ghost]

OK, here's the parentheses patch. I've added parentheses according to C evaluation rules and split G_Damage into two variants to get rid of #ifdefs in the middle of code. I'm not sure how you meant most conditions to evaluate so I've added comments prefixed N_G. Two conditions were obviously wrong (also commented). If you find other wrong conditions, they do exactly the same as the original code.

[sago007]

defend_start conflicts with another bot command, I'm changing that to dd_start.

I think I will end up throwing most of the new bot code away anyway. It currently uses some short cuts to do it all on the upper layers. The leader commands need to be given at a higher level and analysed at a lower level no matter what, I also believe its the missing link needed to get the bots to take different Domination Points.

The chats commends will properly end up being: "dd_start_a" and "dd_start_b" etc. but I will need to look into it a little longer.

OK, here's the parentheses patch. I've added parentheses according to C evaluation rules and split G_Damage into two variants to get rid of #ifdefs in the middle of code. I'm not sure how you meant most conditions to evaluate so I've added comments prefixed N_G. Two conditions were obviously wrong (also commented). If you find other wrong conditions, they do exactly the same as the original code.

Yes there are clearly two errors if not three. Not game critically but after fixing them I can properly cut some redundant checks.

[dmn_clown]

split G_Damage into two variants to get rid of #ifdefs in the middle of code

You of course realize that by hastily removing #ifdef MISSIONPACK you are effectivily making the missionpack baseoa, something that we do not want at this point in time.

I think I will end up throwing most of the new bot code away anyway. It currently uses some short cuts to do it all on the upper layers. The leader commands need to be given at a higher level and analysed at a lower level no matter what, I also believe its the missing link needed to get the bots to take different Domination Points.

The chats commends will properly end up being: "dd_start_a" and "dd_start_b" etc. but I will need to look into it a little longer.

I'll wait then.

[next_ghost]

You of course realize that by hastily removing #ifdef MISSIONPACK you are effectivily making the missionpack baseoa, something that we do not want at this point in time.

I've moved the #ifdefs outside G_Damage, not removed them completely. Take a look at the patch.