vloup / sgfork Goto Github PK

Overall description of the new feature:
Everyone have to play with the same binary.
The check could be optional.
But that is important. We already have a lot of cheaters.

Variables to control the new feature:
To be figured out.

Overall description of the new feature:
During the games only some players are actually play and others are allowed 
only to watch.
Each time when someone leave the spectator may join the game.

Variables to control the new feature:
*g_activePlayersCount*?
(not sure)

Which game parts are involved:
binary?
No
game?
*Yes*
cgame?
No
ui?
No
media?
No

[deleted issue]

Overall description of the new feature:
Some variable which consists of list of allowed variables to be allowed to 
vote.
Not sure about realization.

Variables to control the new feature:
g_allowedVotes "map,kick,..."
(not sure about names)

To be removed.

In case if want to merge something from ioQ or other project uses MISSIONPACK 
stuff will just merge only required functions.
SG hasn't any mission packs.

Overall description of the new feature:
What about an option in callvote like (for BR-mode at least):
/callvote NewGame [mapname] [team_1] [team_2] [scorelimit]

when the vote passes, the server does something like this:
$teamname_A = Random([team_1], [team_2]);
if $teamname_A == [team_1] then $teamname_B = [team_2] else $teamname_B = 
[team_2]
/map [mapname]
/teamname_outlaws $teamname_A
/teamname_lawmen $teamname_B
/scorelimit [scorelimit]

this would also solve the issue of determinating who will be 
attacker/defender first
round

Variables to control the new feature:
Callvote?

Which game parts are involved:
binary?
N/A
game?
N/A
cgame?
N/A
ui?
N/A
media?
No

Two legshots from colt are not lethal.
And headshot from Remington should be lethal (or almost).

Right now it's not possible to pick up ammo and ammo-belt from dead players.

It happens right often that you run out of ammo when you are playing with
standard configuration (Remington pistol and Schofield due to 20$), since
you often need 6 shots to kill someone and most people miss more than half
the shots.


In terms of realism i would suggest to have also the unused ammo-packs (or
the ammobelt including the ammo if he had one) dropped when someone gets
killed.


Another nice addon would be the ability to drop ammo-packs for your
teammates (the number of bullets in those packs would need to be
determinated. In case of pistols, i'd say 6. In case of secondary weapon, 6
would be a nice value aswell i suppose).

Overall description of the new feature:
1) client-prediction-errors: it seems that the parts of the opponent's body 
displayed in console you appear to hit are predicted clientside, and that 
prediction seems to fail here and then, since the console-messages the 
opponent recieves, tells about different body-parts (e.g. my console said, 
i hit 3 times legs and one time stomache -- and the enemy's console said 3 
times stomache and one time leg) - i guess the
server sees what the wounded enemy gets displayed
2) probably unlagged-code didn't get implemented properly
3) Unlagged source must be added to third-party directory in source code!
4) Total review of implementatino according to Unllaged documentation is 
required!

Variables to control the new feature:
cg_drawSGbboxes <0/1> CHEAT

Which game parts are involved:
binary?
No
game?
Yes
cgame?
Yes
ui?
No
media?
No

Description:
    // A temporary solution to disable shadow projection bug
    // in the Quake 3 engine, as it is a form of cheating.
    if (cg_shadows.integer == 2 && !cg_cheats
    && CG_Cvar_VariableInteger("r_stencilbits") >= 4) {
        CG_Printf("cg_shadows: 2 -> 1\n");
        cg_shadows.integer = 1;
        trap_Cvar_Set("cg_shadows", "1");
    }
@CG_Player()

Seems the code is rudiment and some kind of hack.
To be removed?

Overall description of the new feature:
Each use have to fill the variable like with password required to connect 
to server.
Each server has some variable to check if password is correct.
This password required only to join the game!
For connection password is used.

Variables to control the new feature:
g_activePlayerPassword?
(not sure about name)
cg_activePlayerPassword?
(not sure about name and implementation.. I haven't seen the password 
feature)

Which game parts are involved:
binary?
N/A
game?
Yes
cgame?
N/A
ui?
N/A
media?
No

Overall description of the new feature:
In scoretable or somewhere else (including logs) player should have an 
opportunity to see own accuracy statistic.

Variables to control the new feature:
Not sure if any new.

Current realization is very slow.
FPS are down for 30.

Maybe it is better to do it as a decor? You hit some entity, it is removed 
and spawned another which is just animation.
Like rocket smoke in Quake, etc.
We need such stuff because it makes game more attractive.

Right now especially white letters are almost unreadable in final
scoreboard due to the sky being very bright.

I'd suggest to put a shadow or border around the letters in scoreboard to
keep them readable on any background.

Overall description of the new feature:
The anticamp patch should solve camp problems by checking if a player is in
the same area for x seconds and then damage him and tell him to stop
camping. Since you can camp in a building, that could be good to damage a
player if he stays in the same stage.
Since players movements are really slow in SG, time before people is
damaged would be increased if he is reloading, being hurt, shooting or if
they are ennemies nearby.

I already did a patch about it that is attached with the issue.

Variables to control the new feature:
g_antiCamp
g_antiCamp_radius
g_antiCamp_damage
g_antiCamp_bot
g_antiCamp_y

The price of the belt is pretty low compared to the costs of ammo.

In addition to #46 i'd suggest to NOT get additional ammo by buying the
ammo-belt. It should only increase the max. amount of bullets that can be
held at one time.

Possibility to choose team and enemy models.

To make Smoking Guns to be the first in UI games filter instead of ALL.

Like to make ui_serverFilterType.integer = 1 be default.

Not sure how to do it right, so the issue is opened.

Description:
@clientConnect()
    // Joe Kari: exec content of the onEvent_playerConnect_do cvar
    if ( firstTime && !isBot )
    {
        trap_SendConsoleCommand( EXEC_APPEND, "vstr 
onEvent_playerConnect_do\n" ) ;
        trap_SendConsoleCommand( EXEC_APPEND , va( "vstr 
onEvent_playerUpTo%i_do\n" , g_humancount ) ) ;
    }

Also a lot of redundant variables:
global g_humancount
humancount @ CalculateRanks()
CalculateRanks isn't the place to count "humans"

There is no point to check if it is bot or not since the variable is made 
for playercounting (including bots!). Maybe there is a reason not to count 
specs, but not bots since they are playing. And such variable is should be 
available for game module.
And moreover whole this thing is looks like dirty hack. Better to figure 
out other solution for a server to choose maps with dependence on players 
count. Maybe to store a players count or command which server may execute 
in its string.
Also such method isn't a secure one.

Description:
Without everyone /ready the match just in warm up stage. After everyone is 
ready the match will begin (after <n> seconds countdown).
Everyone who is ready has option to make himself /unready. But only during 
warm up stage! (so after everyone is ready and match started /ready and 
/unready are useless).

The pause command could be called by one of the players. When pause called 
the match is paused for <n> (a variable) seconds. The player who called 
pause may interrupt it by the same or other command.
Another possibility is to make this option as vote. So one player call the 
vote and others are confirm or not confirm it.
Better to do both possibilities controlled by server options.

Both options are not required on public servers where players come and out 
frequently. So it will be another BR mode or g_tourney option.

The future investigation is required before coding will started.

To allow server to set starting money, lose money, etc..

Overall description of the new feature:
Server have to write timestamp when each match is started.
Server have to write more detailed information about kills.

Variables to control the new feature:
None. Only logs

The game structure is the following:
./base: directory where all pks from now on are stored. Also default.cfg also 
is there.
<your home>/smokinguns - the dir where all your personal configs and logs are 
stored.

Overall description of the new feature:
Add to downloads section scripts required to convert SG 1.0 to SGFork.

Windows
Linux
OSX

The Client IDs in /serverstatus and /rcon status are different.

I believe that Client IDs from "/rcon status" can be used to perform a
correctly working /callvote clientkick [CLIENT_ID].

Whilest i know that Client IDs from /serverstatus reflect different ones
which will get someone random kicked when using them for /callvote
clientkick [Client_ID]

my suggestion is to adapt /serverstatus in a way, so that it displays the
same ClientIDs as /rcon status.


PS: /callvote clientkick makes it possible to get rid of lame players who
can't be kicked by /callvote kick [Name] -- and lately, you run into such
lamers on an almost daily base.

What about splitting the Makefile into different Makefiles for each part of
SG like game, cgame, ui, server & client ? That would decrease the size of
the main Makefile and make it easier to read and modify.

I also think that removing useless things such as mission pack will be an
interesting improvement.

Ressurect cg_hudFiles to make it possible for players to have their own HUD.

Overall description of the new feature:
typing "qboolean" to get a boolean is too long I think. I would prefer to
use "qbool" instead.

Description:
#ifdef SMOKINGUNS
        if(cg.snap->ps.persistant[PERS_TEAM] >= TEAM_SPECTATOR ||
            cg.snap->ps.stats[STAT_HEALTH] <= 0)
            cg.zoomed = qfalse;
#endif
@CG_CalcFOV()

To be moved to crosshair drawing with preventing of drawing scope?

The thing is used to prevent player from zooming while he is dead or 
spectating.
Both things actually are allowed. During spectate it is like zooming camera 
and during death it is just like focusing.
The only thing is that Zoom crosshair must be prevented during zooming when 
spectate and died.

Overall description of the new feature:
Each player have to know where is he.
It is done by location variable.
In vanilla Q3 we use weapons/powerups near to say the place.
There are must be some similar way to do it in SG.

Variables to control the new feature:
Player can say his/her location in chat like that:
say_team: I'm here #loc
(variations are possible)

I thought it would be interesting to improve server administration like
this : Typing '!command' in chat would execute a command if your admin
level is enough for this. Since it is boring to see people typing that, it
wouldn't be displayed on the screen for non-admin people.

The ioquake3-based game "Tremulous" already uses that system. Ennemy
territory too, but it's not free.

The ban-system shipped with vq3 is pretty weak.

I would suggest to try putting up a bansystem based on Guids.

A Guid-System would have been already implemented in Ioq3, so probably that
can be used in addition to the IPs (and IP-subnets).

Additionally it would be important to get a banfile implemented, where all
bans are stored (with comments, so that you know why the one got banned).

Overall description of the new feature:
There are more q3-commands in, which allow to add fancy visual
effects

what i like about SmokinGuns, is that everyone has to play with 90 fov - 
this adds some realism and especially fairness - but this has to be done 
consequently also with other settings (e.g. r_fastsky allows to make sky 
black)

in case you consider to remove ancient q3-variables which allow players to 
get advantage over others by dragging down realistic look, i will post a 
list of variables which could be considered to be either removed, capped 
into certain limits or locked

Variables to control the new feature:
r_fastsky
+any others?

Which game parts are involved:
binary?
N/A
game?
N/A
cgame?
N/A
ui?
N/A
media?
N/A

To remove g_red(blue)teamname.
The way how variable is used is ridiculous.
Emergency fix is to replace it temporary with g_redTeam and g_blueTeam.
And also in UI they will be temporary shown as blue and red.
Later we'll review the code from mission pack for different teams and just 
will use that way (with one team only instead of 5 as it done in mission 
pack).

Current teamnames are kinda broken.
You see in UI ones and in game others.

Also we have a lot of places where used mission pack stuff (when you can 
choose name corresponding to your team (one of 5 possible)).

The goal to have good team naming mechanics.
Maybe we allow player to choose his clan tag and if everyone in his team has 
the same tag we rename the team name. Otherwise the teams stays as "Red" and 
"Blue". There is no trouble with it.
Or to make this thing voice.

Overall description:
Removing single player mode could be a good idea since it will reduce code
size for a thing that is only a copy of multiplayer mode with bots.
Then, we could write later a campaign mode or something that follows that idea.

The possibility to have each game automatically recorded and to have 
screenshot after each match.

In current code color1 and color2 are disabled.
Instead is used just some color.
To be resurrected.

To make crosshair changeable.

The size, the shape, the color and transparency are required!

In most other mods there's a command named /tell existing.

It follows following syntax: /tell [Player_ID] [Text]

[Player_ID] .. is the player's ID found in /rcon serverstatus

The command allows you to talk to someone on the server in private (noone
else but the chosen player (playerid) will recieve your message). By
Default, this message should be displayed in pink (to go conform with other
mods).  Probably it would additionally be possible to add a " (prv)" like this:
-nox-Thot- (prv): TEXT TEXT TEXT

---

Please also put into consideration, that you need to adjust the function of
deathtalk etc. - to be more precise:
- when deathchat is disabled, also private chat shouldn't be possible with
alive-players when you are dead or in spec


Addon for Competetive games:
a serverside variable that - when enabled - only allows private chat with
own teammates (so specs can only talk to specs in private ... team A only
to team A .. team B only to team B)

Overall description of the new feature:
Current HUD is hardly hardcoded in SG code.
We need to make in very-very configurable.
Like you may edit/create your own HUD ui file with your description and 
you'll get the new HUD.
You may decide where and how to draw one or other thing.

Variables to control the new feature:
The HUD one.

Overall description of the new feature:
teamChat - messages from opponents are written only in console! No 
beeps/showing on the screen.
(Current one are not working when your teammate is dead (his team is 
TEAM(BLUE/RED)_SPEC))
SpecsChat - messages from spectators are written only in console! No 
beeps/showing on the screen. But every message can be read in console 
later.
ChatBeep - on/of sound when message received.
Current variable dead_talk (not sure about name) doesn't stores chat logs 
anywhere. Maybe it is possible to store them somewhere.. To be able to read 
them after round/match ended. OK about other team messages - they are 
private, but NOK about spectators messages. Also I insist on renaming the 
current variable. Its name is not obvious. deadTalk or something similar 
would be OK.


Variables to control the new feature:
I'm bot sure about names.. And not sure that it is cgame part and not 
binary.
(the value is default one)
cg_teamChatOnly 0
cg_specsChat 1
cg_ChatBeep 1

Which game parts are involved:
binary?
N/A
game?
N/A
cgame?
N/A
ui?
No
media?
No

Overall description:
It is possible to do the following in SG 1.0:
\callvote g_doWarmup 1;g_readteamname 11;g_blueteamname 10;scorelimit 4;map 
br_alamo_tiny

But the scorelimit, g_readteamname and g_blueteamname are forbidden to vote 
in game code.

The similar is allowed in SGFork:
\callvote g_redteam 10;g_blueteam 11;scorelimit 5;map br_alamo_tiny

scorelimit isn't in available votable variables.
You can vote via this trick anything you want.

Checked only in offline game with bots. But the code is the same for real 
players too.

And the code has the check:
    // make sure it is a valid command to vote on
    trap_Argv( 1, arg1, sizeof( arg1 ) );
    trap_Argv( 2, arg2, sizeof( arg2 ) );

    // check for command separators in arg2
    for( c = arg2; *c; ++c) {
        switch(*c) {
            case '\n':
            case '\r':
            case ';':
                trap_SendServerCommand( ent-g_entities, 
"print \"Invalid vote string.\n\"" );
                return;
            break;
        }
    }
Variables affected:
void Cmd_CallVote_f( gentity_t *ent )

Overall description of the new feature:
I propose to place everything that is constant in only one header, so you 
don't have to use 'grep' to know what are the values of a thing. You also 
don't need to open a lot of files since you open only one.
This also a way to help people who don't really knows how to code to create 
a mod.

I already did a patch for it a month ago for release 229 of branch 1.1 of 
SG. You can find it as an attached file.

Overall description of the new feature:
You type (if you are server):
mute <playername> and he is muted.
unmute <playername> and he is unmuted.

The variables are votable.

Variables to control the new feature:
g_allowVote_mute <1/0>
g_allowVote_unmute <1/0>

You hit shoulder and get headshot.. Something wrong with it.
Could be models trouble as well.

STANDALONE definition
What it should be like?

Current one is confusing.

STANDALONE means in ioQuake terms that game won't use CD key checking and 
will use own auth server.

In SG we don't need the non-standalone features, but still may left them for 
compatibility with ioQuake source.

We have to choose: to remove or to leave.

It would be interresting to have a support for SSL in client and server so
rcon password and messages would not be transmitted as a plain text visible
for anybody.

Google code accepts only CC BY-SA or CC BY license for separate contents.
It is not compatible with SG license.

That's why I think that we should remove any separate contents from the
reposistory ;-).

Since it is boring to type all the commands to generate pak2.pk3 and
install it, I propose to do a script that does it.

I placed the script as an attached file.