 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
The chaingun was producing three gibs per shot, it just wasn't feasible. Most things died fast enough for it not to matter, but zombies you can blast a lot of chunks out of before they die. One thing I thought of which might be important for rewriting the chaingun; quake doesn't like things that occur faster than every 0.1 seconds. You can do it, and it'll work a lot of the time, but it runs the risk of being very framerate dependent. The quake engine will ensure that there are at least 10 frames per second of game time, and will effectivly slow down the game clock if the computer can't keep up. There might be small fluctuations in the rate of firing depending on how the frames line up with the times, but you should always get 10 nails fired between time and time + 1.
If you do something with a shorter delay, say 0.05 seconds, a person who's only getting 10fps would only get 10 shots per second when they should get 20. This might explain why the chaingun fires rounds 2 at a time and then does two sets of damage in a burst, besides the slight benefits to the network updates gained by doing this. So it's something to bear in mind if you rewrite it. Perhaps the best solution if you want such a high rate of fire would be to check frametime each time it fires - if the framerate is below 20 fps, fire two shots and set the delay to 0.1, otherwise set it to 0.05. Bit more work though. The other thing about the chaingun and model interpolation is that it only uses two frames, which for non model interpolation suffices to give the illusion of a rotating barrel. With modern engines it'll be obvious it's rocking back and forth, might be worth fixing that. I've got a good idea about how I'd go about this so it would look smooth on interpolating engines, but still look like it rotates in older engines, so I'll put it into the rewritten chaingun once it's done. Positive news - fixed the door bug, and I've put in spawning by a spawnflag - 64 makes monsters teleport when triggered, and 128 makes them teleport in the same way, but silently, for doing reinforcments that have "moved into place". Can't upload it yet though, connection issues. Do people want multirockets? I never found them that handy myself, but the code is half there if people so desire. You Reduced Gibs?
blasphemy! :o That is why I went ahead and built the gyro physics.qc patch into my basic Quake. The gibs are extra bouncy; the next step will be to get them to flop around and shake like jello. One thing I thought of which might be important for rewriting the chaingun; quake doesn't like things that occur faster than every 0.1 seconds.
Thought of that. It's averaging 20 for me when I test it. The chaingun was producing three gibs per shot, it just wasn't feasible. Most things died fast enough for it not to matter, but zombies you can blast a lot of chunks out of before they die. At 60 entities per second, I doubt even Darkplaces would be able to cope... Perhaps the best solution if you want such a high rate of fire would be to check frametime each time it fires - if the framerate is below 20 fps, fire two shots and set the delay to 0.1, otherwise set it to 0.05. Bit more work though. It's much easier and more consistent to fire 2 (or more) bullets every 0.1s so that's what I have planned... The other thing about the chaingun and model interpolation is that it only uses two frames... I've got a good idea about how I'd go about this so it would look smooth on interpolating engines, but still look like it rotates in older engines, so I'll put it into the rewritten chaingun once it's done. I noticed that as well. It's a shame really, because it's an otherwise nice model. If you're planning what I think you're planning, then it won't work, because there are other parts of the weapon visible, not just the barrels. I think that a model like the SNG would look best, but we don't simply want a reskinned model. Do people want multirockets? I never found them that handy myself, but the code is half there if people so desire. I will be able to comment on their usefulness a bit more after I actually complete DoE, but my early thoughts are that cluster bombs would be very useful (and more useful if they split up after hitting a monster). Multi rockets would probably be less useful, although they can clear rooms out very nicely. So yes, i want to see them. However, I think we need to limit the ammo on these. Maybe perhaps to 3/6 per box and maximum carrying of 50 ? One last thought about the chaingun before I end this long post: Do people think that the knockback is too much? I've finished re-writing the chaingun, all I have to do is send it to you. I hope you got my previous e-mail.
Haven't been able to e-mail for a few day previously, but I've just checked them now and got the last message about the
I'd prefer more talk, more screenies, more things to test, more of everything! These times where there's nothing that I can do to contribute to this project are making me think about everything else too much...
http://people.pwf.cam.ac.uk/ajd70/progs-14-10-05.zip
Contained herein: The new improved chaingun code, thanks lardarse! Also, teleporting monsters, flag 64 for teleport when triggered, flag 128 for silent teleport. The troglodyte now no longer locks up when it casts the large explosion. Doors can now be opened by the chainsaw without jumping around. Maybe a few other fixes, I'm not sure. So still to come is the enhanced chaingun animation and the multirockets. Maybe by Sunday... http://people.pwf.cam.ac.uk/ajd70/progs-19-10-05.zip
or just go to http://people.pwf.cam.ac.uk/ajd70/ and select the file with the latest date. If people release things that require stuff I don't have it doesn't tend to keep me happy =/ More screenies!
another little buggy: i have a secret which is triggered by the the armor itself (it targets trigger_secret), I get the message and secret sound but the number of secrets I found doesn't change. It works in normal quake.
btw Tronyn: it's really a time to update the site with more info and screenies and maybe something more. normal trigger_secrets work as they should, while one secret with 'targetname' don't. I also wonder why.
The main changes are:
- Instead of using 2 ammo per shot, it uses 2-4 ammo per shot, but the shots are now a consistent 0.1 seconds apart, instead of an inconsistent 0.05 seconds. - Damage was reduced from 40 per bullet to 20ish. but I nerfed it too much, so it's back up to 25ish. - FC had some weird MultiDamage hack in teh code (as used in the shotgun code) which I removed to make the code be handed haster, and also because the gun is supposed to be firing the bullets 1 at a time. - Recoil has been recuded by about 30%, and recoil in the vertical direcion is significantly reduced. I don't think that this gun should be non-damaging RJ replacement weapon... Other than that. it's just cleanup. I'm sending an updated version to Preach in a moment, because I nerfed it a bit too much, and also because it's not behaving exactly as expected. But I'm happy with it. Onto the bugs I've noticed. The slug ammo no longer decreases when the chaingun is firing. This is likely to be because of a change that Preach made to make it work properly in the first place that I didn't know about. Also, it doesn't display when you are holding the gold or silver key. I think that's everything... I kinda nerfed recoil but 60% instead of the desired 25% so I'm fixing that as well.
metlslime: lol I had to make a few changes to the chaingun to make it compile, and while I was at it I fixed the ammo, so the patch released today has chaingun working at full capacity. I'll try and merge the file you send me so all the changes come through without breaking things.
metlslime - quite a few things have been broken because a lot of the code was rewritten before I got it. About half of the monsters use some extra functions and fields to reduce the amount of duplication within the monster code. To my mind it's kinda a wierd thing to do, it reduces the progs size, but at the expense of adding fields that take up just as much memory if not more. But the baron monsters would have to be completely rewritten from scratch to change that, so I'm inclined to fix the code that's there rather than scrap it all. On the other hand, ths secret issue could just be a small conflict oweing to the addition of the master field. That's caused problems in the past. Key icons I was aware of, but I thought I'd consult about them first. The code now offers many additional keys, copper, bone, things like that. So one solution I was considering was to get rid of all the power up icons(to my mind they're not that useful) and use those slots for icons for the remaining keys. Otherwise I could make it so just silver/gold keys get icons like before, but it's not very consistent. Also, with all those keys, things might get confusing - would having the key icon blink until you got it be helpful or distracting? The trigger to start the blinknig would be trying a door that needed a key and getting the "you require the obsidian key" message. I'm kinda leaning away from it now I've though about it, but I'll put it out there anyway. Any thoughts? why on earth would you need that many keys? you'll need to code a keychain soon.
wow, that was terrible. o.o Part of the problem with making it compile was probably that you're using frikqcc to compile it, and I'm used to using fteqcc. I think I have everything sorted out in the version that I will send you tonight...
Key icon blinking would be distracting. I know that there are now 7 keys available, and bar engine changes, it's going to be tricky to display them all. I would be inclined to do it, so that you display 1 of the key icons if you have at least 1 key, and display bth of them if you have more than 1. Then, use an impulse to (centre)print the keys that are being held. Speaking of powerups, how many will this project have? I assume that there will still be the quad, the pent, and the ring, but what else? I have a problem. It looks like spawflag64 teleporter has a bug - it crashes the map when I try to spawn an orge. I get a message:
EDICT 262: modelindex 188.0 absmin '2079.0 -737.0 -1.0' absmax '2145.0 -671.0 89.0' movetype 4.0 solid 3.0 origin '2112.0 -704.0 24.0' classname monster_ogre model progs/ogre.mdl frame 1.0 mins '-32.0 -32.0 -24.0' maxs ' 32.0 32.0 64.0' size ' 64.0 64.0 88.0' use monster_use() health 200.0 takedamage 2.0 view_ofs ' 0.0 0.0 25.0' flags 544.0 waterlevel -1.0 watertype -1.0 yaw_speed 20.0 spawnflags 128.0 targetname door4t noise ogre/ogwake.wav th_stand ogre_stand1() th_walk ogre_walk1() th_run ogre_run1() th_missile ogre_nail1() th_melee ogre_melee() th_pain ogre_pain() th_die ogre_die() mdl progs/ogre.mdl pausetime 100000000.0 hmodel progs/h_ogre.mdl Host_Error: PR_ExecuteProgram: NULL function And I haven't checked it enough but it seems like func_wall's invisible mode (spawnflag 1 doesn't work properly). Also I feel like this mode has really a deal with black magic: something strange happens to my editor, it goes crazy. Objects' properties change somehow without my help, entities turn from one to another... err I hope that's just a bug that won't return after I restart my editor. But if not.. Preach are you sure you didn't use voodoo or something working with your progs.dat? And I had a crash saving the game the other day, but I haven't tried to repeat it since. Can anyone else look into this?
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |