Jump to content
The Dark Mod Forums

motorsep

Member
  • Posts

    913
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by motorsep

  1. @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. :)

  2. 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).

  3. 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.

  4. 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).

  5. @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.

  6. 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).

  7. 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 ?

  8. 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!

  9. 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.

  10. 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.

×
×
  • Create New...