i see a potential problem here. you have a variable 'vec' being passed into the function, and you also have a local variable 'vec' being declared at the start.

remove the local variable and that may fix your problem. 

I'm not so familiar with the stats although I'll believe you.
Remove the local variable, is that

//vec = normalize(vec);  

No, this:

//local vector vec;

Then you'll be using the variable you passed in rather than the local one. 

yeah, the normalize(vec) is actually very important. normalize makes whatever the vector passed in a unit vector.
that is to say, the vector is reduced from whatever it was so that it's total length is 1.
this is how you can then multiply vec by an arbitrary number to create consistent velocity (ie: projectile always travels at 600 units per second). if you didn't normalize, the velocity of the projectile would change in relation to how far apart you and the enemy are. 

I included it in the qc, but I wondered. I always thought that the

org = self.origin + v_forward * 30 + v_right * 8.5 + '0 0 -24';

positioned the point of shooting from the monster, where the last three numbers were the actual position of its gun.

With these coordinates I get a shooting frogman which shoots its arrow 24 units above its gun, but the arrow goes left above me.

http://members.home.nl/gimli/frogman.jpg 

org = self.origin + v_forward * 30 + v_right * 8.5 + '0 0 -24';

assuming makevectors has been run, the above line will set org to a position 30 units in front, 8.5 units to the right and -24 units up (all monsters are 24 units above the ground, so -24 will make it right on the floor).

the reason it's shooting nuts is because when you call launchharpi, you are calculating the trajectory with self.enemy.origin - self.origin but your spawn point is at org.

in order for it to work correctly, the function call should either be:
Launchharpi(org, self.enemy.origin - org);
or:
Launchharpi(self.origin, self.enemy.origin - self.origin); 

It might as well be above my hat but it seems to work.
I just get a little confused by the -24 as it still shoots above the players head.
It reminds me at the moment I placed the new monster in game and it flew 24 units above the ground.
I decided to lower all frames. So it is this difference that shoots the arrow overhead. Can't think of a way to overcome this now. 

 

just take -24 off.

it's shooting up because you are doing:
self.enemy.origin - org

think of it this way:

self.origin = '0 0 0' (you)
self.enemy.origin = '128 0 0' (monster)

this would be both the monster and you being at the same height.

but now, you are calculating:
self.enemy.origin - org
let's forget about v_forward and v_right for now.
that makes org = '128 0 -24' because the math is: '128 0 0' + '0 0 -24' = '128 0 -24'.

so think of it like the enemy.origin is the gun which is -24, so it has to shoot up towards 0.

removing -24 from the vertical element will make the monster shoot straight horizontally.

remember shamblers, how their lightning goes downwards or droles shoot at the player's feet. the drole shooting at the player's feet was completely unintentional and was a by-product of the spawn point of the drole missile (which is above the origin of the monster, so it shoots downward at the player which is the opposite of what's happening to your monster). 

if you want the monster to shoot from it's feet, then change the trajectory vector.

instead of Launchharpi(org, self.enemy.origin - org);, do Launchharpi(org, (self.enemy.origin + '0 0 -24') - org); which will make the monster shoot at your feet too. 

Thanks for your clear explanation!

I understand now how this positioning works.
I just couldn't understand why the arrow kept shooting above the monster, although the cooordinates were right.

Then I realized when I imported the monster into Qmle it was 24 units above the ground.
So when I put these models back in game the arrow shoots right.

Now I need to know how I can lower the model 24 units and keep their original shooting point.
It sounds kinky, but it seems Qmle imports models rather rough.
One moment they are exact on the 0'0'0 axis.
But after playing in game they suddenly drop 24 to 48 units down the zero line.
Also it seems as if there is no difference between the zero line and, let's say a multiple above or below. 

all monsters' feet are at -24 units. 

Noone has UnrealED3 (UT3) installed? 

Heh - my first time ever looking at UnrealEditor. The level looks pretty smart, You obviously blocked it out with the brick texture. I never work like this, although I know a lot of people do. I actually dont think that the red brick texture should be used anywhere in this map. I think if you went for some tech-style textures (metal panels etc) which would go with the trim. The trim (the meshes and stuff) look like they are out of a spaceship, or an oil-rig or something.
I think you would find that the level would start to materialise into something which looked a bit better-themed if you slowly went through the map and replaced all of the brick textures, with dark metal panels and suchlike.

The layout looked prety interesting - multi-tiered, and nice interconnection. So I would say you should finish it for sure. Just do more with tech-style texturing and good old brushwork :D

Nice work 

Tell me, what features do you like and what parts do you not like. anything goes.

It will be implemented in Erlang with plugins written in Erlang. The newest release of Erlang includes wxWidgets and OpenGL so I decided to learn how to use wxWidgets. 

I'd say these are the important features:

Good Cameras
Decent Texture System, with texture lock and multiple WAD support
Ease of use entity listing (def, fgd, whatever)
Ease of install / setup
Slice Brush Tool
Vertex Manipulation Tool
Prefab Library

Probably some stuff I'm forgetting there. 

Viusal (named group) hiding is nice as well. 

| Good Cameras
Is that good camera controls? Ability to change camera positions quickly? i have an idea (look below)

| Decent Texture System, with texture lock and multiple WAD support
I consider multiple part of the virtual file system I will have to make.
Texture locking is for moving brushes, correct?
And what kind of User Interface controls are needed, tagging textures and using that to browse sounds usefull for instance.

| Ease of use entity listing (def, fgd, whatever)
I already started with using a fgd file to see how i can make my own format: http://3spire.com/quake.txt
it is based on Erlang terms and can be loaded easyly, will this format work?
Configuration will also use this kind of file, so that it can be loaded easily.

| Ease of install / setup
I plan on using the same install system of Wings3D

| Slice Brush Tool
| Vertex Manipulation Tool
These should be able to be done with plugins

| Prefab Library
Also done with plugins, so that the prefabs can be configurable

| Visual (named group) hiding
I would like to be able to provide multiple views into the same map as represented as named tabs. Each tab can control visibility of each brush/entity and the positions of the 3d camera and 2d grids.
Another idea is to make brushes and entities each belong to multiple layers, and hiding/showing layers are per tab as well. 

QuArK does some things really well.

-I LOVE the interface (how you create and edit things) and could never get into the major brainfuck that are the radiantish editors (Blender is easier...). Not to mention not having a mess of lines but just dots for the grid. So such an interface would get my love.

-All the texture alignment features (apart from locking I think).

-grouping things in folders, also being able to hide those.

The texture browsing is badly implemented, vertex editing is plain horror.

So Vertex editing is what I am after the most. Especially if you could then triangulate for new edges. 

Cameras - all of those. Extras like 'walkthrough mode' and so on are just a waste of time, although a feature I'd like to see is 'mangle readout' so that placing camera entities inside the level becomes easier.

Yeah, texture lock means it doesn't move when you move or rotate the brush - not an easy technical challenge. Changing projection options between local / global is useful as well.

Tagging isn't as useful as it sounds, even though it does seem like you're going for an 'all wads on the HD' approach (which is great). I say this because wads are usually named in a fairly logical fashion - the ones that aren't tend to be not very good. For me such a feature would be an extra. If the texture listing is alphabetical then you're probably good.

Having said that a 'currently used in map' toggle would be good. Worldcraft is a popular editor (I use it as well despite the bugs) which has a very nice texture system - you couldn't go wrong by copying it.

For an entity list remember that it needs to be editable by mappers who may not have any coding knowledge - the simpler the better.

Tabs = win. Especially if they're user editable.

And finally, make everything you can customisable as far as the interface goes. Nobody works the same way, so the easier it is to turn the grid from lines to dots or chocolate drops the better. For example :)

Like with most 3D editors, ease of use and end user customisation options tends to win out over powerful functionality. 

'Worldcraft has a nice texture system' that's only true if you count not having to convert the wads (in 3.3 at least, 1.6a has shitty texturing). 

What will yours do that will set it apart from others? Or is it just a fun personal project to learn programming stuff?

I think strong brush manipulation tools are key for working with large and complex objects - actions like flipping, rotating, scaling are very helpful and save time for the mapper.

Also, it's probably not a must have feature but I really love 3-point clipping. 

What will yours do that will set it apart from others? Or is it just a fun personal project to learn programming stuff?

this is the first thing that came to me mind.

as grahf said, good brush manipulation is a must. rotating groups of brushes by arbitrary angles (with intelligent vertex snapping onto the grid). more powerful automation of texturing over curves (being able to propagate texture alignment as if multiple faces were a single one, for example). mixing between the straight forward regioning of gtkr and vis groups of WC.

basically this late in the game, it'd take a lot to make me switch editors. 

I have always wanted to create a mapping program, but the interface bits is my more immediate concern.

I would like to get this to a level of making maps for Nexiuz.

I also would like to model the editor to be more like Wings3D, where there are commands that can be done on vertex, edge, face, object.

And concerning the convex nature of brushes I would like to be able store a complex brush while editing that gets decomposed as multiple brushes when saving to a .map files.
That should solve many problems with brush editing I think. treating it like a 3d model rather than a convex object.

for curve texturing, that sounds possible with the internal representation of the brush I have decided to use. And it annoyed me as a mapper that I had to manually adjust texture offsets to get them to match.

This is not the best time for me to start a project (getting married in a month and I travel alot) but this will defiantly sustain my attention. 

"And concerning the convex nature of brushes I would like to be able store a complex brush while editing that gets decomposed as multiple brushes when saving to a .map files.
That should solve many problems with brush editing I think. treating it like a 3d model rather than a convex object."

This is something that I wanted to do for ToeTag but, brother, it's a bitch. If you can get it working it'll be great but I haven't found a nice, reliable way to break down meshes into convex chunks yet.

Although I haven't tried my octree idea yet... that one had promise.