DescentBB

Image wrote:Speaking of complaining, I am going to whine about some small thing now:

When I load a level, DLE-XP makes it all zoomed out!!

..see?

Yeah, I noticed that too. When you load a level, the thing goes to minimum zoom...

[edit]A\Z key panning seems to work great now... except that Z seems to pan in, while A seems to pan out. No big deal, though.[/edit]

Not here, but the current version is buggy anyway ...

Wait till I have the bot trigger feature really done.

With the new teleport triggers and whatnot, is there a way to choose which direction is up? I added a silly secret to Burp 2 with a teleport but I keep appearing upside-down and realy wouldn't like to re-make all them cubes the other way around...

The ship will appear at the teleport destination with the exact orientation it had when entering the transmitter. Given it was aligned to what was the 'floor' of the mine in the editor, all you need to do is to align the destination area accordingly. There's nothing you can do though if the pilot isn't aligned that way.

A/Z panning reversed.

Diedel wrote:Techpro,

• I might add such a button (if I find the space for it in the dialog), but for the time being move the mouse into the mine view pane and hit the 'Tab' key to switch to the current side's opposite side.

Tab does that??? I never noticed... and I've never seen it in the menus. Perhaps it should be listed in the "Other" menu?

Yeah, man.

I always hated DMB2 not offering an option to quickly switch to a side's opposite side, so I added they tab key shortcut to that.

Okay...Well atleast I can picture why he's upsidedown

Is there any way to rotate a bunch of selected/marked cubes at once?
Or to delete a bunch of marked cubes?


Error: when deleting an object DLE-XP freezes.

Switch to blockmode, rotate the block. Or mark the block, copy it to disk, delete it (see the menu), paste the block back into the mine and change the current of the side you paste the block to until it has the desired orientation.

Well..I kinda figured that, but I'm talking about marking multiple blocks and rotating them; I copied them to a .BLK file, but still, I can't figure out how to delete them all at once. I could do this one at a time, but one of the blocks has a robot with custom attributes on it and when I attempt to delete it DLE-XP puts me on hold...

For DLE-XP, all marked segments, regardless of connected with each or not, constitute a block.

If successively marked several groups of segments, saved them to a blk file, unmarked, marked the next group, then you will have to delete each block one by one.

It's strange that you couldn't delete a block containing a custom robot. I just tried this and it worked. No freeze on object deletion either. (v1.5.1)

Yeah, basically multiple blocks in DMB2/DLE-XP is just one bigger block.

I can't see immediately how treating them separately would actually alter behaviour.

I openened a level I had made with v1.5.1 in v1.5.2, and it was corrupted. D2X-W32 loads it fine.

D3Hack wrote: [edit]A\Z key panning seems to work great now... except that Z seems to pan in, while A seems to pan out. No big deal, though.[/edit]

That is the default functionality since DMB2's original version. It simulates Descent flying. Remember what Descent's default binding for A and Z are? That's what DMB2 simulated, and what DLE-XP, until now (THANK YOU SO MUCH I CAN USE DLE-XP NOW AND NOT BASH MY HEAD AGAINST WALLS!!!) did not have.

I have tried multiple orientations for this teleport, yet still I find myself unsuccessful...I always appear the exact same way as the first time: upside-down at a slight angle....

It would be realy useful if a new feature was put in for setting an extra side to serve as the "ground"

D3Hack wrote:I openened a level I had made with v1.5.1 in v1.5.2, and it was corrupted. D2X-W32 loads it fine.

NM that problem; I fixed it by saving it as a regular D2 level, then reopening it in the latest DLE-XP and saving again, this time as a D2X-W32 level. Something must have been wrong w/ v1.5.1's level format, as the latest version of D2X-W32 didn't like it either...

Image wrote:I have tried multiple orientations for this teleport, yet still I find myself unsuccessful...I always appear the exact same way as the first time: upside-down at a slight angle....

I don't think that Diedel meant changing the teleporter's orientation, I think he meant changing the orientation of all the cubes that you are teleporting to.

That's what I did I said 'for this teleport' meaning I made the adjustments to see if the teleport would work right...o.0

Now the latest version of DLE-XP can't load Burp 2 Possibly due to filesize or cubecount?
Now I get an error message from D2X-W32 saying I have an invalid cube type or something and the number 255...

Warning! Segment 12 has invalid station type in 255 fulecen.c

Sorry Image,

I do not understand enough 3D math to change this behaviour of D2X-W32. Basically what it does is to use the normal of the target segment's target side to determine the ships orientation on arrival at the teleport's target.

Basically I don't know how to preserve the ship's roll angle.

Here's the code, maybe some 3D wiz can help me out with that:

• void teleport_set_orient (short objnum, short segnum, short sidenum)
  {
  vms_angvec an, ao, av;
  vms_vector n, vel;
  vms_matrix rm;
  object *objP = Objects + objnum;
  
  // copy side normals
  memcpy (&n, Segments [segnum].sides [sidenum].normals, sizeof (n));
  // turn the ship so that it is facing the destination side of the destination segment
  // invert the normal as it points into the segment
  n.x = -n.x;
  n.y = -n.y;
  n.z = -n.z;
  // compute angles from the normal
  vm_extract_angles_vector (&an, &n);
  // create new orientation matrix
  vm_angles_2_matrix (&objP->orient, &an);
  compute_segment_center (&objP->pos, Segments + segnum);
  // rotate the ships vel vector accordingly
  vm_extract_angles_vector (&av, &objP->mtype.phys_info.velocity);
  av.p -= an.p; // pitch angle (rotation around X axis)
  av.b -= an.b; // bank angle (rotation around Z axis)
  av.h -= an.h; // heading angle (rotation around Y axis)
  vm_angles_2_matrix (&rm, &av);
  vm_vec_rotate (&vel, &objP->mtype.phys_info.velocity, &rm);
  objP->mtype.phys_info.velocity = vel;
  }

Diedel, as far as I'm concerned, using that system you can't do it. You know what side the ship should point toward, but the only way to know which way is 'up' is to consider an edge to be the 'up' direction - but which one is it? Triggers don't save that kind of data.

The only way I can think of to get this kind of thing right is to handle teleports like secret level returns and use an object instead - which you CAN orient. Either that or to add extra information to the trigger system... which is probably not useful anywhere else.

Sirius,

every trigger is attached to a face and points to a face. That means that using the target side's normal, I have an orientation, including 'up' (angle zero).

What I want to have is to preserve the banking angle of the ship when it arrives at the destination, while changing pitch and heading to the direction the normal points to (or actually, the opposite direction, as the face normals point into the faces' segments).

Right... code is surprisingly easy to follow considering it involves 3D stuff...

Doesn't the normal vector just contain three (x/y/z) values though? While that does give you part of the story needed for the orientation, I suspect it misses some as well.

For instance, a normal vector pointing up would just be 0/1/0... but an orientation vector would have the pitch at 90 deg up (personally I don't know how they encode it, but probably +1), while bank and heading ... well, you can't really tell what that is from an xyz vector.

It seems to me there is an information tradeoff converting between the two; XYZ vectors store length, while orientation vectors store the banking detail... so you pretty much need two XYZ vectors to fix orientation, rather than just one.

Sometimes I think of it a bit like a skewer... if you poke a stick through the Pyro in the direction of the normal, you fix which way it's facing - but you can still spin the Pyro around on the skewer because the normal doesn't fix that part of the movement.

However, if you poke another one through at right angles, you can't turn it at all because you now have an exact orientation.

A bit weird, but it makes sense to me.

It's probably stuff you already know, though, since you've touched 3D and I haven't... But I still get the 'we need more information' feeling from this.

What you COULD do, of course, is derive a kind of 'default' which-way-is-up vector from the cube, by perhaps the difference between the standard 'top edge' and the centre of the face (only a suggestion, as that involves more than a few averages and there are probably more efficient ways to derive such a vector). If you did this for the source cube and the destination cube, then I guess you could figure out the banking value for the source and set it in the destination, relative to that 'up' vector... but it wouldn't give the level designer a very good idea what would happen unless they knew how orientation was determined.

I think the position vector and orientation matrix are the two references that determine aligment of the ship axis'.

I've been playing with the colored lights a bit and there is an issue that i didn't like too much.

For the colored lights, you can only select a fixed color from the actual 256 color palette of the level.
It could be possible in future vesions of DLE-XP, selection of light colors from a complete RGB or HSL palette, so you can pick whatever color you want?

Yeah, I have no idea how the orientation matrix works.

All I'm trying to say, I guess, is that on a theoretical level I would expect there is nowhere to get the information about bank from. Could be wrong, of course.

Bug:
I notice that in the latest version (don't know about other ones) the 7 and 9 keys on the editor tool bar work opposite to the 7 and 9 keyboard numpad keys.

Idea:
Is there a way to map the vertical and horizontal rotation to a middle/scroll button XY mouse movement?
I use a 3d cad package at work that has this to rotate 3d objects and I try to do it and end up finding the click-click-click for rotation quite frustrating.

found it!!! ctrl-shift-mouse

Sirius,

• with some ingenious math, the 3 angles of the 3 ship spatial axis' are mangled into the orientation matrix, but not simply an angle per matrix vector, hence I said 'mangled'.

Weyrman,

• thx for the hint. I will fix that.
  
  Edit: Fixed.

Pumo,

• I had thought of that myself, and actually light color is stored as RGB by DLE-XP, but I'd need to implement a way more sophisticated color control, that's somewhat of an obstacle. I dimly remember MFC eventually offering one, but I'd need to dig through the MFC doc depths to find it. Does anybody have some info about it at hand?

i am stepping way out of my level of knowledge here to comment and am probably asking a stupid question.

since the game saves your spatial orientation in a file shouldn't those save routines reveal how/what/where the data is stored?

please excuse me if this was a totally stupid thought.

I know how the data is stored, but I don't know to isolate/preserve a single orientation angle from it.

ah, the orientation values are merged together in someway and stored as one? it would be time consuming but could you change one value at a time to see what affects what? is that the code you posted above? i'm not looking to acquire knowledge of dle programming. sometimes a unsullied and uninformed opinion (i.e. kibitzer) can point someone in a different direction. the forest for the trees syndrome.

extract_angles_vector extracts the angles from a matrix, but I still did not manage to keep the ship's bank value ...

well i'm too deep now to stop. vectors are angles to a reference no?. the bank would be relative to the starting/up position of the mine. so i'm not sure it would be a vector. wouldn't it be a degree value?
1-360 or 0-359 or +/-(0-180)

A vector is simply a list of values here. Don't be confused by the name.

ok. i was really suggesting that the reference for the bank is different from the left/right up/down.

doesn't the pitch up/down use the up/start orientation of the mine as a reference also?

maybe there's a different function for those values?

obviously using a name that doesn't suggest what it does. hmm? the load game routine must use something to get the bank value.

The reference orientation is always 0 degrees for each angle. D2 simply stores/loads the position vector and orientation matrix of the player.

The lighting algo seems to be all screwed up in the latest version... it fills in darkness with full-bright light...

D3Hack wrote:The lighting algo seems to be all screwed up in the latest version... it fills in darkness with full-bright light...

This is a crap error message! I need details, not some the lighting is screwed up. It isn't, at least for me. So either you're precise or don't post.

Just a suggestion - if you see a bug in DLE-XP, test it in a different situation or with a different level and see if the same bug occurs. And it never hurts to send in the level along with an exact description of how to reproduce the bug...

Edit: jakee308 - the load game function just remembers your orientation and loads it. It's no big deal; the Descent engine has to keep track of what way you're looking to know what to render also.

The problem is when changing orientations, like what happens when you teleport from one place to another. Basically you need to take the left/right/up/down directions and alter them so they are the same respective to the cube you teleported into - which may be facing in a completely different direction.

Part of this can be preserved; the problem is figuring out which way is up from the data given and ensuring it's set properly.

ah, thanks Sirius. i was in over my head anyway.

Okay, one thing you COULD do I guess:

Add an extra object type that is completely invisible (considering teleport triggers are not supported in standard D2 anyway)... and allow that to be added through DLE-XP... then make the segment number in the trigger refer to its object number instead.

That way, when D2 encounters it, it can just copy its position and orientation straight to the player, without requiring all the drama of the cube/side system...

It also has the bonus of being able to control more easily which way you're looking if the cube has an odd shape.

Diedel wrote:

D3Hack wrote:The lighting algo seems to be all screwed up in the latest version... it fills in darkness with full-bright light...

This is a crap error message! I need details, not some the lighting is screwed up. It isn't, at least for me. So either you're precise or don't post.

OK, I'll go with the latter.
I made a D2X-W32 level in v1.5.4 (actually, I didn't make it in that version, I edited it in that version). The level has colored lights and partially transparent walls, and custom textures with colored lights attached to them. When I open it in v1.5.5, and do the lighting (I'm writing this as I go)...

Actually, nothing out of the ordinary happens. W. T. F.

OK, nm that prob... I guess reinstalling the thing did the trick... *insert really weird SciFi channel commercial here*
Next time, I'll try doing that first...

BTW, DLE-XP does still go to minimum zoom when I open a level...

dee dee dee dee,
dee dee dee dee,
dee dee dee dee,
dum dum dum dah