Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable obituary output to console #8

Closed
ldrone opened this issue Oct 31, 2016 · 24 comments

Comments

Projects
None yet
4 participants
@ldrone
Copy link
Contributor

commented Oct 31, 2016

Playing a game of insta ctf mod, frag messages appear in small intervals, clogging the console and making the chat history unreadable. The same probably applies to deathmatch mode.

I am thinking of implementing a variable cg_fragmsgoutput [0|1], zero disabling the output of obituary messages to console. The frag message would still appear on the hud (upper left corner).

@The-Gig

This comment has been minimized.

Copy link
Contributor

commented Nov 4, 2016

Just a question: are those infos used by statistics analysis tools?
http://openarena.wikia.com/wiki/Servers#Server_statistics

@ldrone

This comment has been minimized.

Copy link
Contributor Author

commented Nov 4, 2016

I'm referring to messages of the type: "player_x almost dodged player_y's rocket", or other info such as
player_x got the flag. These are all shown on the top left screen and written in console.

My idea is to have an option not write them into console. If those are used for statistics, they can be enabled on the server side, but I'd have it set default to 0 for clients.

@The-Gig

This comment has been minimized.

Copy link
Contributor

commented Nov 4, 2016

"Default to 0" does not seem a good idea to me. For me it's hard to read messages in top left corner, finding everything in console output is useful IMHO.

Another question... when there is a single cvar which has effect on both client and server aspects... does its prefix begin with com_ , usually? Just asking...

@ldrone

This comment has been minimized.

Copy link
Contributor Author

commented Nov 5, 2016

Anything not having sv_ prefix is not server related. So everything else, in theory, should be client side. I'm not sure I completely understand your question. How does a cvar affect both client and server? Give me an example.

For a list of prefixes, from Quake Live http://www.regurge.at/ql:
BOT_: bot settings
CG_: client game settings
CL_: client-side settings
CM_: collision map settings
COM_: Common settings
FS_: game files settings
G_: server-side game settings
GT_: connection settings
IN_: general input device settings
JOY_: joystick input settings
M_: mouse input settings
NET_: network settings
PMOVE_: player movement server settings
R_: video rendering settings
S_: sound system settings
SV_: server-side settings
SYS_: system configuration settings
UI_: user interface settings
WEB_: website settings

@The-Gig

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2016

I was thinking about "common settings" (com_) due to the console sounds something where both client and server parts of the game write output.
I don't know exactly if the "feature" you are thinking about should be considered a client one or a common one... So I asked. It may just be a client thing... Would the command also affect a dedicated server, if typed there?
Or maybe should it be UI_?

PS: Thank you for the list, that's interesting!

PPS: Your first sentence sounds a bit strange: at least g, pmove and bot prefixes do seem to be server-related, too..

@leilei-

This comment has been minimized.

Copy link
Member

commented Nov 6, 2016

games.log logs the kills iirc. and personally i'm hoping for icongraphic obituaries ala Half-Life for the UI3 system at least but i've never messed with cgame string printing all that much.

@ldrone

This comment has been minimized.

Copy link
Contributor Author

commented Nov 7, 2016

I don't know exactly if the "feature" you are thinking about should be considered a client one or a common one... So I asked. It may just be a client thing... Would the command also affect a dedicated server, if typed there?
Or maybe should it be UI_?

I'll have to look at the code for further answers to see how it's implemented. If it's a common one, can it be split into a client only.

@sago007

This comment has been minimized.

Copy link
Member

commented Nov 7, 2016

I looked a bit in the code.
It appears that cgame is unable to distinguish between writing to the screen or the console. It is currently all done in a trap call. I don't want to mess with a trap call.

Implementing a icongraphic system like leilei- suggested and perhaps placing it in a different corner (bottom left seems to be the standard) is properly the best solution to the mess.
If icongraphic is too hard then just a cgame managed console in the bottom left corner would be fine too.

@leilei-

This comment has been minimized.

Copy link
Member

commented Nov 9, 2016

I'd also want to suppress a lot of the warnings (with a cvar) if a console gets a role in the bottom left. Those can really clog up and there is always 3rd party content that fires off warnings on load, warnings not necessarily OA related

@sago007

This comment has been minimized.

Copy link
Member

commented Nov 9, 2016

The current console will stay in the top left. It needs to for backwards compatibility.
It was only the kills I wanted to move lower.

The old console are used for say and system information.

We cannot disable the output only move it away.

Bugs should be fixed not ignored. (A warning is a bug)

@The-Gig

This comment has been minimized.

Copy link
Contributor

commented Nov 10, 2016

Since it looks like the focus has changed a little from the initial post, I'll try to sum up what I understood:

  • ldrone (1pixel) would like an option to avoid writing "x was killed by y" in the console log (when the console is open). No change instead to the HUD: still showing such infos in the "notification area" (I don't know the exact name of it... so I'm going to use this term for the "HUD console" in this post) in the upper left corner, together with chat text ect.
  • Sago007 would like to split the HUD "notification area" in two parts: the upper left area with chat and system text, and a new area, placed lower, dedicated to "x was killed by y". Or alternatively, an "infographic" (EDIT: iconographic) system (which I don't know what it is). Not sure about his thoughts about the console log (when console is open), maybe just keeping it as it is now?
  • Leilei (Fromhell) woud like an "infographic" (EDIT: iconographic) system for the hud, if possible. And an option to suppress many warnings (but how to distinguish which ones?) in the "notification area". I don't know if also in the log (when console is open), maybe not.
@ldrone

This comment has been minimized.

Copy link
Contributor Author

commented Nov 10, 2016

I believe the correct term we are all looking for is iconographic.
It means that instead of an only text message:
player_x almost dodged player_y rocket
it would display message with an icon involved:
player_y (rocket icon) player_x

Sago007 is saying that my idea of suppressing warnings in console can't be accomplished
without changing some low level functions. In the last two posts Leilei and Sago007 seem to be talking
about output to HUD (or screen).

@The-Gig

This comment has been minimized.

Copy link
Contributor

commented Nov 10, 2016

Yes, "iconographic"... "infographic" was just a typo from mine.
Maybe it may be possible to allow the end user to choose between text or icons?

@ldrone

This comment has been minimized.

Copy link
Contributor Author

commented Nov 13, 2016

I think most would prefer looking at icons over reading text, assuming it's clear from the icons what happened, e.g. dropping a flag is distinguishable from capturing a flag. You'd still have the text output in the console. But if you really want that option, it could be easily implemented by adding another console variable.

@The-Gig

This comment has been minimized.

Copy link
Contributor

commented Nov 14, 2016

For example, we would have to think (and make) icons for all those kinds of stuff... cb6f540

@leilei-

This comment has been minimized.

Copy link
Member

commented Nov 15, 2016

You're overcomplicating things. Just a skull will do for all else.

@ldrone

This comment has been minimized.

Copy link
Contributor Author

commented Nov 18, 2016

I made the iconographic display, separated from the console. I still need to test/add code for the
font from the UI3, and then I will make a pull request.

Before I close this thread, I'd like to go over my main idea of having a variable to disable the frag output to console. I've tested it, by disabling the console output, the games.log file still displays:

0:23 Kill: 2 1 8: Ayumi killed Skelebot by MOD_PLASMA

That is, doesn't actually log the frag message Skelebot was melted by Ayumi's plasmagun.

So if you think it is unnecessary, maybe increasing the chat time and adding more lines to screen chat display is the solution. That wouldn't help those who prefer writing/reading from console line rather than using the screen chat from key binds (messagemode and messagemode2).

@The-Gig

This comment has been minimized.

Copy link
Contributor

commented Nov 18, 2016

Is the iconographic thing enabled/disabled by a cvar? I would appreciate it.
About what using as default, IDK: general rules would suggest to keep original behavior as default, but this is just an UI change...

@The-Gig

This comment has been minimized.

Copy link
Contributor

commented Nov 18, 2016

I have given a quick look to the code (with an eye to the code and one to my daughter running through the house)... a small thing I noticed: "hideAttacker = qtrue" used various times... it looks like what suggested by Leilei a few posts above (just a skull for all else)... but I think just a skull without attacker is okay for the generic "x died' (there isn't an "attacker")... but for generic "y killed x" one might use a generic death icon and still mention the attacker, isn't it?

@ldrone

This comment has been minimized.

Copy link
Contributor Author

commented Nov 18, 2016

Is the iconographic thing enabled/disabled by a cvar? I would appreciate it.

If I disable it now as it is, there won't be any output to the screen. I'd need to add more code to display
text instead of icons, to have the same behavior as before.

I have given a quick look to the code (with an eye to the code and one to my daughter running through the house)... a small thing I noticed: "hideAttacker = qtrue" used various times... it looks like what suggested by Leilei a few posts above (just a skull for all else)... but I think just a skull without attacker is okay for the generic "x died' (there isn't an "attacker")... but for generic "y killed x" one might use a generic death icon and sill mention the attacker, isn't it?

You are right about hideAttacker. Leilei seems to think differently (if I understood correctly) about cases when someone hits you and you fall into lava. I can implement it both ways.
The way you suggest would look like <attacker1> (skull_icon) <attacker2>
You'd have to find agreement on how you want it to look.

I can't upload the image here to see how it looks. I'll post it on forum or discord.

@leilei-

This comment has been minimized.

Copy link
Member

commented Nov 19, 2016

About what using as default, IDK: general rules would suggest to keep original behavior as default, but this is just an UI change...

Which "general rules" do you speak of? Updated HUD/UI presentation != core gameplay alterations,

and I'd default to iconographic because it's been very much the acceptable standard for obituaries in the past 17 years. OA doesn't have to be under a rock.

@The-Gig

This comment has been minimized.

Copy link
Contributor

commented Nov 19, 2016

I have absolutely no problem with having the new behavior as default, as long as there is an option for who likes the old style way. It's just that recently we have read some complaints on the forums about a few changes more or less enabled by default (spawn protect, delag hitscan) and so one might want to think twice before changing any kind of default, in general...
However, I agree that an UI change is much different than a gameplay change... that's why I said "this is just an UI change" in my previous post.

About showing attacker name for "assisted suicide" (e.g. awardpushing), I don't see any drawback with it (it allows to know who does get the score)... however let's hear Leilei's opinion. I THINK she was just saying "you don't need an icon for cratering, an icon for lava, an icon for slime, etc", but I can't tell for sure.
Of course, cases like "x does a backflip into the lava" and "x cratered" would just show a single name and a skull (I do wonder if the skull icon should be slighly different -e.g. a different color- in this case to differentiate from "assisted suicide", or who cares?)...

PS: about "juiced" effect, maybe one may use prox mine icon instead of the generic skull? IIRC it's the only thing that can achieve it... (by throwing a prox mine into an "invulnerability" shpere). Please correct me if I'm wrong.

PPS: looking at the code, it looks like you did not set an icon for this:
// we don't know what it was
CG_Printf( "%s died.\n", targetName );
Is that due to being in a different part of an "if", would require to repeat too much code, maybe?

@ldrone

This comment has been minimized.

Copy link
Contributor Author

commented Nov 20, 2016

Since I coded the behavior, additional discussion should be at the pull request.

@ldrone ldrone closed this Nov 20, 2016

@The-Gig

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2016

Let's insert a link to the pull request discussion, then:
#11
:-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.