Engine standards for mod compatibility

[Chip]

[leileilol]

[LordHavoc]

[frag.machine]

[Urre]

[goldenboy]

[r00k]

[Baker]

Slightly off-topic to some, but entirely on-topic to me if the idea is engine standards for modding:

I wish engines would use the same name for the same feature:

Case in point:

Gamedir switching

DarkPlaces: gamedir
Quakeworld (all engines): gamedir
JoeQuake: gamedir
Qrack/ProQuake: gamedir
FitzQuake: game

I don't care if FitzQuake uses "game" but it would nice if it also supported "gamedir". It would be nice for there to be a single way for a readme to indicate this.

Yes -hipnotic and any other special "game" (Nehahra, the big list that DP supports, etc.) parameters represent an issue.

Helps in a mod readme.txt to not have to list multiple ways to do something trivial and widely supported.

Memory

I think -heapsize xxxxx is universal, but it would be nice if all the engines supported -mem. Although it would be better if a good universally functional memory manager tutorial existed and maybe MH's one does the trick. Still, lower resource platforms may not be a good match for such a memory manager.

I won't drifting into the whole "no command line" discussion.

Easily "Dedicating" an engine to a mod

For total conversions or standalone mods, it would be nice to be able to:

1. Specify the engine name (I notice in Makaqu there is an ini file) so the Window doesn't say "GLQuake" but might say "Solitude" or "Kurok" or "X-Men: Ravages of Apocalypse" or <insert mod here>.

2. Customize the menu stuffs easily. XML like Urre or someone said? And the "help screens". And not having the engine precache demon/dland.wav or other Quake specific stuff (Where is source for Tomaz GLQuake clean source? I guess ArQLite () is based off that ...)

Then again the whole sbar issue and CSQC crops up.

I'm sure DarkPlaces has ways to deal with all of this and -- well -- a major problem that always resurfaces is that I bet it isn't documented anywhere, but likely there is a mod that is open source and uses it except no one knows the name of the mod or where the download is because the site of whatever mod is dead and only lives on leileilol's hard drive.

And then there is what Spike said about video mode switching and related features that really shouldn't be stored in a config.cfg because they have nothing to do with the mod. Video mode, directinput, etc ... those aren't gamedir.

Standard Places for Stuff

Where do external skyboxes go ideally? gfx/env or what?

DP captures video to gamedir\video whereas JoeQuake captures to quake/capture.

Where do screenshots go? gamedir\screenshots? Or "User Documents" folder on Windows like Quake 3 and whatever the Linux equivalent is? Or throw them all in gamedir?

Maybe this last part has drifted way off topic and that's not what I'm trying to do, but rather collect the list of "things" while I am thinking about them so as to not lose them.

AND PLEASE!

One single standard for naming external model textures! Use the DP way! It is insane to have to rename textures from engine to engine. And only TGA ... jpg and png are bad due to the reasons LH mentioned. JPG loses quality for trivial hard drive savings making future modifications of the texture "even crappier" and PNG is virtually requires external libraries to load and save, but TGA is optimally efficient to implement in engine code.

Button

Lardarse once told me the benefit of DarkPlace's support for button1, button2, button3 etc. I don't recall what this was exactly, but maybe simplifying binds and menus and more or less a standard controls implementation on the QuakeC side (since my playing around with QuakeC is somewhat limited, I plead ignorance on this, but know it is important.)

[goldenboy]

Baker, the yellow makes your posts hard to digest.

[necros]

hey there,

i was linked here from func_, so i haven't read any of the posts. i'm just responding to the OP.

vital:

-map limits: i won't bother listing them all, but essentially, if i'm able to compile the map in aguirRe's tools, then it should be loadable.
i consider fitzquake to be adequate (although i have already reached the limits in v085 and had to scale back a couple of maps).
if fitzquake double it's limits from 085, i would be very happy.
also: don't neglect the max_ambient_sound_channels (or whatever it's called). i'm talking about that error that shows up when you have a lot of ambient sounds in your map which stops further ambient sounds from playing. fitzquake still uses the old limit (or the increased limit is still too low)

-multiple mod loading. especially for quoth because it sucks that anyone who made a map back when it was new essentially had to dump their files into the quoth folder.
fitzquake has -quoth but dp does it best, i think, with a more general method of just specifying whatever mod folders you want in a row.

-the signon buffer and whatever else needed to load up maps with tons of entities.

-alpha transparency with the .alpha key for windows or whatever. it should work on everything; brush models, mesh models and sprites.


not vital, but Pretty Damn Important:

-skyboxes and fog: while not having any impact on gameplay, skyboxes contribute a lot to the atmosphere of a map and not having access to one or both sucks.

-i would also consider it pretty important that there be a qc manner to load fog and skyboxes. if you have a map that used multiple skyboxes or fog levels, it shouldn't be necessary to have to use fancy qc to get the settings to stick for map loading and saving.

-external file loading for map textures, sprites and skins. this opens up all new texture sets for use in maps. (but pretty much everyone does this already)


would be very nice to have:

-sound sources that move with entities they are played on. so my lifts and trains emit their sounds nomatter where they are after they started.

-going along with the previous point, doppler effect.

-stereo sounds

-ogg support

-real rotating brushes. i'm so damn tired of that hacky hipnotic shit. if this was a standard, it'd be beyond cool to have proper rotation.

-some way to have more control over particle temp entity effects in qc. it doesn't have to be complicated.
say for example, you take all the currently existing temp entity particle effects and give the ability to control what colours are used by specifying a start and end point on the palette.
and maybe a way to scale the size of the particle effect so you could have a TE_EXPLOSION at half size or something.

so.. yeah, that'd be my ideal quake engine standard.

[frag.machine]

[scar3crow]

[Dr. Shadowborg]

[leileilol]

[r00k]