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. 

In fact, if you've got a handle on things like how to do texture locking and breaking down meshes and that sort of math in general - we should get together and maybe do a cross platform version of ToeTag or something. 

concave, not convex, right?
That feature would be a true killer feature. 

dunno if this is what you mean, but it would be awesome if you essentially build a 3d mesh out of n-sided polys just like in 3ds max and the editor would automatically split ngons into tris. afterwards, it would look at the face normal and whichever direction is closest, north, south, east or west, it would simply extrude the face backwards, keeping it parallel.
ie: you make a collection of faces that face upwards, it would extrude the face down allowing you to make cool trisouped terrain easily. the same could be applied for caves. 

Madfox looks very nice the frogman :) 

Type of advanced brush treatment you're describing isn't in any bsp editor I've seen (anyone else?) so if you need testing then let me know.

I'm pretty busy so testing to destruction I probably can't do, be an update a week wouldn't be a problem. 

http://groups.google.com/group/maperl 

 

Yeah, all the mappers are here. :) 

all editors are there....

preach, you've got email.