 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Is there any sane way to animate weapons and models from QC? Without having to tie frames and game logic and without having to declare each and every frame as a var and then as a function?
@dumptruck
Best way to poke me is generally via #qc, if I'm on. Or if you're on discord I got harassed into joining the Quakeworld one. I don't know what would be up with the keyboard input. you could try toggling in_rawinput (followed by in_restart) which may or may not help, but I've not seen similar issues in the windows builds. I also don't use win10, but hey. @dfut framegroups would be the obvious answer there. however, animating with framegroups from ssqc is kinda messy as there's no way for the server to force a framegroup restart, which makes firing animations de-sync. csqc has full control over the time into framegroups though, and because that's the answer to everything, you can use it to detect toggles of some bitflag and convert them into restarting whatever framegroup. and if you're using csqc, you could also use it to position the various bones of eg an iqm via the skeletal objects extension, which allows things to spin independently of whatever animation they're otherwise meant to be playing, for smooth chainguns or whatever. md2+md3 do not natively support framegroups, while mdl+iqm do.
csqc is quite explicit when it comes to animation, so there's about 5 fields that need to be updated each frame. So, to switch from one animation to a new one, you copy additionally, you need to increment both note that if you want to restart an animation, you will likely want to do it with lerpfrac (and when it comes to viewmodels, they're not really any different from any other entity. Just make sure MASK_VIEWMODELS isn't used, spawn a private entity with renderflags|=RF_VIEWMODEL|RF_DEPTHHACK, setmodelindex it to getstatf(STAT_WEAPONMODEL), and update its frame to getstat(STAT_WEAPONFRAME) as appropriate. use some bit in the frame stat to signify animation restarts, and have the csqc restart the animation when its toggled by the ssqc or so. So yeah, quite a bit of code that really needs some proper example code to fully understand. I don't really have easy-to-read code to link though, so I'm sorry about that. Should work for most AD maps. Might not work on sepulchre, swampy, or other megamaps. Spike can correct me, but I don't believe FTE has support for sv_protocol 999 even though it does support bsp2.
Spike could have done some updating though. I highly recommend he does since "can it play AD" seems to be the new standard for whether a Quake engine is "worthy" (initial AD release only specified Quakespasm as supported, leading to a lot of questions on other engines). Orl maps are a concern too since they are very very large as well. ad_sepulcher: worked okay last time I tried it.
ad_swampy: I really have no idea why anyone would think this map would have a problem. 999: sv_bigcoords 1; if its need isn't autodetected (if for some reason you want 999 specifically, also set cl_loopbackprotocol fitz;cl_nopext 1). I'm not aware of any limits that are lower in FTE than QS, while I am aware of the reverse (even vs QSS). That's not to say that there are no issues whatsoever, just that any issues are more likely to be due to qw-by-default player physics, or other such 'minor' incompatibilities that could affect ANY map... And this is why you never fix what are obviously bugs. :( But yeah, if I was aware of any issues with any of those maps that were mentioned, then I've either fixed them or just forgotten about them... Feel free to try them and shout at me should they somehow crash and burn. This is not a warranty - if it causes your computer to explode and destroy your entire city, then you probably shouldn't have been playing quake inside a nuclear reactor. or whatever. As I said in the other thread, I got PrimalLove to give me a list of changes on that front, which are now implemented in the latest build.
Most of it was just cvar changes, so you'll need to do 'cvarreset joy*' or to wipe that part of your config some other way. So... this is news for me... i've been playing quake with FTE for 6 months now and never experienced crackling sound :/ but when i play sm181_coce1 and sm181_coce2 i can hear some annoying cracklings... and if i go to "menu/audio options/restart sound" the cracklings stops, but if i load the map again, or just press F9, the crackling returns :(
Why is this happening? And why only in these two maps? :/ snd_restart doesn't restart static sounds.
there's a crackly static sound played near all wall torches. I've no idea how you wouldn't have noticed that on other maps too though, maybe you've just been playing maps that use regular lights. that in the first one the crackling comes from the torches, and in the second from light_fluoro or light_fluorospark (i don't remember which right now). But torches do a very different sound from the fluoro
There is no logic gates or other sounds that repeat save the idle sounds from the enemies so it isn't from that, it can't be from performance as one is very open and the other took visibility seriously Ok, i've made a video showing what i'm talking about =D
https://www.youtube.com/watch?v=0yJ5DR2eutY I choose "coce2" because it doesnt have torches, so there will be no mistake here ;) After 00:27 you can hear the crackling sound. At 00:50 i restart the sound, and the crackling is gone, but the "wind" sound is gone too... So, at 01:30 i've loaded the map again to show that if you reload the map the crackling is back, and this time i fought some death-knights to prove that the crackling has nothing to do with the "wind" sound, since you can hear it when i'm fighting... And at 02:15 i loaded the same map with quakespasm to show that there's no crackling sound in this engine. But, as i said before, coce1 and coce2 are the only maps that i heard this annoying crackling ;) but it is not from my maps, as it isn't any of the sounds Quake does. I also used a completely clean install (just FTE.exe and the two
What i noticed and will be interesting for the developer is something on coloured lighting: i have coloured lights everywhere on the map, but there is only one not coloured. It's values are 1 1 1 to make a very dark light, so i suppose that FTE misunderstood it as a light with values between 0-1 instead of 0-255 and made it pure white. Look back on the spawning point on skill 1 and you'll see it. I also noticed that on default config hell_knight projectiles don't leave a trail. Rechecked it with E2M5 and the same happens so its not from my map. Gotta check which option puts that well. sound:
try using directsound instead of openal. snd_device dsound (or pick an explicit outpur driver+device via the menus) or wasapi or sdl2 or alsa... etc... lights: this is the problem when there's a complete lack of standards. you may wish to provide an missing trail particles: QS rounds up - particles get thicker at high framerates, making it harder to see enemies. FTE rounds down - particles get thinner. This is consistent with other QW engines. Unfortunately they can get so thin that they become invisible... I need to do something about this, I'm just not entirely sure what. The scripted particles do not have this issue (they have working distance tracking). In the meantime, cl_maxfps 150 (or vsync), or 'r_particledesc high' will 'fix' it, assuming a lax definition of fix. what's the command to get q2-style noclip movement? (fly in direction you are looking). For some reason this keeps going away and I end up back with sucky vanilla noclip style
that's nq player physics for you. oh, so NOW you don't want it faithful! pah! :P
sv_nqplayerphysics 0 will give qw physics, which don't have that annoyance (yes, there are a few mods that depend on the vanilla behaviour, which just makes things messy). its default varies by preset, which is awkward. Hehe, well I don't consider noclip as "part of the game", so how that works can be as unfaithful as I like :}
Is there anywhere I can read about the differences in player physics between qw and nq, because it sounds pretty interesting, and is something that I've never really come across before, having been a single player all my life, and never actually played qw. missing trail particles:
QS rounds up - particles get thicker at high framerates, making it harder to see enemies. FTE rounds down - particles get thinner. This is consistent with other QW engines. It's a little more complex than this. If you run your favourite Quake engine at 20-30 fps - which is the best that most people would have been getting in 1996 - you'll see that the intended behaviour of particle trails is not a straight, continuous trail of particles, but actually a trail that drops "clumps" of particles at discrete intervals. There was a So both NQ and QW are actually behaving incorrectly at higher framerates. The correct way to "fix" particle trails is to track an "ent->oldtrailorigin"; if a certain timespan has passed (something between 1/20 and 1/36 seconds works good) drop a clump (using standard R_RocketTrail from ent->oldtrailorigin to ent->origin) and update oldtrailorigin from origin. Add in some reset behaviour for when a new ent is spawned or an existing one is culled, and you're done. This way works consistently at any high framerate and doesn't excessively spam particles in timedemos either. Ok, so I can set 3d filter mode to "nearest" and 2d filter mode to "nearest" to make the world and the HUD cruncky pixels, but is there a way to make the console / text pixelly? Currently it's blurry and the text has some line artifacts around it, which seem to be a result of the filtering....
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |