HMart

In this particular case they don't follow power of two rules, they just get a basic integer value automatically by c++, because is a enum like the first in the examples bellow: // this is the enum used in TDM source, is a C type unnamed enum and gets set to a int automatically. enum { value0, // this is 0 value1, // this is 1 value2, // this is 2 value3, // this is 3 ... // etc }; // this is a C type unnamed enum based on power of two unsigned int values (hex values) enum { value0, // this is automatically a 0 value1 = 0x1, value2 = 0x2, value3 = 0x4, value4 = 0x8, ... // etc };

I don't know how to say this any other way. That function gets the value of usercmd.buttons while impulses are normally handled by usercmd.impulse, they are two different variables, so you should never get impulses using .getButtons() (unless TDM team changed something that I'm failing to see in the source). About that particular impulse value, looking at TDM source code and counting by hand, _impulse51 == 76, so if you press the key binded to _impulse51 and .getButtons() returns 76 that means I'm wrong, you can access impulses in TDM, try it.

If is a impulse then is like the frob unfortunately. About if the player is frobbing a entity, looking at the code there's a script event defined for it. // ishtvan: Let scripts get the currently frobbed entity, and set "frob only used by" mode const idEventDef EV_Player_GetFrobbed("getFrobbed", EventArgs(), 'e', "Returns the currently frobhilighted entity. This includes entities the player has in his hands. Sets \"frob only used by\" mode"); void idPlayer::Event_GetFrobbed() const { idThread::ReturnEntity( m_FrobEntity.GetEntity() ); } doesn't "&player1.getFrobbed()" work?

I can only look at that and say, wow SSR for how fast it is compared to RT, is very realistic and to my eyes, others are free to disagree, is good enough. I certainly don't care if it reflects stuff outside the view or not, if they look "good enough" and are fast that is all what matters to me. But I stopped caring about graphics in 2009.

By USE key you mean the frob key? If so, why are you trying to know directly the state of the frob key? There's no other way to know if the player is frobbing something? What are you trying to do? But so you know, looking at TDM source, currently yes, you cannot get the frob key value using .getbuttons(), because is managed by a impulse, _impulse41. case IMPULSE_41: // TDM Use/Frob { // grayman #3746 - If a readable gui is currently displayed // we need to ask for it to be closed. if ( m_immobilization.GetInt("readable") ) { // Pass the "inventoryDropItem" event to the GUIs m_overlays.broadcastNamedEvent("inventoryDropItem"); } else { // Register the button for tracking m_ButtonStateTracker.StartTracking(impulse); // Perform the frob PerformFrob(); } } break; But TDM most have other ways in script to know if you are frobbing (using) or not a object is basic functionality?! If you really need to get the state of a key, then afaik this are the buttons that you can realistically check. You just need to bind a key to any of them. For example, bind "e" "_attack", then when you press key "e" it will set usercmd.buttons to UB_ATTACK and that can be retrieved by .getButtons() script function. { "_attack", UB_ATTACK }, { "_speed", UB_SPEED }, { "_zoom", UB_ZOOM }, { "_showScores", UB_SHOWSCORES }, { "_mlook", UB_MLOOK }, { "_button0", UB_BUTTON0 }, { "_button1", UB_BUTTON1 }, { "_button2", UB_BUTTON2 }, { "_button3", UB_BUTTON3 }, { "_button4", UB_BUTTON4 }, { "_button5", UB_BUTTON5 }, { "_button6", UB_BUTTON6 }, { "_button7", UB_BUTTON7 },

There's a link to the doom3 wiki on my reply above that has a example on how to use that function with Doomscript, with the Doom 3 game button functionality in mind but I think it can be converted to TDM very easily if you know how TDM buttons are set up. Btw again, unless TDM team changed things, you can't get the values of impulses from .getButtons(), it only returns the value of usercmd.buttons. Meaning that any key binded to a impulse is unfortunately off limits in DoomScript, in the case of original Doom 3 engine you only have access to seven buttons with that script function and apparently based on the link below because of a engine bug the button seven, didn't even worked well, don't know if still true in TDM. http://web.archive.org/web/20050404051342/http://www.planetdoom.com/d3cc/tut02.html Not really useful for scripting but if you are curious, you can look at TDM c++ source code, I assume inside UsercmdGen.h to know what value each impulse or buttons is set too.

IMO the com_showFPS display is buggy, it is not clearing the old displayed values, so it was overlapping the fps numbers very fast, was almost impossible to see clearly a single value during the game, but I could see more or less that it was showing values between 50 and 68 fps. The screenshot bellow shows a single value thou, but I'm not sure I believe those fps numbers, even thou it shows 61 and 58 the game felt very smooth in both versions to me! Even with freesync disabled, I saw no screen tearing, perhaps because I have the screen set to 120hz. https://drive.google.com/file/d/10dAOzYynkH2aor-2pVNcygzRgPDQl6nR/view?usp=sharing Btw was the savegame required for what you wanted? I asked because this is me starting the mission, taking the shot, quitting the game, disabling freesync and starting the mission again from the start, so no savegame was used.

The engine doesn't call key presses only impulses, impulses are just a kind of key presses, in this case a key that you press and it does its work only once, even if you keep the button pressed, in the other end the engine also has the concept of buttons, this is a key that you press and it does it work, over and over again while you keep the button pressed. Like always I can only suggest stuff I use on original idtech4 not TDM engine, so with that out the door, to get player key presses you have this: .getButtons(); this code bellow should also exist in the tdm_util.script /* Waits for the user to press a button */ void waitForButtonPress() { float buttons; do { buttons = $player1.getButtons(); sys.wait( 0.01 ); } while( !buttons ); } Afaik original idtech 4 has no way to get impulses directly by script only buttons. Don't know if TDM team changed that. I also remember in the doom 3 forum days, talk about a way to do custom player key presses using some console cvar or console command but I don't recall how right now. Will update when I do.

Make a DR feature request tracker entry, in the DR (not TDM) bug tracker https://bugs.thedarkmod.com is the best option to make sure greebo sees the idea.

Was able to play for a few minutes today using the default console cvars, no messing on the console for now, apart from a initial very bright gamma that I add to bring down, everything seems to work as expected. I also enabled everything on the advanced settings to their max settings, to me the game feels extremely fast and snappy, is just fantastic what you guys did to the engine. Btw played a few minutes of the Volta 2 mission because I think it looks awesome and would be a good test. My PC: Screen: 165hz 1080p freesync monitor (but set by me at max 120hz 1080p) Windows 10 x64 AMD RX 570X OC 8GB latest drivers AMD Ryzen 7 1800X 8c/16t 16GB of RAM

Here is a better video with r_tris you can clearly see that at the center of the room, even thou behind walls, other models/entities tris show up with r_tris 2 on, while the other peace in the void do not, two when clipping the wall the other "room" tris show up and while in clear view of the camera, it totally vanishes from view, including the tris visualization when I backup into the room. I don't know how else to read this but the engine culling it. https://drive.google.com/file/d/18yd3014cnRGnF4bF9DbR1ynLNZjObxLv/view?usp=sharing

I will try to make a video with the r_showTris 2 but the room is not flickering, is just hiding and showing as I move slightly forward and back while clipping with a wall.

Afaik you don't need to edit the original player script inside the .pk4, you can just make a copy of it change what you want (minus the file name obviously) and put it inside your own script folder, the engine will override the main TDM with yours. You can also create global script functions like those inside the tdm_util.script file. edit: see the tdm_custum_scripts.script file it has important info on how to make your own custom scripts

Sorry if I'm being stubborn but have you seen my video and what I show at the end? I ask because to me that is not what's happening, by "view frustum" i assume you mean the camera view, the rectangle that make up the game window, so based on that article, you should be entirely right no doubt and while those parts are in view, they should render, even if behind a "wall" but that is not what I see and I hope you guys too , the other parts of the single model/visleaf, are still obviously inside the view of the camera, but get hidden/stop rendering when I move, again I assume, the player origin from the void into the closed room. Also I don't know if this matters to the discussion but I have no problem transporting the player between the different "rooms", physics, lighting and sound, seems to work correctly, have not tested AI because right now, I don't have a working AI model, so perhaps the thing that fails is AAS. Btw in Doom 3 when the player first gets transported from Mars to hell, using the transporter, is that really loading a different level? I remember that organic tunnel effect during the transport but I don't remember the game going into a loading screen that it normally does, when changing levels, but truth be told I don't play Doom 3 for ages.

In that case you have to code them yourself, like those inside the player object script, if the necessary peace's of information, is available to the script code, that I don't know if it is.

I assume this is exclusive for TDM engine because of that game console cvar. Petty, I don't use TDM engine but would certainly love this feature.

Not wanting to start a GPU debate here but at lest for my usage, I've no complaint about AMD OpenGL support, all OpenGL games I have (that truth be told are a minority) run well enough. But I totally comprehend that for Linux users and those pushing the idtech 4 engine like the TDM team having "sufficient" OpenGL support is not a good thing.

First I still see that you use "self" has a simple variable name, not sure if wise. For comparation, in c++ using "this" (self is like c++ this) as a normal variable name, is totally forbidden and will give you a compile error. From the doom 3 wiki. Second have you tried to search the tdm_events.script to see the available script functions? Don't know if all player script functions are defined on there thou.

Ok thanks for the confirmation, I forgot that most of the AMD features only work on D3D and Vulkan now.

I'm certainly not a expert in idtech4 rendering engine, so you may be right, perhaps my misconception came from my past work with the C4 engine, in that engine, portals were gateways into other areas, so much so that, contrary to idtech4, in C4 you add to make two portals to connect visually two areas, I think HPL engine does the same. This part at lest seem to be true, like you see on the video at the end. So even if all unconnected rooms are a single model the engine somehow knows to only hide the parts of the model outside the view, that seems to be a perfect behavior for my idea but like you implied, I don't know how this affects, the AI, AAS or sound flooding, perhaps if I make the rooms to near each other sounds could leak into the visible part, need to test this. But all of this is just a curiosity, I don't know if I will use this door system. I read this on the link nbohr1more posted Seems to say exactly what OrbWeaver said but at the end, it talks about the opaque nodes. And if the entire map is send to the GPU to render, then why Is the other parts of it not rendered when not in view? Imo seems to be a contradiction.

Yes, is indeed inspired by Resident Evil, so much so that I called this door entities idREdoors I have Velvet Assassin, bought it on a sale ages ago and even thou like you said, is broken in some things and is clearly a small indie game, it also grew on me. Petty the developers add to close shop they add potencial.

Good question, I really don't know if AMD enables that by default but I also don't think it does, It most have been me that enable it, I comprehend and agree, so no more on this from me.

Is that without no visportals in the level? If so that tells me that the engine, default is to automatically cull everything outside the current "room" or visleaf? the player origin is in and needs visportals, so the player can see into other rooms but if you have no visportals and the rooms are not connected then it doesn't care to show the other geometry, unless the player origin is in the void, then it renders everything. If this is true then the engine can indeed support the kind of unconnected rooms i'm thinking about. I will do a video showing what I'm saying but don't expect something pretty, far from it, is all programmer art the "level design", texturing, lighting, etc, for now is very very basic, just test rooms to test my c++ coding. And you peter_spy will recognize the door models no doubt, btw none of the models in the video are to be released for the public and are just place holders. Also sorry for the very dark look at the end, is a huge testing "room" just with a ambient light, on my monitor, ingame it looks reasonable but on the video looks very dark and I didn't care to edit the video. what I want to show imo is very apparent. https://drive.google.com/file/d/1KIgExPcmeVg14nGFnwa-YDwaO_8ZCPHu/view?usp=sharing

Ho I know that cabalistic and that was not my intention, what I was saying is if the feature should be on by default or really something players enable by themselves, but I do realize a sample of one, is hardly a incentive to change that. But thinking about it, just a warning for AMD users or a small hint in the menu, next to the slider, could be a nice reminder for them to disable one or the other and perhaps prevent some complaints. If this is really a problem, I'm not sure, still didn't had time to test this.

That cvar is what I've used to test this but I was not sure, if it was showing if the geometry was really being culled or not. I could be mistaken but it seems the engine does care, if you are inside a closed "room" or not, why? Because if you noclip and position your self next to a wall, in a way that the camera is clipping the wall and showing the other room somewhere in the void, if you move a little into the room, but still able to keep seeing the other room, there will be a point, where it will vanish, even if the camera is still clipping the wall and should be seeing it, to me seems it happens when the player origin falls entirely inside the room.