Jump to content
The Dark Mod Forums

HMart

Member
  • Content Count

    915
  • Joined

  • Last visited

  • Days Won

    4

HMart last won the day on November 11 2015

HMart had the most liked content!

Community Reputation

222 Excellent

About HMart

  • Rank
    Advanced Member
  1. I'm with peter_spy on this and I assume John Carmack/id software also agrees, why, because the Doom 3 game and engine is full of warnings and even missing asset errors that do not cause a crash! Is totally normal during development to mess around with assets, materials, models, fonts, etc that never end being used and so get broken definitions to stick around, like i said, Doom 3 came with many broken/missing .mrt and .def files but the game worked just fine. When you are developing, specially in a multi-user environment you don't want your game and tools to constantly crash because someone else failed to delete a material file!? IMO crashes (asserts) and game-stop errors should be used for things that can potentially make harm to the user PC or cause serious visual problems in the game, all the rest should just be developer warnings that may or not be solved until shipping. And if you really want to cause crashes for everything during development then, use assert, those only trigger on Debug mode not release mode so there's no danger of the final release mode game crashing because of something that should be a simple warning.
  2. I most say that i'm not a TDM mission maker nor I even made that much scripts for TDM so I don't really know how they handle their weapon system, if it is similar to the Doom 3 way you could try this idea below. warning: This code is untested code, based on the way Doom 3 works and could be totally wrong for TDM, don't take it as a plug and play sort of thing, is just something for you to try, a direction of sorts. Btw if it throws any error at game startup post here and me and I hope others will try to help. I'm very busy so it could take some time for me to reply tho be patient. // in the player script file (if the TDM player script looks anything like the Doom 3 one...) object player : player_base { ... // Create a thread handle float discardthreadNumber; ... ... // create a new function // NOTE: notice the float data type, threads always return a float id number float DiscardWeapon(entity ent); }; void player::init() { ... discardthreadNumber = 0; // init the thread handle to zero ... } float player::DiscardWeapon(entity ent) { eachFrame{ // NOTE: a gui parm, is a variable in a entity gui (fullscreen or otherwise) that looks something like this, gui::parmName, // so, for this to work the player hud gui, most have a onNamedEvent or a windowDef // where a gui text cmd, is updated by a gui::message parm. // In Doom 3 idSoftware used gui::parm1, gui::parm2, etc but you can use any name you want. // BTW you cannot access any other script variable, using script or the engine c++ code but those, using // the gui:: naming convention, so no use trying to access a float defined inside a gui script, // those are only to be used by the gui code itself. self.setGuiParm("message", "Theres something wrong with this weapon!"); wait( 5 ); // clear message self.setGuiParm("message", ""); disableWeapon(); waitFor(ent); // kill the thread function if(ent.weaponHolstered()){ sys.terminate(discardthreadNumber); discardthreadNumber = 0; } } } void player::RaiseWeapon() { weapon = getWeaponEntity(); animState( ANIMCHANNEL_TORSO, "Torso_RaiseWeapon", 2 ); // Did not used weapon.getName() because that returns the entity name has defined in the editor // and not the weapon name has defined in the player def file, don't know if they match. string weaponName = getCurrentWeapon(); if(weaponName == "weapon_pistol"){ // start the thread function if(!discardthreadNumber){ discardthreadNumber = thread DiscardWeapon(weapon); } } }
  3. Btw i'm sure someone will use that Modding Kit to bring Dragons and magic into KCD ;D Can't wait for the Lord of the rings and Game of Thrones mods.
  4. Not exactly, Cryengine is not a brush based engine like idtech 4, is a full mesh based engine, you make your terrain in the editor using the editor tools to sculpt the terrain and then you import meshes made in Blender, Modo, Maya, etc into the level editor to populate your world but nothing prevents you from making brushes in DR, then export those as a obj, but you would need to UV map and texture them in the previous mentioned tools. Cryengine editor is a tool set suited to make huge open worlds. Is possible to make small indoors levels but they are not build exactly like with DR. peter_spy Cryengine has visportals (portals and anti-portals) they are mostly used for the indoor sections. p.s - Forgot to mention Cryengine editor has a entire set of tools to build and edit box primitives (designer tool), you can think of them has brushes but they are in reality triangle meshes and work exactly like those in Blender for example. You can then edit and construct full structures like buildings using those, this tools are mostly used to "white box" a level before the real objects get imported but I've seen people build complex structures with it that stay in the final game.
  5. TDM is open source and anyone can do with it what they want, I'm also no one to demand others to stop but I most ask, why would you want that? Just to spread the word on the game? Running a game in a browser, is very slow compared to running it natively on the PC and that is also slower than it can theoretically be that is why Vulkan and dx12 were invented. If the first contact people have with TDM is with the slowest version of the game, why do you guys think they would go then try the faster version? IMO they would just say the game is trash and forget it, first impressions are very important. TDM is already more demanding than Doom 3 ever was, they are two different games, not to mention that the engine version used in TDM has many changes and requires newer and updated GPU's, IMO Doom 3 is not and should not be a benchmark for what TDM should be capable off. Also Would the TDM team be fine with the game being known by many people has a browser game? We all know the stigma that those games have. Now again, if you want to try doing it, go for it, I bet it would be a fun exercise but I ask, what good would it make to the future improvements of the game/engine to have two different versions outhere? Who would maintain them? TDM team of volunteer coders is already small and even tho I don't speak for them, I bet they don't have much free time to work on something like this. Ultimately I certainly don't believe this would help people with slow computers (or slow internet), there's a reason you only see a few games running on browsers and none of them have the complexity or more complexity than Crysis for example, a 12 years old game. (google stadia will change this tho...)
  6. If the effect is subtle (that based in the video seems to be) imo it doesn't effect the identification of dark/light areas, personally I could very well see where was dark and where was not, this is like a person being in a dark spot and his eyes adjust to the darkness and imo that looks cool. I also think this would not affect gameplay at all, besides making it easier to see in the dark, imo is no different from people bringing gama up but at the same time seems to look better and to me is more realistic.
  7. Don't know if the TDM frob is based on a trace but if it is, you could try turning on (g_showCollisionModels 1) and make sure the collision box of the readeble is not inside the door collision box. You can do the same on the editor by displaying the collision proxies (green texture with collision text on it) and fix it there.
  8. Imo most be windows defender AI system flagging the exe has a virus, personally I don't use it, I use Avast instead and I have no such problem. See in the windows defender "vault" if it has any I don't know, if the exe is there restore it and make a exception. A relatively famous game developer, Casey Muratori, made a twitter some days ago about this same problem. https://twitter.com/cmuratori/status/1185242609737818113?s=20
  9. Personally I have a 3D screen and I don't play games that way for the most part, I don't even remember the last time I played a game using the 3D capability of my screen, but for VR I comprehend why people would want it. Btw idtech 3 (quake 3 engine) if i'm not mistaken has stereo capabilities perhaps someone with good knowledge of rendering code could see how it was done back then? Or even see how BFG does it? On my basic comprehension on how this stereo stuff works, it could be made by rendering two views (using two player cameras?!) with a small separation between them, then you just, interleave them for a 3D screen (like mine) or you color one view red and the other cyan for all screens, how that would be done on code is for a rendering programer to think about.
  10. I like it, it perhaps could be used to help optimization? I'm asking cause the outside view of a well lit room would be totally dark (at night) and so many things could be culled out of view (even if the visportal is open and things apparently should be visible to the player), the run time cost of doing the testing for visibility, would needed to be evaluated tho.
  11. You can also try renderDoc it has the benefit that it is GPU and OS agnostic. Handmade hero coder experience with renderDoc
  12. Oh yes i know that scene in Quake 4, is where they have the marine corpses going around on conveyor belts in meat hooks for stroggification! I was mistaken, is possible to attach a af to a animated object, In the script and specially in the c++ code you can bind a bone to anything (you can even animate bones with code). Btw the crane script in Doom 3 can give some clues on how to attach af objects to animated objects. This particular piece of the script code, does the binding, you can see bindConstraint mentioned there and also the keyword "fixed" this last one says that is a fixed bind, instead of "fixed" you also have "ballAndSocket" that is what the dragentity tool uses (permits the af to move around) and imo should be used for a hanged ragdoll. /* ============ crane_pickup close the claw and bind ============ */ void crane_cmd_pickup() { vector begin, end; string bindJoint, bindBody; if ( !( !bindEntity ) ) { return; } crane_have_object = false; bindJoint = bindBody = ""; sound_crane_fingers_close(); $crane.setFingerAngle( 20 ); sys.wait( 2.0f ); $crane.stopFingers(); begin = $crane_trace_start.getWorldOrigin(); end = $crane_trace_end.getWorldOrigin(); sys.trace( begin, end, '0 0 0', '0 0 0', MASK_SOLID|CONTENTS_RENDERMODEL, $crane_hang ); bindEntity = sys.getTraceEntity(); if ( !( !bindEntity ) && ( bindEntity != $world ) ) { bindJoint = sys.getTraceJoint(); if ( bindJoint ) { bindBody = sys.getTraceBody(); if ( bindBody ) { bindEntity.setKey( "bindConstraint bind1", "fixed " + bindBody + " " + bindJoint ); bindEntity.bindToJoint( $crane, "crane", 1 ); crane_have_object = true; } } else { bindEntity.bindToJoint( $crane, "crane", 1 ); crane_have_object = true; } } // automatically move up crane_move( $crane_hang, UP, crane_maxs_z - crane_pos_z, false ); if ( !crane_have_object ) { sound_crane_fingers_open(); $crane.setFingerAngle( -60 ); bindEntity = $null_entity; } else { $main_control_gui.setGuiParm ( "gui_parm1" , 1); } } Btw looking at the c++ code that manages this in the dragEntity tool, it seems "bindConstrain bind" are both required, only the number changes in the c++ code. so you need to say bind1, bind2, etc. key.Strip( "bindConstraint " ); if ( sscanf( key, "bind%d", &num ) ) { if ( num >= largestNum ) { largestNum = num + 1; } }
  13. I didn't know this was something you guys add problems with! The Doom 3 game and Grimm (also using idtech 4) have hanged ragdolls, Grimm even use them to good effect to make simple dynamic cloth. The Doom 3 one (hanged by one feet) can even move about like a pendulum. The trick like you found out is to bind the bone you want stuck to the world (with the AF editor). But your method VanishedOne, even tho works, unfortunately makes the character unrealistically stuck in the world by the head. Like you guys also found out, binding a ragdoll to another, doesn't not work (afaik) in idtech 4, it will just cause collision problems. If you guys want to have realistic hanged ragdolls , that can be moved about realistically, than the only way I know (apart from animation...), is to make the rope part of the character rig (in Blender), in that way the body and rope will just be one single skeleton/ragdoll. Btw when you drag a dead AI character around you are essentially making a "hanged" ragdoll.
×
×
  • Create New...