 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
http://people.pwf.cam.ac.uk/ajd70/progs-14-10-05.zip
Here we go, fixes: Ammo counts now work, and the lava nails are in. Cycling forward is fixed, although multi-rockets might still break it. I'll do backwards once the weapons list is locked. The problem with non mastered/triggered func_trains is sorted. A few other cosmetic changes like reducing the number of idle noises from the chainsaw. Haven't been able to reproduce the chainsaw door bug yet, so it's still at large. The new ammo code is the thing most likely to cause problems, if you notice at any time that the ammo on the top doesn't update correctly, let me know what you did so I can fix it. Lava nails should also be considered fully featured, so let me know about any bugs encountered. If I've got this right, this is the list of known things that still need doing: Fix chainsaw door bug. Add teleporter flag. Improve moster reaction time when waking up. Add multirockets and exploding shells? Backwards weapon cycling. Anything else? I think that backward weapon cycling has to be a priority now, if only so I don't have to listen to that bloody chainsaw starting up every time...
Forward cycling is fine, and it completely ignores the possibility of MR weapons. Ammo counts change correctly as well. I have noticed a few issues with the chaingun, though. The weapon spins so fast that it looks to be convulsing when I hold down the trigger (I guess because of DP's model interpolation). The weapon is also far too powerful. It drops knights with 1 hit, and gibs eels with 1 hit as well. Also, it uses 2 ammo per shot, for some strange reason. I am wondering if you are going to want reskinned lava guns, because they don't need those stupid warning arrows on... Now I understand why the Chaingun is so sick...
Preach, with your permission, I'd like to re-write the code for the chaingun to be less evil, less messy, and easier to balance once we get to that stage. If you've made updates to w_chaingun.qc, then I'd prefer to work from your copy. Only things I've changed in w_chaingun.qc are reducing the frequency of gibs spawned so it doesn't cause packet overloads when you unload on a zombie, and since the whole thing is a mess anyway, it might not be necessary once it's done. So yeah, just work from the FC version and that'll be fine.
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?
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2026 John Fitzgibbons. All posts are copyright their respective authors. |