|Posted by Baker [126.96.36.199] on 2016/11/19 04:53:11|
* Nehahra support -- better and deeper link
* Mirror support, "mirror_" textures. video
* Quaddicted install via console (i.e. "install travail")
* Full external texture support DP naming convention
* Enhanced dev tools texturepointer video inspector video
* IPv6 support, enhanced server capabilities
* Enhance co-operative play (excels at this!)
* Software renderer version (WinQuake)
* "Find" information command (ex. type "find sky")
Thanks to the beta testers! NightFright, fifth, spy, gunter, pulsar, johnny law, dwere, qmaster, mfx, icaro, kinn, adib, onetruepurple, railmccoy
And thanks to the other developers who actively provided advice or assistance: Spike (!), mh, ericw, metlslime and the sw guys: mankrip and qbism.
/Mac version is not current yet ...; Linux will happen sometime in 2017
The Smell Of Napalm On The Forum
There's something wonderful about reading Baker raging against ogg, and then immediately afterwards reading about how despite Baker's strong desire to prevent it by explicitly coding it out, someone has hacked it to work with a find+replace.
It makes you wonder what ogg did to Baker - murdered/kidnapped family I guess - in the past to make him think "I have this perfectly good DirectShow support in my engine. I should ruin it and only use it for mp3 format music to ensure that my users have to work harder than with other engines!"
Doesn't Sound Complicated At All?
Implement a generic audio library and comment out ogg from the list of supported formats.
why not just add literally 3 extra characters to the source code to enable OGG support
I obviously can't speak for Baker but this wouldn't be just 3 extra characters. It's only 3 characters if you directly replace the existing .mp3 support with .ogg support, but of course you then lose .mp3 support.
Adding multiple file format support would involve enumerating files of multiple extensions, sorting them into lists, making decisions such as which format has priority over others (not so clear-cut - how do you decide between a high bitrate inferior format vs a low bitrate superior format?), and how to handle the inevitable crazy-assed situation where someone has multiple formats in the same folder (some of which may even be multiple versions of the same file in different formats).
I absolutely do think that people should make the effort to do all this, of course. But it would need some guidance as to what the end-user expected behaviour is. Multiple end users pulling an engine in different directions is something I can personally vouch for as never ending well, and it would be nice to see players striking up a discussion among themselves about how they'd like to see these kind of decisions work out.
Funny thing is, OGG is actually already listed in Mark V's file extension look up table:
But there must be some code that explicitly ignores or forbids it. Seriously though, just why. It's a relatively popular file format for video game audio.
To enable OGG support find the above bit in a hex editor and replace mp3 with ogg. Simply renaming your OGG tracks to MP3 should work as well, I guess.
I'm confused... Isn't engine inter-compatibility something to strive for? Considering that all other engines support the format AND the fact that most soundtracks available online are in .ogg, it strikes me as odd that Baker would want to force the user to convert the files in order to use them with his engine. Plug'n'play, man, plug'n'play...
Probably doesn't want bloat.
Ok Baker, I NEED ogg support!
I tried the hacks mentioned above (either renaming my ogg to mp3, or hex-editing mark_v), then, after installing the ogg directshow filter ( http://www.vorbis.com/setup_windows/
), Mark_V does play ogg.... and it loads in a FRACTION OF THE TIME as an mp3 file of the same file size!
Do you remember a while back, me going through a LOT of testing because I have an issue where loading an mp3 file causes Mark V to freeze up while the file loads? (mentioned in #651 above)
After some encoding gymnastics I managed to get that loading time (during which everything freezes up) down to only like 4.2 seconds for track04.mp3.... Well, I converted it to an ogg of the same bit rate and file size, and it loads in only 1.23 seconds!
So... yeah. That would be the reason to allow ogg files to be found by Mark V (since it is already capable of playing them).
You really don't have to do all the complicated stuff mh mentioned. Just state, "Mark V supports the following formats, in the following order of preference: mp3, ogg."
And let the users sort their own files and formats and bitrates.
Indeed, there's no need to compare bitrates or anything, just let it read formats A|B|C in the priority of A, B, C. And the game folder should take priority over id1, e.g. say you have OGGs in id1 but e.g. Travail comes with an MP3 soundtrack, disregard the OGGs in id1 then, unless there's not enough tracks in the game folder, in which case read the missing ones from id1. I think that's how Quakespasm handles it anyway, correct me if I'm wrong.
is there a way to set the fog value via an cfg file or fog depends on qc?
Just use an external_entity file(yourmapname.ent) Put the fog command in there.
I Don't Quite Sure What You Talking About
why would i put the fog command in the external ent file? and where exactly should i put it?
i'm using the fog value via the worldspawn. AD mod supports this and shows fog correctly, but it seems kinn's old mod (bastion/marcher) doesn't support fog from the worldspawn, as there's no fog after loading map.
i'm just wondering :)
The worldspawn "fog" key is handled by the engine, it should work in id1 with MarkV (and most engines). Maybe bastion/marcher is resetting it via QC.
My answer was for the simple question of setting fog values via an external(.cfg) file, now I see your problem!
i have a map with a worldspawn settings something like
fog_colour x y z
and after loading this map in AD the fog appears correctly, then i put the very same map in the id1/maps folder and run it from the vanilla game
there's no fog at all
until i manually set the fog numbers in the console, what gives?
those are AD-specific fog keys.
Try: "fog" "density r g b"
Have You Just Tried...
"fog" "Density R G B"
All on one line for stock id?
Try: "fog" "density r g b"
i put this line fog 0.015 0.35 0 0
into an *cfg file without the quotes, but no avail.
Sorry, put it in worldspawn, not a cfg file :) i.e. the worldpawn key is "fog" and the value is "0.015 0.35 0 0"
yay, it's working this way. silly me. Thank you Eric and damage_inc
Hey, I require help
Whenever I try to launch any of those 2 executables using:
./mark_v_linux or ./mark_v_winquake_linux
I get following error:
bash: ./mark_v_winquake_linux: Permission denied
Double-clicking doesn't work either
On manjaro, hope anyone can help
chmod +x mark_v_winquake_linux
Has done the trick for me, it works now!
Marcher / Bastion Imps Sprite Issue
I was playing back some demos of Spy's work-in-progress map in 1.36 and the final frames of the imp fireball (the impact only) show up as non-transparent. If this is not a known issue, or repeatable I can try a screencap to make this a bit more clear. Works fine in other engines. Notably Quakespasm-admod
I've ran into this.
Which sprites are you using?
Kinn original: uses black for transparency requires enfine with support for .png override textures (e.g. Darkplaces) and additive mode.
AD: Not sure.
Keep: I converted all mine to use pink transparency for full support on all engines.
It's actually an older map of Spy's that he's working on getting ready to release pretty soon. Not sure what assets he was using.
@Spy are you using the same assets from the original Bastion/Marcher maps?
@dumptruck_ds Kinn Sprites
Mark_V enables external textures by default, so set external_extures to 0 and reload the map
or just delete all of *.tga files from the sprites folder, they are absolete now
Mark V's adaptive FOV calculation method seems to be quite different from QuakeSpasm and original FitzQuake. I need to increase FOV by about 6 to get the same field of view as in QS (using a 16:9 display). Of note, QS just does vert- when you set scr_sbaralpha 1, while Mark V does hor+. Not sure which method is preferable, however, it's possible that Baker based his adaptive FOV calculation on specific scr_sbaralpha and viewsize values. In particular, setting scr_sbaralpha 1 and viewsize 100 gives about the same FOV as in QS with full screen view point (that is scr_sbaralpha 0). But nowadays most people are probably playing with the transparent HUD, so this just results in smaller FOV.
I have finally come across a solution to my problem. It turns out that I actually didn't have pak1 and pak0.pak. I thought I did, but I didn't check my ID1 folder. Long story short, I found something which contained both pak files and copied them over.
I love it. It runs like a charm:
I'm so sorry for wasting your time over such a dumb mistake of mine.
>looks like glquake
Missing PAK files was the problem?
How does that happen? If I remove my PAK files and try to run Mark V, I immediately get a popup error message saying it can't find the pak files.....
Maybe corrupt pak files?
My laptop is 10 years old, I'd rather not...
Also, it's my first time using this sourceport, so I haven't tweaked all of the settings yet. Though, I'd love that to change. :)
Funny thing is, there were no .pak files at all in my ID1 folder.
The .pak files' contents were actually extracted to my ID1 folder, but the .paks themselves weren't there. Interesting.
Interesting! You may have found "an issue."
I tested with unpacked pak files, and Mark V does indeed just crash without any meaningful error message.
These alternate engines I tested work just fine with unpacked pak files:
Unpacked pak files should be an acceptable setup... so... Mark V should be able to handle that.
Anyway, if you're interested in tweaking Mark V with all kinds of setting which make it look better (in my view), I have a page with downloads and settings to alter: http://www.fvfonline.com/fitzquake.php
Then come play FvF :D
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.