motorsep

@NagaHuntress: Thanks a bunch - the fix works! The only issue, as you stated, it stuttering. I don't think it happens in FPS view (maybe I simply didn't notice as I didn't walk long enough on the edge), but it's very obvious in TPS view: (I used second method in the build I was testing). Hopefully you can figure this one out too I believe it was never an issue in Doom 3 simply because maps were smaller, and were mostly made of basic brushes - no slopes and such, just flat floors. I am thinking that since animations are played via script, the game still "thinks" player is on the ground and then momentarily in the air, and they again on the ground. So it switched anims crazy fast, and thus we see stuttering. I might be totally wrong, and even if I am not, I have no clue how to fix that.

@NagaHuntress: Sorry, was at work. Here is the test case: https://drive.google.com/open?id=0BwE6dxM0O2PsQUNncWw0aGFuZms This is a video of me getting stuck:

@NagaHuntress: I have a test case for collision issues (player gets stuck in the floor) in 64bit build (or 32bit compiled with /fp:strict). Would you care to give it a spin and potentially fix it ? (it was made for Doom 3, but I am sure it will run in TDM)

May I ask what's the benefit of having 64bit build ? Besides obvious issues you already mentioned, you will have collision issues on both Linux and Windows builds. Plus you'd have to port all tools to 64bit platform (Linux has not tools, so it's a bit easier to deal with).

I was thinking of having a check for the game type to be Quake 3 (in the .game file) but decided against it, since having "angles" in Doom 3 maps does no harm, and hopefully eventually Dark places engine (and maybe even ioquake3) and q3map2 compiler will support Doom 3's rotation matrix. Right now Quake 3 and engines that support Quake 3 maps/content (Darkplaces engine for example) only support "angles" for func_statics and "angle" for entities like info_player_start (rotation around Z axis as I recall).

Problem solved! (with help of one of the guys who works with me) In rotation.h in the following function : void write(Entity* entity, bool isModel = false) const add Vector3 euler = m_rotation.getMatrix4().getEulerAnglesXYZDegrees(); at the beginning of the function. Then comment out the same line inside if (!isModel) { and add std::string keyVal2 = std::to_string( euler[1] ) + ' ' + std::to_string( euler[2] ) + ' ' + std::to_string( euler[0] ); entity->setKeyValue( "angles", keyVal2 ); after entity->setKeyValue("rotation", keyVal); at the end of the function. Done! Full code: void write(Entity* entity, bool isModel = false) const { Vector3 euler = m_rotation.getMatrix4().getEulerAnglesXYZDegrees(); // greebo: Prevent the "angle" key from being used for models, they should always // have a rotation matrix written to their spawnargs. This should fix // the models hopping around after transforms if (!isModel) { //Vector3 euler = m_rotation.getMatrix4().getEulerAnglesXYZDegrees(); if (euler[0] == 0 && euler[1] == 0) { entity->setKeyValue("rotation", ""); write_angle(euler[2], entity); return; } // Non-z-rotations will fall through here } // The below call to reset the "angle" keyvalue will // trigger callbacks and reset this matrix. std::string keyVal = m_rotation.getRotationKeyValue(); entity->setKeyValue("angle", ""); // This call will usually update the m_rotation member again entity->setKeyValue("rotation", keyVal); // motorsep 08-05-2015; writing Quake 3 "angles" std::string keyVal2 = std::to_string( euler[1] ) + ' ' + std::to_string( euler[2] ) + ' ' + std::to_string( euler[0] ); entity->setKeyValue( "angles", keyVal2 ); // motorsep ends } P.S. I haven't worked with Git, so I don't really have time to mess with it to create pull request, sorry.

I managed to compile master with no errors, but it crashes on launch. Will try compiling 2.0.2 tomorrow and see if that runs. EDIT: Never mind, I managed to build master with MSVC2013 Community Edition (32bit for now).

Last time I tried to build DR 2.0.2 I managed to build it successfully. I'll try building master after work and see if it builds.

Aye, apparently you and greebo were the only two folks to work on DR :/ Can you please tell me if I am going in the right direction with the code ?

I think I found what's needed to get this working, but I don't know programming well enough to implement it :/ This would get us angles: vector3 eulerRad = getEulerAnglesXYZ(); And this would give us degrees for each axis: float angX = radians_to_degrees(eulerRad.x()) float angY = radians_to_degrees(eulerRad.y()) float angZ = radians_to_degrees(eulerRad.z()) And in Doom3Group.cpp, EclassModel.cpp and GenericEntity.cpp we need to add that stuff. And I think in rotation.h is where DR writes entity's rotation spawnarg (so "angles" would be added there, I think).

@OrbWeaver: DR has support for Quake 3 map format and it works wonderfully, except that Quake 3 doesn't support "rotation" matrix on entities. Instead it has "angles" "Y Z X" spawnarg. I am wondering if you can add conversion from Doom 3 "rotation" matrix into "angles" "Y Z X" when map is being saved into Quake 3 format. I am pretty positive DR converts angles into matrix, so angles should be naturally available. To avoid messing with back and forth conversion, I am thinking writing "angles" spawnarg should be done along with "rotation" spawnarg. This way there would be no need to update any code pertaining to displaying entities with correct angles nor converting "angles" into "rotation" when loading Quake 3 maps made in DR. There is no need to update "angles" spawnargs in real-time either. Simply set new values to "angles" spawnarg when saving of the map is happening. Could you please fix it? Thanks beforehand.

Yep, that worked!

Thanks, I'll try that after work

Since DR now supports Quake 3, I am trying to setup entityDefs for Quake 3 entities. Light entity in Quake 3 has different spawnargs than Doom 3, so instead of "light_radius" it has to be "radius" and instead of 3 components, it has to be only one (lights are spherical in Quake 3). So ideally, I'd still want to be able to see the box for light in DR, but have spawnarg to be "radius" "100" (for example) (I'd just keep box to be cubical in DR to have proper value reflecting the size of the light).

Well, I added "editor_radius" "300" to the entityDef, but it doesn't show up by default. I'd have to right click and add it. I assume the following will not show up by default either and I'd have to right click to add it: "radius" "300" "editor_radius" "radius" So do I need to do this: "editor_setKeyValue" "radius" in order to not have to right click to add it ? What about default value ?

I see. Probably modifying interaction shader is the only thing to do. I have been brainstorming lightmapping, and it's absolutely doable without any engine modification, if only shadows were cast on fullbright surfaces as if it was normal surfaces.

There is the following line in the game settings file: <property match="light_radius" category="Light" type="vector3" /> I assume when light is created, it gets "light_radius" spawnarg with "X Y Z" value. I need to change that, so that when light is created, it gets spawnarg "radius" and "X" value only. Following the example above, I am thinking it should be: <property match="radius" category="Light" type=???? />, although I wonder what type should I give it. Would that work? What type do I give it if I only need one value vs vector type ? Thanks!

Is it possible to have a fullbright material, which receives shadows as if it was standard material ? For example, if I add stage with blend add to a standard material, it becomes fullbright, but then any shadow that is cast on it looks so faint, as if it's not even there. Thanks.

When I make entityDef for a new entity, what do I need to do to have all spawnargs to be shown in the Entity Inspector ?

Why not? It's a large surface and I needed to scale up this baby to look in a way it doesn't hurt my eyes (the texture isn't tileable, so...)

I had this issue with 2.0.2 and with 2.0.3: I get this weird texture shimmering until I remove good chunk of decimals as depicted on the video (why is there so many numbers after decimal point anyway?). The texture is 4k x 4k. Another issue (which probably just a feature of DR) is that I can't use Surface Inspector to adjust values manually (not using arrows in the Inspector's window) when several brush faces are selected.

Looks like type="quake3" or type="quake4" does the job!

DR has several map formats to save to, Doom 3, Quake 3, Quake 4 and Prey. However, every time I change game type, default map format is always Doom 3. So I have to keep reminding myself to change map format every time I save the map. Is there a way to specify default map format to save to in the setting for each game? (for example, when Quake 4 is set to be current game, when Save dialog comes up, map format would be set to Quake 4; and so on) Thanks.

You don't need to go too far - get on Steam and get Doom 3 + RoE bundle for $12 (less when on sale).

BFG has no gui scripts. It uses SWF (Flash). Entire multiplayer stuff is tied to Steam and is ripped out of the source code release due to license.