Jump to content
The Dark Mod Forums

HMart

Member
  • Content Count

    1074
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by HMart

  1. Is that really true? I've not used it in some time but I did used it before and it worked every single time in all games I tried it, could be a recent bug, personally stopped using it because I don't like how it blurs the scene a little and also affects the text in the GUI's of some games, makes them overly smooth. It also doesn't work in Dx12 and Vulkan games, but those are a minority. Btw I personally don't like FXAA either, why, because it also blurs the scene a little to my tastes, if I can't use MSAA or even SSAA I don't use AA at all, I prefer fluid motion, crisp images and don't mind aliasing, IMO isn't that bad at 1080p.
  2. You can also write a autoexec.cfg file, if it doesn't exist already that is and if TDM team didn't changed how config files are managed, don't have TDM at hand to see, then you can put all your preferred cvars in there. Btw no need to put there all the cvars, only the ones you want to change, if it works, it will safely override the ones in darkmod.cfg.
  3. The performance improvements are very impressive, you guys are doing a fantastic job but I most say that personally, I like the 2.03 version look the most, less shiny more brighter. Could it be the SSAO doing that, or the team changed how the ambient lighting works?
  4. Sorry I should have mentioned that i'm not using it on TDM. So I really don't know.
  5. Unfortunately idtech 4 GUI editor (made by the Quake 4 team Raven btw) is very bare bones, has a tendency to crash and corrupt GUI's, specially if it has complex scripting and you are not careful and save constantly, it also doesn't support any in editor scripting abilities and animations that still has to be done manually in a text editor. For those that care here are the cvars I use to make it work +set developer 1 +set r_fullscreen 0 +set r_multiSamples 0 +set r_mode 5 +disconnect +editguis There's also a material editor if you don't already know, but imo is far from being a very user friendly tool and for the most part personaly prefere to write them by hand.
  6. Hum the last time I tried to mod the game it only guarantied full support for collada 1.4.0, I used Modo 601 (the same I still use for idtech4 .lwo), it exports collada 1.4.1, it worked but not 100% the model exported/imported fine but all the extra stuff, like lights, and light options, like color and size and stuff, didn't worked correctly. Or perhaps Modo exports a invalid collada format? (I find that unlikely) Or HPL1 engine uses a particular format of collada that only the Maya plugging, Frictional games used, could export. I remember looking at original Penumbra collada 1.4.0 models in a text editor and the collada 1.4.1 exported from Modo 601 and saw obvious big diferences. Never tested blender because didn't used it at the time. To me is important that collada export/import work correctly, because afaik to use HPL1, 99.9% of the level work is done inside the 3D tool (Maya in their case), their "editor" is just a pre-viewer of sorts.
  7. Awesome work revelator, don't forget to post that in the Frictional Games forum if you have not already, thanks for making this, I really hope that having the ability to use a more modern collada version and so more modern tools, will help this engine get more use, IMO was one of the main stoppers. Unfortunately can't test right now, will do so during the weekend and give you some feedback. cheers.
  8. 1 - go to modify -> rotate and scale, is already at 45º increments. 2 - Are you talking about DR here? if yes changing keybindings in edit -> mouse bindings, doesn't help?
  9. stgatilov, unless you guys modified the input system has well, in normal idtech 4 there's also the ability to print (list) key bindings on the console, so obviously they can be made into a simple string. If this code gets updated has keybindings get changed ingame, I don't know but I assume it does. Here is the relevant code from KeyInput.cpp void Key_ListBinds_f( const idCmdArgs &args ) { int i; for ( i = 0; i < MAX_KEYS; i++ ) { if ( keys[i].binding.Length() ) { common->Printf( "%s \"%s\"\n", idKeyInput::KeyNumToString( i, false ), keys[i].binding.c_str() ); } } }
  10. First personally i'm not a fan of those situations where games override player commands, but that is me. About the question itself, afaik there's no way in script to simulate a button press, don't know what you are trying to do but couldn't you just push the player forward with a invisible brush? It will not "walk" but glide but at lest would move forward.
  11. No problem revelator, its nice to hear from you. Never worked with angelscript but from the code I've seen, it seems to follow C syntax, similar to Doom Script, that makes it very attractive to me. Not that I can help but what problems are you having with it?
  12. Holly shit that bump in performance is impressive! Good job!
  13. I've used vertex colors in some models before (not on TDM version of idtech 4) and never saw this behavior, idSoftware also used them for the Mars terrain peaces and afaik they look fine, but perhaps I just didn't looked carefully or this bug only happens on .ase models? All my models are in .lwo format. If this ends being a original idtech 4 bug then not even idsoftware artists were aware of it, but Doom 3 was rater dark so that could hide some bugs.
  14. The model topology in the flat parts imo is really not optimal, so perhaps is smoothing groups causing problems? If it was me I would cut (separate in blender I think) the model manually at the "hard edges", to see if that solves the problem, this if the exporter doesn't decide to "glue" the model again at export time, afaik exporters should do this cut automatically at export, when using smoothing groups or "hard edges" but perhaps is failing in this case? If that solves the problem then I would rework the topology. Btw what model is that for? Or is a secret?
  15. To solve that I would do a trace "tracePoint( vector start, vector end, float contents_mask, entity passEntity )" pseudo code vector start = playerOrigin; start_z += 10; // make the trace start some units above the floor vector end = enemySpawnPosition; end_z += 10; tracePoint (start, end, MASK_SOLID | CONTENTS_RENDERMODEL, self); // "self" is of course the player entity, you don't want to detect the player. if the trace detects a entity: // 10 units high or above entity ent = sys.getTraceEntity(); if( ent ) do nothing else, there's enough open space in front of you, spawn the enemy; Of course this doesn't take into account all corner cases, this can end very complicated, with more than one trace needed to really solve every case; Just see this to see how tracing can be very powerful but also complicated: http://blendogames.com/news/post/2013-01-02-qc-dev-001-ghost-cursor/ Edit: your idea of setting teleport's by hand is not bad at all and the script would be less complicated, but of course less dynamic.
  16. Hum in that case can't you just use the available AI script code? Unless the TDM team changed totally the Doom 3 AI code, the original AI had this script functions, see if they are available (and work...). .faceEnemy(); .faceEntity(); .canSee(); .TurnTo(); .TurnToPos(); .TurnToEntity(); .LookAt(); // For the heads .LookAtEnemy(); // for the heads And others. Here is the code for the Doom 3 sentry robot, where some of those are used, here just as a guide, I don't claim any of this works on TDM but no harm in trying I guess. /* ===================== char_sentry::state_Combat ===================== */ void char_sentry::state_Combat() { float attack_flags; eachFrame { faceEnemy(); lookAtEnemy( 1 ); if ( AI_ENEMY_DEAD || !getEnemy() ) { startSound( "snd_target_lost", SND_CHANNEL_VOICE, false ); AI_ENEMY_DEAD = false; clearEnemy(); setState( "state_Idle" ); } attack_flags = check_attacks(); if ( attack_flags ) { do_attack( attack_flags ); continue; } if ( canReachEnemy() ) { combat_chase(); } else if ( !find_attack_position() ) { ignore( getEnemy() ); checkForEnemy( false ); } waitFrame(); } } (edit): To make a entity spawn in front if the player, try something like this, change has needed to work on TDM: float someDistanceValue = 128.0; // Doom units tweek has needed vector playerOrigin = self.getOrigin(); // player needs to exist in the world already vector playerAngles = self.getAngles(); vector playerForwardVec = sys.angToForward(playerAngles); vector enemySpawnPosition = playerOrigin + (playerForwardVec * someDistanceValue); entity enemy = sys.spawn( "classname" ); enemy.setOrigin( enemySpawnPosition ); Not sure if the spawn code itself is correct at all.
  17. I didn't read all the discussion in detail, so sorry if this is totally not what you guys are discussing but if you guys are talking about knowing the direction the player is looking at, in relation to something else, then I do this: I get the forward vector of the player view angles, vector playerViewAngles = self.getViewAngles(); vector forwardVec = sys.angToForward(playerViewAngles); i do the same for the object then I do a dot product between the two vectors, the player forward vector and the object forward vector, I think whose vector is second is important, also both are normalized (they are length 1), if the dot product value is 1 player is looking in the same direction has the object, if is zero, player is looking in a perpendicular direction (90º left or right) if is -1, player is looking in opposite direction, one is looking forward the other backward. Again hope this is what you want.
  18. I always found it really stupid how violence is extremely downplayed in games and movies but erotism/sex (not talking about porn here) is considered totally off limits. I've seen a video recently where people, including James Cameron, were discussing, that the scene in Ridley Scott Alien, where Ripley is in underwear was over the top.
  19. Hey thanks for the deep explanation, I'm still learning this stuff, so is no surprise to me that I add some wrong or incomplete ideas but i'm glad I said it, because it made you correct me and that will just improve my knowledge.
  20. Even tho I do agree that TDM should go 64bits exclusively I most say this: Using 64bits software doesn't mean 32 bits goes away, why, first because it is neither old nor faulty, afaik is just a size of a memory address (an integer), and second because even tho idtech 4 is or was 32bits software, it still uses 8bits and 16bits wide data, and TDM 64bits still uses 8,16 and 32 bit wide data. Going 64bit, does make a game faster, just because the team has the option to use bigger memory address numbers and so, access more RAM, but this is only important if your game is memory starved. Other thing that 64bits gives is the option to have more precision on some CPU/GPU calculations, that does mean better looking effects but also mean heavier calculations and so slower calculations, talking in global terms, is that what you need for your game? Do you lose much by doing the 32bits calculations instead? This is what game/engine devs need to think about. Having the option to do more, also means you can be more wasteful about memory usage/optimization, the game can end bloated very fast and slower to many people using low end hardware.
  21. IMO that advantage will slowly erode in the next versions of game engines, for decades programmers, optimized their code to Intel architecture, for obvious reasons, Intel has more users and that fact is still giving it a advantage, plus next to slightly faster IPC (Instructions per clock) makes it faster in many games, not by much but faster. But now that AMD hardware is gaining more and more users, I believe that will change.
  22. Goddammit, sorry about that, I just read "Not if corporations have any say" and the rest went pass my head.
  23. I'm obviously not so optimist but I really hope you are right.
×
×
  • Create New...