Func_Msgboard: Modelling Help\Screenshots\Requests

Posted by Preach on 2009/05/17 18:52:10

It has always been difficult to get decent models for quake 1. So a thread where people can get advice on making models and post a work-in-progress for critiques is long overdue.

Any requests for models may well get met with silence. Specific requests will likely stand a better chance; "I'd really like a knight but carrying a shield" might be better received than "we need a mdler to join our mod remaking counter-strike for darkplaces".

First | Previous | Next | Last

Looks Good

#1034 posted by SleepwalkR on 2015/10/15 12:31:31

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?

It Was Meant To Be Big, Yes. Kinda Like TF2's Minigun

#1035 posted by aDaya on 2015/10/15 13:19:50

#1036 posted by Kinn on 2015/10/15 14:43:11

Preach - Cheers! That's some useful info to have. It sounds like it could be nice to have the corrected .mdl format info in the Quake Wiki :)

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.

To Wit

#1037 posted by Kinn on 2015/10/15 14:49:55

I may update the quake wiki myself with all the .mdl info. Could be a fun little distraction.

Nice Work Daya

#1038 posted by Preach on 2015/10/16 01:03:36

You worried that team fortress might outcode you, but there's no doubt now your model surpassed what they could do.

Daya

#1039 posted by FifthElephant on 2015/10/16 01:13:04

that's really awesome to see in game, love it mate!

Lovely Stuff

#1040 posted by Skiffy on 2015/10/16 07:53:17

Nicely done man. Look forward to seeing a map use that weapon.

Gatling Gun Polishes + Nail Infantry

#1041 posted by aDaya on 2015/10/16 15:13:17

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.

Thats Cool

#1042 posted by ijed on 2015/10/16 15:56:26

I'd say the bottom one, since it will give him a slightly more recognisable silhouette.

Muzzle Flash

#1043 posted by Mike Woodham on 2015/10/16 17:09:33

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.

#1044 posted by Lunaran on 2015/10/16 17:27:33

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?

#1045 posted by metlslime on 2015/10/16 18:33:49

at least in fitzquake, any frame with a muzzleflash is not lerped into or out of.

Lunaran

#1046 posted by aDaya on 2015/10/16 20:59:53

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.

Queer Question

#1047 posted by madfox on 2015/11/03 03:22:09

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.

#1048 posted by Spike on 2015/11/03 05:15:09

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.

#1049 posted by necros on 2015/11/03 05:18:42

thankfully you just need to reposition everything periodically to get around that!

Well

#1050 posted by madfox on 2015/11/03 05:39:25

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?

#1051 posted by necros on 2015/11/03 13:14:58

Maybe I misunderstood. Was this a mod entity to make a conveyor? If it is just trains then maybe you can't fix it...

Static Entity & Sprite

#1052 posted by madfox on 2015/11/03 23:46:33

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?

Break The Loop

#1053 posted by Preach on 2015/11/04 00:29:31

You need to rewrite your code so that the conveyor belt is in charge of the sprite. Get rid of the 2.7 second delay so that the sprite doesn't loop at all by itself. Instead make it so that when the conveyor belt hits frame 40, it triggers the sprite to begin animation one more time. Then they cannot go out of sync.

Sure

#1054 posted by madfox on 2015/11/04 01:44:31

But what piece of code should I use here:
convoybelt = truns.qc
void() trun_stand40 =[ 39, trun_stand1 ] {};
for a sprite = vonk.qc
void() model_vonk

something like:
void() trun_stand40 =[ 39, trun_stand1 ] {vonk_stand1();};

#1055 posted by madfox on 2015/11/04 23:40:27

I can't integrate framerates of a sprite with a static entity.

So.., if I add a statement to the convoybelt.qc that goes like the grenadecode it works.
It looks like:

void() LightVonk =
{
self.movetype = MOVETYPE_NONE;
self.velocity = '0 0 0';
self.touch = SUB_Null;
setmodel (self, "progs/vonk.spr");
self.solid = SOLID_NOT;
vonk_stand1 ();
};

Now it sparks all the time.
That wasn't my purpose.

Nail Infantry! (Yeaaah Boyyyy The Third)

#1056 posted by aDaya on 2015/11/15 18:28:07

#1057 posted by JneeraZ on 2015/11/15 18:52:32

Nice work, this guy seems like a solid addition to the game!

Yeah I Like It

#1058 posted by nitin on 2015/11/16 14:11:11

First | Previous | Next | Last

You must be logged in to post in this thread.