[Killfrenzy]

1) Is it possible to code it so that ships DON'T get vapourised by the beam? Can they just explode 'normally?'

2) YOU STILL DON'T GET CREDIT FOR THE KILL!!! <-- My biggest gripe!!

On another note, who was doing beam helixes? How are they coming along? (WANTS THEM!!!)

[IceFire]

3) Limited range.

4) Correct sound.

5) Cycling or non-cycling.

[DTP]

Originally posted by Killfrenzy
1) Is it possible to code it so that ships DON'T get vapourised by the beam? Can they just explode 'normally?'

2) YOU STILL DON'T GET CREDIT FOR THE KILL!!! <-- My biggest gripe!!

On another note, who was doing beam helixes? How are they coming along? (WANTS THEM!!!)

everything is possible, if you have the time and the drive.

its a lot like the average essay, where you form an idea, you mold it, you arguement against it and for it, and finally you have a layout.

But we all know that an essay is easy to write because we all know how to write.

But to write code is a different mather, well especially since we are dealing with code done by other people. for exp. i have a very good picture of how the file system works, how it builds a file list, how it acces them, etc etc.

But i have little or no idea about the rendering, the weapons or the ship.

True i fixed the secondary bug, but that was easy, since the bug was a genuine bug where some Programmer remembered wrong and put in the wrong value. To tell the truth, the way he wanted it to be done, was not possible.

the only person who has dealt with beam weapons so far is Bobboau. And he is still learning of stuff. and beleive me there is a lot of stuff to learn. Also, he might have other interests, for example his POF editor.

I´m also learning, but i have this huge kick ass book from the creator of C++. A bit hard to understand for the novice, but once you get the hang of it, its easier, not easy, but easier.

so what i saying, give the man some time. evetually, he will come around to it.

[Kazan]

the helix position at point (x, y, z) should be determined as follows

assuming that +z is the direction of travel

(sin(z), sin(z), z)

[DTP]

Originally posted by Kazan
the helix position at point (x, y, z) should be determined as follows

assuming that +z is the direction of travel

(sin(z), sin(z), z)

i think i get what you mean, but where does ít aim.

[Kazan]

down the Z axis

[DTP]

Originally posted by Kazan
down the Z axis

yeah yeah, but unless i misunderstood it,

who?. .

[Bobboau]

I already have fixed the kills thing and the vaporize thing and the cycleing thing (though cycling is a bit of a hack at the moment it is relaited to shots(the beam field) and firewait) sound is proveing to be a major pain in the ass, and the limeted range I want to wait untill I get sounds fixed

[IceFire]

If those things are present in the next release (or the current one) then TBP will release and require the Open version of the EXE for play.

[Inquisitor]

Bob: I'd call these bugs, is that something that can make it into CVS asap?

[Bobboau]

well if they arn't in there now they will be,
I'm going to dedicate myself to fixing the fighter beams once and for all this weekend

[Fury]

Originally posted by Bobboau
I'm going to dedicate myself to fixing the fighter beams once and for all this weekend

WOOHOO! Everyone praise the mighty Bobboau!

[Solatar]

*praise praise praise*

[Bobboau]

vaporised bug-fixed
kill getting bug-fixed
sound bug(s)-fixed
next up range

[vyper]

*pats Bob on head* Good programmer! Gooood boy!

[Inquisitor]

now all we need are committs

once he's got em all licked, of course

[Bobboau]

I've given beam weapons a range, I'm not sure if they do damage or not beond the set range, but they only render to a table specified range, next I shal implement damage based on distance.

[Solatar]

Don't forget cycling!

[Bobboau]

didn't mention cycleing becase it's been in the code for months now

OK, commiting all improvements, to use the new limeted range stuff

Code: [Select]

$BeamInfo:
      +Type:                        3
      +Life:                        0.9
      +Warmup:                      -1
      +Warmdown:                    -1
      +Radius:                      4.0
      +PCount:                      0
      +PRadius:                     0.0
      +PAngle:                      0.0
      +PAni:                        particleexp01
      +Miss Factor:                 0.5 0.7 0.9 1.1 1.3
      +BeamSound: 84
      +WarmupSound:                 151
      +WarmdownSound:               157
      +Muzzleglow:                  minbari_bg1
      [i]+Shots:                       1[/i]
      +ShrinkFactor:                0.0
      +ShrinkPct:                   0.0
[b] +Range: 2500
+Atenuation: 0.75[/b]
      $Section:
...


shots is the number of beams that will be fired at a time,
more importantly the new values

+Range:
this is the max length the beam will fire if you are beond this range it does not apply any damage (though it may still show an impact explosion), also the beam will not render any further than this and the beam will gradualy fade along the length, I have taken into acount for beams getting shorter when they hit stuff so there should not be beams that sudenly look faded when they hit stuff.

+Atenuation:
this is the point (between 0.0 and 1.0) along the length of the beam that damage will start to weaken, by defalt it is set to 1.0 wich means damage does not get atenuated untill the end of the beam, wich means it does not get atenuated. if you wanted a beam that was strongest right at it's sorce you but was half as strong half way down the beam you'd set it to 0.0, if you wanted a beam that was 100% powerful intill half way down the beam you'd set it to 0.5

the only thing the current beam system does not suport is warm up/downs and I don't think it is going to get it any time soon, though I may play with it a little.
but bad things happen every time I've tryed to get it to do that

[Bobboau]

test me