 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
There's an error in the link you posted, as well as in the link I posted, which both describe the
Both of them include the same error in their descriptions of the framegroup structure, i.e. they both say struct { long type; // Value != 0 trivertx_t min; // min position in all simple frames trivertx_t max; // max position in all simple frames float time[nb] // time for each of the single frames simpleframe_t frames[nb]; // a group of simple frames } but it should be struct { long type; // Value != 0 long nb; // number of pictures in group trivertx_t min; // min position in all simple frames trivertx_t max; // max position in all simple frames float time[nb] // time for each of the single frames simpleframe_t frames[nb]; // a group of simple frames } I guessed where those tasty bytes of crucial extra info were stored and turned out to be correct. I imagine the radius thing was probably being used as a culling shortcut at some point
FWIW, ToeTag included the source as a download and it read MDL files successfully
http://wantonhubris.com/toetag/ToeTag.html Can't promise it's pretty, but it works. :P No writing tho... Another error in the quoted text (kinda)
float time[nb] // time for each of the single frames Aha, you wish! It makes you think that you could have a variable framerate in a framegroup animation. And in software Quake you can. But in GLQuake (and basically all engines nowadays) this is broken, and the time value of the first frame sets the animation rate for the entire thing. So the only option compatible with all engines is having the entire sequence animate at the same rate. To add insult to injury, you still need to set the values correctly for software compatibility (plus any engines which might try to fix the bug - a futile effort by now). And they aren't set how you'd expect: wrong: [0.1, 0.1, 0.1, 0.1, right: [0.1, 0.2, 0.3, 0.4, http://image.noelshack.com/fichiers/2015/42/1444897285-gatling1.png
http://image.noelshack.com/fichiers/2015/42/1444897286-gatling2.png http://image.noelshack.com/fichiers/2015/42/1444897284-gatling3.png http://image.noelshack.com/fichiers/2015/42/1444897284-gatling4.png http://image.noelshack.com/fichiers/2015/42/1444897282-gatling5.png Quakespasm webm: http://webm.host/5aed6/vid.webm Darkplaces webm: http://webm.host/9f98d/vid.webm But I think that muzzle flash is a bit over the top. I would tone it down a bit, it looks cartoony as it is now. Or was that the intention?
Preach - Cheers! That's some useful info to have. It sounds like it could be nice to have the corrected
Daya - I like the cut of that weapon's gib. I think I'd have gone with a smaller/subtler muzzleflash, and I'm not too big a fan of the raised "idle pose" of the weapon, but basically do what you want and don't listen to me. I may update the quake wiki myself with all the
You worried that team fortress might outcode you, but there's no doubt now your model surpassed what they could do.
Realized I missed to play an extra frame in the programming for the barrel to rotate smoothly during the shooting loop. Also fixed the non-fullbright pixels on the muzzleflash texture.
Quakespasm webm: http://webm.host/b2613/vid.webm Darkplaces webm: http://webm.host/08742/vid.webm Also, I have started working on the Nail Infantry, which is basically a recreation of Doom 2's Chaingunner. Taking the Enforcer as a base, I have 2 designs in hand, but I don't know which one to choose: http://image.noelshack.com/fichiers/2015/42/1445001145-nailinfantryconcepts.png Obviously the messy textures are temporary. I'm just looking for the right shape. What does it look like when played against a Quake enemy? First impression is really good but just wondering if the muzzle flash might be a little too big?
Nevertheless, I like it. It does take up a lot of the screen, yeah. Resist the urge to put all your work front and center - AAA shooters that lavish detail on their guns and then make them cover a quarter of the screen are sort of irritating. When the gun is firing, the muzzleflash comes all the way up to the crosshair.
Still gives me Wolf3D flashbacks, too. :) How did you solve the problem of vertex interp on the rotation? If I stop firing on the right frame does the gun collapse on itself? Depends on which firing frame is the last one before switching to the spinning down animation. The farther it is to the first spinning down frame's barrel rotating angle, the squichier the interpolation frame gets.
But because the firing frames have a self.nextthink of 0.05 instead of the traditional 0.1, the "collaspe" is barely noticeable when it happens. As for the muzzleflash's size, I'll wait until level playtesting to see if the size needs to be changed. Also, I modelled the muzzleflashes (there's actually 2 of them, I have to rotate the barrel 45� at each frame [360/45=8, it takes 2 frames for a proper minigun-like muzzleflash to animate, when one finishes its 2-frame animation, it goes back at the tip of the barrel, gets minuscule and let the second muzzleflash do its animation, and so forth], going further would make the barrel look like it's going so fast it would collapse by itself, like you said) so that it's extremely minuscule just at the tip of the barrel's interior, and it follows the barrel in every frames until the firing state, where it gets out just a few little units forward. I made a convoybelt with an injector.
It moves on 40 frames, so one cycle takes 4 seconds. I also made a sprite that lights the injector. It lights with 14 frames on self.nextthink = time + 0.01; To make them work synchronical I need a wait time of self.nextthink = time + 2.7; This works well for 42 minutes, then the sprite starts to act slow, after 65 minutes it's out of order, meaning it misses the synchronity and falls out of the movement. I tried time + 2.69 and time + 2.71 but that doesn't seem to help. Do time accounts excist in that timescale? Of course I can say, finish the map in 42 minutes, but that's a hatch of the hat. as always, it depends on the engine.
sv_gameplayfix_multiplethinks 1 (this is always enabled in quakeworld servers and thus default-enabled in fte, and default-disabled in dp, I don't know of any other nq engine that implements an equivelent) NQ servers normally only run one think per frame. if the entity thinks faster than a game tick then it can easily miss a think. the time global will be larger than the nextthink value used to be. additionally, floats have limited precision, centered around 1. that is to say that as the float becomes larger, it can no longer hold smaller numbers quite so precisely. this means the server's framerate might slow down as its own timing degrades. this is especially true of 'listen' servers. it shouldn't really be a problem for 100fps at 42 mins though. 1000fps might start to have some issues though. bigger intervals will be more reliable with larger time values. As I expected this goes far beyond my hat.
I'm not thinking about a server at all, neither that I can imagine what happens on the moment my console opens. I fear it is much more than my small mind can suspect, as I am only translating my poor knowledge into the quake world my singleplayer attitude has learned. I would gladly know how to get around this repositioning every once in a while, but.., would it change things if I turned the sprite into a static entity, at least the convoybelt is also. So maybe they interact synchronical? Maybe I misunderstood. Was this a mod entity to make a conveyor? If it is just trains then maybe you can't fix it...
I made a static entity of a convoybelt and a sprite of an injector.
For some reason these two interact fairly well, only after 42 minutes there is a delay of a second. This makes the injector mismatch. My first intu�tive respond is to give the sprite, called info_spark, a delay of 0.1 sec. So when the player arrives after let's say 30 minutes it is synchrone. I don't know the difference in behaviour between static entities and sprites. Maybe that's the cause. Therefore my question. Would it change things if I turned the sprite into a static entity?
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |