News | Forum | People | FAQ | Links | Search | Register | Log in
Quakespasm Engine
This engine needs its own thread.

Feedback: I like the OS X version, but I have to start it from the terminal for it to work and can't just double-click it like a traditional OS X app. I'm sure you guys already know this, either way great engine.

http://quakespasm.sourceforge.net/
First | Previous | Next | Last
Vkquake And Dynamic Lights 
Since there is no vkQuake thread I figured I would ask this here. In the latest version of vkQuake (1.05.0) any and all brush entities are not affected by dynamic lights, including lights from rockets and weapon flashes, flickering or strobing lights, etc. They always remain the same lit value, note the first secret door in e1m1 is fullbright despite being in an area with a flickering light.

Is this behavior intentional, or is it a bug? 
 
That has to be a bug. I've just had a quick look over the Github and the code for calculating lights on brush models is still there. I didn't look over it comprehensively enough to pinpoint what the bug may be, however. 
 
Change Conchars With Quakespasm 
Hi! i was trying to change console font but i cant find the way, how can i do it? and where can find conchars example to test it?

Thanks alot! 
@Drugod 
Quakespasm uses the standard file format for conchars, here is a guide:

https://www.quakewiki.net/archives/fatty/defaulte128.html?opinion=conchars

Short answer, it's in gfx.wad 
@metlslime 
aaaaa!!!! thanks you so much bro "!!! 
@metlslime Another Question 
And for Quakespasm spike? you how works? same way than quakespasm ? 
Drugod 
The same method will work there. 
@metlslime 
thanks! 
 
Sensitivity on MOVE stick is too high. I can't strafe properly, my character just launches himself left and right.

You can alter the sensitivity of the LOOK stick but not with the MOVE? 
 
apparently QSS supports IQM:
https://github.com/Shpoike/Quakespasm/blob/9ffca1dedc47061ec4c2b7c230c44aa23a591226/quakespasm/Quake/r_alias.c#L619

so, for animated models, one can just use the following plugin:

https://github.com/lsalzman/iqm/blob/master/blender-2.93/iqm_export.py

and use them as replacements? Or are animations not supported at all? 
PARTICLES! 
Is there a way to make particles bigger like they are in original DOS Quake or WinQuake?

For example, comparison screenshots: http://gila.deathmask.net/particles/

In DOS or WinQuake, the particles are really big, even in higher screen resolutions. In modern GL/Fitz/QS/vkQ variants the particles are too small compared to that.

I thought that r_quadparticles would affect this, but it's purpose is probably something else. 
Particles 
What you're seeing in Dos/Win Quake is particles that are further away. It's also noticeable that when particles are closer to the viewpoint in Dos/Win they're substantially smaller.

FitzQuake and derivatives just use the same particle scaling algorithm as GLQuake, so nearer particles are larger, further particles are smaller, with further particles being slightly boosted in size to prevent them completely disappearing at more extreme ranges.

Looking over the code, there's no way to modify this behaviour, but there are a few scaling factors that could potentially be cvarized in a future version.

QSS, I would guess, has all of this controllable by CSQC. 
Mh 
Thanks for explanation!

I walked rigth up to the wall and fired the shotgun. In WinQuake the particles are small, but as soon as I start moving away (like ~64+ units away maybe?) they suddenly get bigger, like x4 in size.

In GL/Fitz/etc it's the other way around. Really 'in your face' particles are big but moving away makes them smaller, almost like this behavior is inverted from DOS/Win :)

It's just that recently I played some classic map packs (Beyond Belief, etc) and both official mission packs in Mark V WinQuake to check out (more like to remember) the 256-color look, and then I go back to QS/vk/Fitz and the particles like blood and explosions are so puny and small... 
 
It's unfortunate that glquake and fitzquake and friends don't have particles that feel "correct", but the behavior of software quake is hard to call correct either, so probably the best solution (if one is needed) is to provide some cvars to let users get closer to the behavior they think is best. 
.ent Question 
Assuming I am loading an external .ent file for start.bsp (start.ent) in the ID1 folder, would that mess up any other start.bsp loaded on top of it (e.g. from SoA or DoE)? 
#3734 
QuakeSpasm has checks to ensure that external content files come from the same, or a higher priority, gamedir as the base .bsp - I think this might break if your .ent files are at a higher priority gamedir than both the .bsp and the mod (so "QuakeSpasm.exe -hipnotic -game mygame", where "mygame" contains your .ents), but I haven't personally tested that so take it with the appropriately-sized grain of salt. 
If The .ent Is Only Placed In Id1 
and considering any other content is loaded on top of it, I assume it should be ok if there is another start.bsp somewhere else. 
HIPDM1 Ent 
BTW, has anybody ever figured out how to fix the Spike Mine in HIPDM1 which explodes right after level start and prevents you from getting 100% kills?

The relevant ENT entries are these:

{
"spawnmulti" "1"
"classname" "func_spawn_small"
"origin" "-376 248 1256"
"spawnsilent" "1"
"spawnfunction" "trap_spike_mine"
"spawnclassname" "trap_spike_mine"
"targetname" "7777"
"target" "7778"
}
{
"model" "*27"
"sounds" "3"
"spawnflags" "2048"
"classname" "trigger_once"
"target" "7777"
}
{
"classname" "path_corner"
"origin" "-360 792 1224"
"targetname" "7778"
Didn't Catch All Cases 
There are actually more definitions involved.

Full list should be this:

{
"spawnmulti" "1"
"classname" "func_spawn_small"
"origin" "-376 248 1256"
"spawnsilent" "1"
"spawnfunction" "trap_spike_mine"
"spawnclassname" "trap_spike_mine"
"targetname" "7777"
"target" "7778"
}
{
"model" "*27"
"sounds" "3"
"spawnflags" "2048"
"classname" "trigger_once"
"target" "7777"
}
{
"model" "*28"
"sounds" "3"
"spawnflags" "2048"
"target" "7777"
"classname" "trigger_once"
}
{
"model" "*29"
"target" "7777"
"classname" "trigger_once"
"spawnflags" "2304"
"sounds" "3"
}
{
"model" "*30"
"target" "7777"
"sounds" "3"
"spawnflags" "2048"
"classname" "trigger_once"
}
{
"model" "*31"
"target" "7777"
"classname" "trigger_once"
"spawnflags" "2304"
"sounds" "3"
}
{
"classname" "func_exploder"
"origin" "-384 216 1248"
"spawnflags" "1"
"targetname" "7777"
"dmg" "-1"
}
{
"classname" "path_corner"
"origin" "-360 792 1224"
"targetname" "7778"
How It Might Have Worked 
I am not sure if I get it right, but the way I see this, it was intended to work like this:

That tube at the top of the level (which can blow you down if you try to jump into it) was supposed to work as some kind of "mine launcher". There are 5 spots on the map that would trigger a spike mine, launched from the tunnel (with an explosion that wasn't supposed to damage the mines, apparently).

Not sure why it doesn't work, though. Maybe func_exploder and the mine spawner shouldn't have the same targetname (7777)? Or maybe there is something in the trajectory of path_corner? 
Solved 
Looks like the code itself was OK, but - as so often - spawning coordinates were flawed. In func_spawn_small, setting "origin" to "-376 268 1256" (+20 on the y axis) is all it takes, and that HIPDM1 Spike Mine launcher suddenly works as intended.

In the meantime, we found out that the lavamen in DoE's R2M3 dropping to the lower floor in QSS can be fixed if you change their z origin values, too. However, it shouldn't be necessary since other ports don't have that problem. 
@NightFright 
Do you have more entity fixes maybe? Not only SOA, but DOE and/or ID1? 
It's Coming 
I actually fixed all id1/hip/rog maps now. Many could be taken from Maddes' Quake Info Pool, but I added a few on my own. They will be part of a vanilla fix pack I intend to release soon. It's stuff like Orion's mdl fixes, better id1 sounds from QTest, Romero's full E2M6, progs.dat and map fixes for Quake and both mission packs. I even corrected the music not playing in the first SoA demo. 
Sweet! 
The other day I was thinking of a fix-pack like this.

Speaking of E2M6, did you (or anyone) check that there was no other changes to it, apart cutting the swamp cave entrance? Are you going to use the actual file from the "Beta 3" pre-release (converted to BSP v29) or newly created from E2M6+E2M10 map sources?

Sorry for continuing this offtopic, but on Quaddicted you posted on this subject:

> The ending of E2M5 finally makes a lot more sense since it ends in a cave which is logically continued here.

But I don't get it. E2M5 ends in some blue corridors and rooms... not in a cave. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.