I was asking if it was feasible.

re: ad-tfuma Not sure if it would keep you from playing the map though? Also not really necessary in AD as mappers can add a key to suppress infighting. So it would really just be for vanilla Quake. As I asked: Wondering if this is even possible from an engine perspective?

mh - why would it be "inappropriate" to add this feature to an engine? 

is planned and set up using triggers.

I'm not sure why you would want to alter this behaviour as this is my vision for the map. 

the logic of the game is in QuakeC
the monsters are in QuakeC
the infighting rules are in QuakeC

the only thing that the engine can do is put the slider in the menu 

I mentioned above this would be for vanilla Quake not AD and it's just an inquiry. Not trying to destroy your art. ;)

@topher yeah I get that's how it works. It was more of an academic question. Wondering if you could modify QC behavior through the engine. Apparently not. 

my guess is that it's possible but it will be hacky, bug prone and harder than modifying and recompiling a new progs.dat 

Wondering if you could modify QC behavior through the engine. Apparently not.

Well the engine can change the QC, but that's not really the point. The logic that deals with infighting is all in the QC, so all you could really do in the engine is do something like a truly disgusting hack such as preventing self.enemy from changing on an entity if certain conditions are met. However, you could only reliably guarantee it working for id1 (the assumptions you make in the engine to make it work for id1 wouldn't necessarily be valid under any other mod), and any other mod being run under it could break in all sorts of subtle ways. 

mh - why would it be "inappropriate" to add this feature to an engine?

First read Kinn's answer just above - that covers the technical reasons why.

Then read Fifth's answer because it covers the gameplay/modder perspective.

I know you said that you were asking about vanilla Quake, not AD, but it's still relevant. Infighting is a designed behaviour of vanilla Quake - it's even mentioned in the Quake manual:
Q: Did I really see two monsters fighting each other?
A: Probably. Some monsters hate one another almost as much as they hate you. You can use this to your advantage (exercise left up to the reader).

Infighting is game logic and the correct place to modify game logic is in the QC code. The engine should not try to inject modifications to QC code. I'm actually shocked and appalled that this even has to be explained. If you want to modify the QC code, the correct thing to do is... modify the QC code. Make a mod with reduced infighting and play that instead. 

If you really want such a feature then make your own progs or throw money/sexual favours at someone to do it. 

I'd do it if you threw money at me ;)

I actually previously modified this behavior in FvF. I think my monsters only have a 50% chance of getting mad at each other if they hit each other by accident. If they get hit intentionally by another monster, then they immediately retaliate (they just check to see if the owner of the attack is a monster, and they sometimes ignore the attack if it was not intentional -- if the owner of the attack has you set as its enemy, then it was intentional and you return the favor). This cuts down on the monster infighting, so they can focus more on killing the FvF players >:D But it's still fun to try and get the monsters to fight with each other instead of them all turning their attention on you!


Buy yeah, this is not something the engine should really be tinkering with.

Except MAYBE as a secret hidden setting which is defaulted off; like a new, harder difficulty mode or something. But I think there are plenty of other issues Mark V can be addressing before adding something like that.... 

I could be mistaken but I think the infighting behaviour is slightly different in AD and they don't instantly change target unless you do a certain amount of damage. 

could someone sent a config with basic graphics to to improve the fps (dx9_mark_v.exe)?

My notebook isn't very good, onboard video and etc.
what's the command for save a config? 

My email: hmdbrandao@gmail.com

How can i put the Time (with high size) on the center of the screen?

Tks everyone! 

We need more women in Func_. 

The only major default thing that might help FPS is to disable mirrors (which really should be disabled by default):

r_mirroralpha 1


To always show the clock, set:

scr_clock 1

(Baker, the help info for scr_clock is incorrect. It says 0 = deathmatch only, and -1 = never. That info is reversed).

I think the only thing you can do to make the clock bigger is to make your HUD bigger, like:

scr_scaleauto 0
scr_sbarscale 2 

Onboard video is actually capable of running fast without needing to compromise on quality. The problem isn't onboard video, the problem is how the engine is coded.

One of FitzQuake's claims is "if you can run glquake, you can probably run Fitzquake". Unfortunately that means that it tends to brute-force certain things on the CPU where a more elegant, faster approach often exists.

MarkV has inherited that tendency, so hence it suffers from the same problems.

No amount of "go faster" config options can fix that; it needs a complete rewrite.

It's a fallacy to think that the older API is faster with low-end hardware. Low-end hardware these days supports shaders and VBOs; really old low-end hardware still supports shaders and VBOs. Shaders and VBOs allow a faster renderer.

I recommend that you run QuakeSpasm and run it with all extensions enabled; odds are that it will run substantially faster than DX9 MarkV, even on Intel hardware. 

Thank you Gunter!
With the command r_mirroralpha 1 improved something.

My notebook is a Lenovo E520 - I5.2410 CPU 8gb ram, 128gb ssd with Intel HD Graphics 3000.

Thank you mh too!

I downloaded the QuakeSpasm, but the QuakeSpasm FPS is similar than MarkV FPS (200..300). what do you mean "with all extensions enabled?". Could you send to me some config?

Thanks in advance! 

With an Intel HD 3000 that's going to be the best framerate you'll get. The only option you have is to lower your resolution.

"With all extensions enabled" means don't disable multitexture, don't disable combine, don't disable shaders, because hardware will run better with these enabled and QuakeSpasm is more sensibly coded than most.

If you're doing nothing to disable these then you don't need a config, just keep things the way they are.

I'm currently working on an engine that will probably run twice as fast, but it's not suitable for general use yet. 

Has anyone seen baker in the past week or so? :/

In other news, has this "transparent models" issue been seen before in any other engines, or is it unique to markv? Noticed it while playing today and I wasn't familiar with it at all beforehand. 

YouTube's video encoding is bad for analyzing such things, but it seems that there's a conflict with the skybox renderer, maybe related to the Z-buffer. 

Thanks everyone for your answers. It really was just a curiosity and I learned a lot in just these few answers. The reason I asked here is that Mark V seems to be the engine with the most "out of the box" and unique features. I will look into a progs version. Maybe something exists or can be gleaned from AD dev kit. 

Ya know, if you want to play Quake with the monsters being smarter, more dangerous, and not in-fighting as much, you should come play FvF ;)

We usually gather to play on Sunday nights....

http://fvfonline.com
connect fvf.servequake.com 

Ok.... Another complaint about the secret cfg files overriding expected behavior:

I installed a clean copy of Quake and Mark V into a completely separate folder ("Quake1"). I ran it and got everything set up how I wanted it for THAT folder only.

Then when I went back to my original Quake folder ("Quake") and ran Mark V, the resolution settings I had made for the separate folder were loaded... (perhaps other settings too).

I do not like that, no I do not.

All cfg settings need to be kept separate for each folder, and for each mod.

This goes back to the stuff I was commenting about in #1276 with ideas for a better setup with these config files -- too much behind-the-scenes stuff not matching user expectation. It would be better if the Mark V config files were saved alongside the standard cfg files, and were user-accessible. 

https://www.youtube.com/watch?v=pWyFltQ-wRY 

I made mention awhile back about the overwriting of my configs and the "secret" area as well.

What if custom engine wrote their own "branded" config.cfg? EX: markv_config.cfg, fte_config.cfg, qs_config.cfg etc etc

That way no one engine writes over another's config file.

Also, there really is no need to complicate such a simple execution of saving a players configuration settings like this:

C:\Users\damage_inc\AppDataRoaming\Mark\Vcaches\id1\config.cfg

Especially given most are not even aware of it and simple browsing of folders doesn't even reveal it. 

All I want is a way to save video settings and only video settings. Having a mod load in 640*480 and move all the windows on my 3 displays one display across (apparently... Idk, it just gets weird) is beyond frustrating. I guess I should just force my res through launch args but still...