jdolan / quetoo Goto Github PK

It'd be nice if the game module couldn't hose up the server representation of each entity so easily. At the very least, for readability and maintainability, we should encapsulate the first fields of g_edict_t in an sv_edict_t.

Add a water splash effect for when rain hits the ground, and for when players enter or leave a body of water.

It'd be great if http://ci.quake2world.net included a manual build for Clang static analysis. I've run into issue producing this report from Clang on OS X, but maybe it's easier on Linux.

Just an idea but I find that without ncurses, console output is hit-or-miss and there's no way to input commands into the console. Might be a good idea to have ncurses-dev as a requirement for server builds

As the title says, get the info avalible

I remember this being suggested but didn't find a ticket for it. Mostly for those who are barely meeting requirements and/or for competitive players :rolleyes:

artwork plzkthx

kill - kills the specified client, special case "kill all" for bastard admins kick - extend kick to imply a 30m or so ban mute - mutes the specified client until they are unmuted

added private messaging in R1118: /tell

configure summary is incomplete
see: http://ci.quake2world.net/job/quake2world-master-mingw32/lastBuild/console

Title says it all. Have speed of hook and player hook speed variables to a server-side cvar (speed of which hook travels to wall and how fast player moves once grappled). Also server side cvar for enabling/disabling hook, default disabled

Marks (like blast from rocket launcher/explosions/shots/burns), don't follow moving objects (like platforms). This leads to awkward burn marks in floating space, when the platform moves away.

The lift platform in torn is a good place to look at this

Game-specific CVAR_INFO variables (e.g. color) should be moved to cgame.

There are some sound artifacts for loop / ambient sounds. The weather and misc_emit sounds on Torn Glory are adequate for reproducing this.

The title says it all. Would be cool to have a handicap feature to allow people to play against others who are on a different skill level. I can't play some of my friends because it makes no sense dut to our differences in skill (match results are usually something like 30:0).

How handicap works: * each player has a handicap value that he can set in his config. It defaults to 100. * the weaker player does nothing (so he has 100) * the stronger player specifies a lower handicap value (like 70). This affects (weakens) him in several ways:

he starts with <handycap-value> health instead of 100
he can't pick up more than <handycap-value> health with normal medkits (but more with +5 bubbles and MH)
if he hurts another player, he only does <handycap-value>% (per cent) of the normal damage 

There's no need to implement all of these (and others may also be introduced, of course), but a feature that does something similar to the things described here would allow me to attract a few of my friends to q2w. :)

Changed 14 months ago by jdolan

owner changed from jdolan to wickedshell
status changed from new to assigned

A userinfo cvar on the client could set this for the server, and the game module could then honor it in G_ClientRespawn_.

make ammo boxes explode simmilar to q3 alternativefire http://www.satgnu.net/files/quake3/alternatefire/ammo.html

Lighting and texture alignment, especially for non-axial surfaces, is not very reliable at all. This could have something to do with negative angle values?

Changed 15 months ago by jdolan

priority changed from major to minor

Downgrading to minor. There are only two instances of this on all of our maps (Aggressor and Fractures each have one -- both on similar sloped-ceiling brushes. It's possible to work around the problem by adjusting the textures in Radiant, so I'm not sure we need to focus on this bug right now.

..... and display neat progress bar and stuff

The game module has MySQL spaghetti code throughout it. Let's try to consolidate it, and make sure that it works and is documented correctly. We should also make sure we provide a valid schema / ddl to seed the database.

Changed 14 months ago by wickedshell

Is there an old schema sitting somewhere that I can use as a starting point, or should I be figuring it out purely from the code?
Changed 14 months ago by maci

IIRC, the schema back then was not quite optimal either. I think it makes more sense to design a proper schema without redundancy etc and then change the code.
Changed 14 months ago by jdolan

The base schema was ..eh; what was missing was some temporary cron-rebuilt tables for providing fast aggregate views (heh, if only proper views didn't perform so poorly in MySQL). Also, I'm not crazy about the fact that I didn't use numeric pk's for the player table. That should probably be rethought.

The old schema and PHP scripts are kicking around in stats/trunk. Note that I wrote all of that like 10 years ago for Quetoo; it is likely very, very bad.
Changed 13 months ago by jdolan

priority changed from major to minor

It would be nice to be able to get textures to behave like sprites using either the material definition or a surface flag. This could be useful for sfx like flares or background/small details.

An additional feature that would be nice to have a special sprite function that restricts the sprite's rotation to its longest axis, similar to what 'deformvertexes autosprite2' does in q3 . This is especially useful for things like long animated energy beams.

Q3map2 shader manual entry for autosprite2: http://q3map2.everyonelookbusy.net/shader_manual/ch2.htm#deformvertexes

Vertex deforms have been a // TODO: for quite a while. I'll try to get these done for the beta.

Bans certain weapons from play. Any weapon banned will not spawn in map once map/server is reloaded and all ammo related to that weapon also does not spawn. Good for Rocket/Rail Arena and Freezetag railgun-only modes

dodsoN made a suggestion to have a Duel mode, whereupon you join the server, you either join into the game, are set in spectator mode, or in the queue. Two players duel until one loses (timelimit) and the next person in the queue joins in (no map change) and the loser goes to the back of the queue. If you do not join the queue, you are always spectating. To join the queue, type /join (or something along those lines) to be entered to the end of the queue. Maybe even something you click on to join the queue, like holding down tab to see the scoreboard and have a Join Queue and Leave Queue button?

Static limits:

timelimit to 15 minutes

2 players max playing at once (everyone else spectates)

Lowered ammo limits to all guns (50% less ammo on all guns except for Rocket Launcher and Railgun, which are reduced to a maximum of 20 rockets / 10 slugs

this would be so much fun. for example: changing gravity for just one room

The protocol version should have a minor revision as well as major. Upon challenge/connect, the server should transmit the full string. The client can then compare and issue a warning if a difference is found.

This is a "nice to have" before a general public release is made.

Changed 6 years ago by jdolan

status changed from new to assigned

Changed 4 years ago by jdolan

type changed from task to enhancement

Changed 15 months ago by wickedshell

Can this just be to take the existing protocol cvar/varaible/define and say that the last 4 digits are the minor version? IE 130034 would be Major version 13, minor version 34. Or do we want a whole additional define & sending of it? I'm willing to do it either way if you want me to.
Changed 14 months ago by jdolan

status changed from assigned to accepted

This is a good idea (the larger protocol number). I'll start enforcing this at the next protocol change.

The following list of game specific things should be broken out into cvars that allow the server operator to control settings. This is a more full list then #209. We may not want all of these
-g_respawn_protection - default 0 - protection from inital damage after respawning, the value is delay before damage
-g_rounds - already exists but very buggy and doesn't work right (ammo spawns, and what to do when in DM for example).
-g_deadchat - 0|1- default 1 - whether dead players can type to live ones (mostly intended for conjunction with g_rounds and competitive play)
-g_deadhealth - 0|1 - default 1 - tells a player the health/armor of their killer

Clients should be able to set some specific to themselves as well
-cg_autoswap - 0|1|2 - default 1 - swap weapons on pickup according to the best weapons list on the server (1 being the server list, 2 being always swap to last picked up, probably not a popular option but might as well have it as one)

Changed 13 months ago by jdolan

g_spawn_protection Should introduce a new shell effect (yellow?) 

g_rounds Actually is (and should be) independent of g_gameplay arena, which will disable item spawns -- so I don't think this is as much broken as it is just missing countdown sounds and other queues. 

g_spectator_chat Good idea, we should leverage the team chat facilities for this. 

g_show_attacker_stats Also a nice idea. 

cg_switch_weapon I'm less inclined to care about this one, let's treat it as lower in priority than the rest. 

Changed 13 months ago by wickedshell

r1635 provides g_show_attacker_stats (which is a much better name then g_deadhealth) currently only provides health/armor of the attacker as we haven't built up any more complicated stat logging.
Changed 13 months ago by wickedshell

r1637 g_spectator_chat, renders dead_chat uneeded

r1642 g_respawn_protection defaults to 0, takes seconds

The console-based loading screen is really dated and unattractive. We should have a pretty progress bar, centered, with a series of randomized background images. Users should be able to hit ESC to abort loading.

The renderer in the experimental branch is hemorrhaging 200-400MB per map load. Most of the memory can be reclaimed / freed by r_restart. Valgrind confirms that we're not actually leaking memory (i.e. there are still valid pointers to it -- somewhere); we're just retaining more resources than we should. This is puzzling, because z_size reports that most maps use less than 50MB of memory in total -- so why is Q2W using > 550MB at all times? Puzzling indeed.

instead it should rsync to the target created by 'make install'

cl_chathud 1 will make all the chatter go into a seperate area in the HUD, for easier reading. Optionally, you could add: cl_chathudtime to set the number of seconds a message stays in the chathud cl_chathudlines to set the amount of lines the chathud uses

Here you can see cl_chathud 1 and cl_chathudlines 3 in action in AprQ2. In case you was wondering, the chathud is located in the lower-left corner of the screen.

Changed 14 months ago by jdolan

owner changed from jdolan to wickedshell
status changed from new to assigned

This could actually be implemented rather easily now in the cgame module.
Changed 13 months ago by wickedshell

associated with this should also be a cl_chat_time that dictates how long text stays on the screen, currently scrolls off to rapidly, requiring lots of console checking
Changed 10 months ago by jdolan

I'd like to make this the default (read: only) behavior in the cgame. Basically, we should move the Cl_DrawNotify stuff to the cgame. The notify buffer can be populated via Cl_ParseServerMessage, and then rendered by the cgame. Any cvars that control the visibility or placement of the notify buffer should be cg_*. I'm looking at line 425-ish in cl_parse.c.

Some players prefer to hold down a key to see the scoreboard, and release the key to make it go away. I think we could accomplish this by adding a +score command in the game module.

It'd be really nice to offer a dedicated server binary for Linux that includes all of the required libs and uses LD_PRELOAD or something to make it a universal, drop-and-go install. Maybe what we really want to do here is add some library discovery / bundling magic to the existing Linux build so that we can provide all of our Linux builds this same way. Currently, the Linux build assumes that users have or can install a compatible version of libSDL and libPNG. It'd be great if instead our Linux builds were self-contained, self-reliant bundles.

Moving pmove to game / cgame would allow mods to implement their own player movement code, ala Quake3. The most difficult part in doing this is moving or splitting up the client side prediction code.

It would be incredibly useful to accumulate kill locations for each level, and allow designers/developers to load this information in the client to revise item placement and layout issues.

One option would be to include this information in the MySQL frags table; but a tool would be required to export the table data into a file format which the client could easily load for rendering the frags.

Ideally, the server admin would set e.g. sv_fraglog 1. The server would dump all new frags to a file, e.g. default/fraglogs/$map.log. The designer could retrieve this file and load it in their client, e.g. fraglog $map.log. The client would render frags as particles or even just points.

The client should be able to from a menu run the rsync update and pull all the update data. This would vastly improve user experience, and make it smoother.

Once this is done, it's worth considering compiling enough assets in (mostly a(the?) default font), so that a simple GUI saying "No game data, do you wish to update?" Could be displayed. That's probably a separate task issue though, just where I'd like to take this once this is done.

add things like:

water pit jumppad doors stairs several ways to die switches with several triggers

that way it is easier to test changes to the gamecode and see the immediate effect

Phong shading is difficult to do in software. We'd get much better looking results by simply calculating lighting values for each vertex (using interpolated normal vectors, which we have). We'd lose detailed shadows on these brushes, but right now they look decrepit so who cares?

This could be done without a map format change: lighting values for shaded vertices could be calculated at load time using the r_bsp_light_t's that we already have. We would have to extend r_bsp_vertex_t to add the color field..

Rendering would then use a color array / VBO, rather than a lightmap texture.

The scoreboard has a number of issues outstanding. This is a running list/catch all for them.

-spectators don't show up on the scoreboard unless in spectate and not chasing anyone -scoreboard doesn't show up if in spectate and chaseing someone -scoreboard contiminates client with game stats, #167 +scores command would allow this to be fixed

Dynamic light sources are not rotated for rotating bsp models. A good example is the turbine / grinder on q2dm5.

Enable/disable cvar for team scramble via rcon or console either between rounds (to scramble teams during obviously uneven scores?) or at the beginning of match before teams /ready up

something like

sv_teamscramble Inputting this command randomly switches team members on each team. Each player will either be a 0 or 1, if 0 then player stays on team, if 1 then player is forced on the other team. Cvar takes into account number of players on each team and balances them accordingly

Enable/disable scramble cvar if team scores are extremely uneven and temporarily disable team switching for fair play?

something like

sv_fairplay 0/1

sv_fairplayhold value = amount of time team switching is disabled after teams are scrambled

Need a way the server operator can control what things can be voted for. IE, a TDM server can be voted to ARENA, when the operator only wants to leave map voteing open. Not sure of an easy/general way to do this.

Some commands are not being interpreted correctly, and result in the client spewing what appears to be gibberish in messagemode. The gibberish is actually the keynum and the timestamp of their input. A simple test case for this is to bind any key to an alias beginning with +:

alias +score score
alias -score score
bind TAB +score

Hit TAB, watch yourself say +score 9 120833 to the world.

Add joystick support.

Changed 15 months ago by wickedshell

owner changed from jdolan to wickedshell
status changed from new to assigned

Changed 13 months ago by maci

do we really need joystick/gamepad support ???
Changed 13 months ago by wickedshell

Might be nice in the end. I'm not working on it till post 4/1 beta stuff though. (Or at least I'm not planning to).

Currently, in order for Radiant to find them, assets must reside in the root install folder. Instead, Radiant should honor our prefix setting:

quake2world/trunk/gtkradiant/games/q2w.game#L11

We need to work with divVerent to determine why this fails, because mappers can not insulate their works-in-progress from our Update utility as-is. This is very dangerous; people are losing maps, textures, sounds etc. when they Update.

The code in question is here: http://git.icculus.org/?p=divverent/netradiant.git;a=blob;f=radiant/mainframe.cpp;h=546ba9d7a772d8df5965d4a74d37b3628d3beeb6;hb=HEAD#l185

Doors should open and close with a high speed, also doors should open when a projectile is incoming, much like in Quake3.

Changed 6 years ago by jdolan

status changed from new to assigned

Doors do support the "speed" key/value pair. The default speed is 100 if none is specified. Try 500 maybe? If you could attach a test .map file with a door, I'll work on getting projectiles recognized and allowed through.
Changed 6 years ago by Lava_Croft

Yeah, I kind of messed up on the ticket, I think I was very tired, or just smoked. Ignore the stuff about the speed, I am looking forward to your code that makes doors open for incoming projectiles. It will add yet another fun gameplay element to Quake2World.
Changed 6 years ago by jdolan

owner changed from jdolan to Lava_Croft
status changed from assigned to new

Any chance on getting a test .map for this one? I honestly don't know how to create one off the top of my head.
Changed 4 years ago by jdolan

owner changed from Lava_Croft to jdolan
status changed from new to assigned

I can actually use one of the Alien Arena maps to test this.
Changed 14 months ago by jdolan

owner changed from jdolan to wickedshell

If you need a test map for this, I can knock one out tonight.

The BFG skin is .. not great. I think it was the first texture you ever made :)

Classic freezetag mode

I liked Q3's implementation of the encasing ice when frozen, but would like it if the ice either melted or exploded without gibbing.

Static settings:

stand next to friendly frozen player (X amount of units away) for 3 seconds to thaw, thawed player respawns immediately

Tie into weapon banning/allowing to be able to have a unlimited railgun-only 1-hit freeze for instafreeze mode

Include lithium grapple