vloup / sgfork Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/sgfork
License: GNU General Public License v2.0
Automatically exported from code.google.com/p/sgfork
License: GNU General Public License v2.0
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)
Original issue reported on code.google.com by [email protected]
on 26 Aug 2009 at 10:45
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.
Original issue reported on code.google.com by [email protected]
on 24 Aug 2009 at 7:35
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>
Original issue reported on code.google.com by [email protected]
on 29 Aug 2009 at 8:34
You hit shoulder and get headshot.. Something wrong with it.
Could be models trouble as well.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 5:02
[deleted issue]
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.
Original issue reported on code.google.com by [email protected]
on 23 Aug 2009 at 2:30
Attachments:
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).
Original issue reported on code.google.com by [email protected]
on 23 Aug 2009 at 11:31
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.
Original issue reported on code.google.com by [email protected]
on 23 Aug 2009 at 7:01
Attachments:
Possibility to choose team and enemy models.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 9:43
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
Original issue reported on code.google.com by [email protected]
on 23 Aug 2009 at 6:37
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.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 6:20
To make crosshair changeable.
The size, the shape, the color and transparency are required!
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 9:42
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.
Original issue reported on code.google.com by [email protected]
on 26 Aug 2009 at 10:52
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?
Original issue reported on code.google.com by [email protected]
on 20 Aug 2009 at 3:19
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
Original issue reported on code.google.com by [email protected]
on 23 Aug 2009 at 2:08
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 20 Aug 2009 at 6:18
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.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 3:05
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.
Original issue reported on code.google.com by [email protected]
on 23 Aug 2009 at 7:43
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.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 5:00
Overall description of the new feature:
typing "qboolean" to get a boolean is too long I think. I would prefer to
use "qbool" instead.
Original issue reported on code.google.com by [email protected]
on 24 Aug 2009 at 12:49
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 ;-).
Original issue reported on code.google.com by [email protected]
on 19 Aug 2009 at 12:14
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
Original issue reported on code.google.com by [email protected]
on 23 Aug 2009 at 6:07
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.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 2:57
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.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 10:49
Ressurect cg_hudFiles to make it possible for players to have their own HUD.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 5:10
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.
Original issue reported on code.google.com by [email protected]
on 27 Aug 2009 at 11:46
To allow server to set starting money, lose money, etc..
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 9:44
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
Original issue reported on code.google.com by [email protected]
on 23 Aug 2009 at 6:02
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.
Original issue reported on code.google.com by [email protected]
on 23 Aug 2009 at 8:41
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
Original issue reported on code.google.com by [email protected]
on 23 Aug 2009 at 7:42
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)
Original issue reported on code.google.com by [email protected]
on 23 Aug 2009 at 7:23
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.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 2:10
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.
Original issue reported on code.google.com by [email protected]
on 19 Aug 2009 at 6:16
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)
Original issue reported on code.google.com by [email protected]
on 23 Aug 2009 at 7:15
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.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 9:57
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
Original issue reported on code.google.com by [email protected]
on 23 Aug 2009 at 7:00
In current code color1 and color2 are disabled.
Instead is used just some color.
To be resurrected.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 6:17
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).
Original issue reported on code.google.com by [email protected]
on 27 Aug 2009 at 11:56
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).
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 5:31
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 )
Original issue reported on code.google.com by [email protected]
on 31 Aug 2009 at 6:52
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
Original issue reported on code.google.com by [email protected]
on 23 Aug 2009 at 6:54
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.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 3:02
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.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 9:40
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.
Original issue reported on code.google.com by [email protected]
on 27 Aug 2009 at 11:59
The possibility to have each game automatically recorded and to have
screenshot after each match.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 10:14
Overall description of the new feature:
Add to downloads section scripts required to convert SG 1.0 to SGFork.
Windows
Linux
OSX
Original issue reported on code.google.com by [email protected]
on 23 Aug 2009 at 7:30
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
Original issue reported on code.google.com by [email protected]
on 23 Aug 2009 at 7:07
Two legshots from colt are not lethal.
And headshot from Remington should be lethal (or almost).
Original issue reported on code.google.com by [email protected]
on 21 Aug 2009 at 5:01
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.
Original issue reported on code.google.com by [email protected]
on 29 Aug 2009 at 6:15
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.
Original issue reported on code.google.com by [email protected]
on 20 Aug 2009 at 5:02
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.