HMart

Personally I have a 165hz monitor and I set it to 120hz, why you may ask, because most old games can't go past 60fps without something breaking and most modern games that can run at above 60fps, are to heavy for my modest GPU to constantly run at 165fps or above, to take full advantage of the fast refresh rate. Plus imo is a waste of energy, 120hz is good enough for me.

I stand corrected but in my defense, you used the word character and the player is a character also.

Sorry if I assumed wrong, I thought you guys were talking about player animations. But even with NPC's imo there's problems opening doors realistically, seems such a basic thing to do but in reality is a very complex task, even AAA games where millions were spent didn't solved this.

I don't know how to solve that but perhaps this page may help. I do find it really funny thou. I love when that happens in games, other games have this feature, don't know if intentional or not, I remember particularly Severance Blade of Darkness (or edge of darkness in some countries) where higher ranking enemies would kill the lower ones if they hit them accidentally.

Yes that true but there's a reason even most AAA games don't use such door opening animations, even thou many people want them, they make the gameplay slow and they are very hard to make work right, first imagine you are on hurry, you want to open the door fast to escape a guard, but you need to wait for your character to finish its "door opening" animation before you can hide, I've experienced this in some games, that use such animations. Also even thou some may think is more realistic, IMO sometimes it is not, in a FPS game, it can sometimes disconnect the player from the character, specially when glitch's happen during the process, and they do happen, why, because of the way this type of thing needs to be made, it requires that the coders and animators, make sure the player is at the right angle and distance, to grab the door handle realistically, if not, it will fail, causing the player to be unable to open the door, or the player character will just grab the air and that imo, defeats the purpose of such system. This also demands the use of IK (inverse kinematics) like TDM characters use for the legs and we all know how twitchy it can be, not to talk that is some performance lost (ik is not free) for something imo not required and with some important cons. Not to talk that in the case of TDM, as a free game made by unpaid volunteers, don't expect everything to be animated.

No need to ask sorry you did nothing wrong.

Zerg Rush that reply looked like something a bot would post because of how off topic it seemed. And how the Eternium link, at a glance looked like a link to Ethereum the bit coin type virtual money. I almost reported you!

Fair but those images show what TDM is capable off in the right hands, even with the current assets and there are missions that have scenes like that or better, of course TDM missions are made by fans, everyone of them with different skill sets and so some may look less than that, but IMO even the "worse looking" TDM mission looks at lest comparable to Thief 3 not original thief.

Lets see: Thief 1/2 https://media.moddb.com/images/downloads/1/13/12812/dump026.jpg https://www.mobygames.com/images/shots/l/22894-thief-ii-the-metal-age-windows-screenshot-that-s-what-thief.jpg Dark Mod https://www.thedarkmod.com/wp-content/gallery/environments/thedarkmod-2018-05-25-23-38-03.jpg https://www.thedarkmod.com/wp-content/gallery/environments/thedarkmod-2018-05-26-00-20-43.jpg Yep the same....

It was already at 64bits. Tried 32bits just to see if it made any change, nothing, tried messing with gama and brightness no change to the color banding, tried changing anisotropy (was at 8x) no change, tried changing to the old backend, again nothing, enabling r_useNewFog makes a big change to the Snowed Inn skybox look but it still shows some color banding. Other things i tried, disabling sharping, bloom and SSAO, no obvious change to the skybox, I also enabled the new frob shader just to test it and I see banding on the highlight! edit: tried Snowed Inn in TDM 2.07 also see the color banding so is not a 2.09 bug.

Unfortunately I don't have a Navi based GPU only a older GCN one and that bug doesn't happen to me but I need to ask something, I played the mission Snowed Inn just now and, I seem to be getting very obvious color banding on the skybox, as if the skybox texture was 8bits do you get that has well? I tried the training mission and I don't see the same thing, perhaps is the fog?

IMO this was bound to happen, to me is a surprise how long it took for someone to push TDM in a direction it was not originally designed for, is a testament thou to the excellent work the TDM team made to make the tools relatively easy to use to create "thief" like missions. So is easy to understand that the more knowhow you guys gather the more limitations you guys strike against, so is not surprising that some of you want more than what is offered now, so yes for TDM power users, like grayman said "enhancing the scripting API" is a good idea, but like Geep said "minimize slowdowns inherent to scripting" should be taken seriously, making scripting easy is a blessing but is also a curse. IMO that is why Unity is still slower than Unreal in pretty much all complex games. C++ is hard but is fast. This *I hope* should open some eyes.

Please don't take this wrong but to me it seems you are confusing TDM engine with engines like Unity, that are a black box totally separate from the gameplay code and assets and you script your entire game, but idtech 4 is not like that. TDM when it was a mod used the SDK (source development kit) that idSoftware released for us fans, the SDK is the full c++ gameplay code, forget the script language is the real c++ code that linked the gameplay to the engine. Remember when I talked about a .dll? idtech 4 was separated in two components, the main engine .exe and the gameplay code .dll, moders add access to the c++ gameplay code (.dll) but not the main engine c++ code, now TDM has access to everything. (edit: TDM engine doesn't use a dll anymore is all on the main .exe now) Is like Source 2 for example they both have the same design philosophy and roots the quake engine. IMO expecting TDM engine to be like Unity will only bring frustration to you, if you really want to make a full total conversion for TDM you will have to fork the game and work on the c++ code, or work on the c++ and ask the main TDM devs if they can merge your changes. Or like you are doing, just accept the script limitations and try to workaround things.

Func_statics are meant to be static, meaning for walls and such, so that class lacks some necessary code to manage movement, if you want to move anything you should use a func_mover, a idDoor is a func_mover and I assume that is true for TDM doors has well.

That is theorically right but today CPU's are, way way faster and have better float support than at the time that first recommendation was made, so I don't think is so important anymore but I'm not a expert far from it. For example in the attachment bellow, is John Carmack saying he should use as default, 64bits types! He doesn't, because "old habits die hard", but if he says using such big types is fine then it most be, who I'm I to doubt him that man is a genius coder, I'm not...

Thank you Greebo for your hard work and this very useful improvements.

This also means anyone learning doomScript can more easily upgrade into C/C++ than anyone using PHP for example. There is major difference between static and dynamic typing. And "auto" keyword in C++ does not make it dynamically typed, so there is huge real difference with how javascript works. Oh I know that, I didn't mean that auto makes c++ a dynamically typed language! I just meant that from c++11 forward, you can use auto to automatically infer types now, but I know it only works in some cases, mostly when you give it a value or a hint at definition time, if not the compiler obviously cannot infer the type just from the function name. example: auto somevar; // Error at lest from c++11 and above. float somevar; // No Error auto somevar = 1.0f; // No error this is like saying, float somevar = 1.0f; I would say C++ is the "language of lifetime". You need a lifetime to master it enough to feel free using it. And the rest of your lifetime to catch up with new things piled upon the old things I guess only very scarce knowledge of C++ is helpful to deal with DoomScript. Basically, the C basic syntax, C preprocessor, C++ class/inheritance/virtual functions, and probably that's all. Then just practice and get generic programming skills, then look at doomscript examples and try to do something similar. And for God's sake don't ever read anything about "threads" in C++! You will be lost for scripting forever I couldn't agree more on this, you are exactly right.

I started in story mode from the beginning, first with (I think) normal difficulty died and died again, even before being able to go up to the plane, was trying to harm up the cave but didn't knew how, no matter how much wood I put on the ground, used matchs and such (didn't knew I add to use the special circle menu!), started again in easy, now knowing how to make fires, was able to go up to the plane after resting, just to die next to it, even with a camping fire setup and with the cold coat in the inventory and the character supposedly wearing it, for some reason the health went way down and the camera went crazy, gave up uninstalled the game. About bleeding out that shouldn't be it, because even thou I did die initially first of bleeding, the first thing I did was learn how to create bandages and stop the bleeding and rest, so the only other reason most be hypothermia and that happened even after I supposedly reached the plane and got the coat, gloves and such, I still died for some reason, I didn't cared to know why after that, this game is just not for me.

Personally I tried to like that game but was just impossible the survival aspects looked very interesting, I loved how you could pick wood, create fires and you add to make your own bandages, etc but to me the start of the game was atrocious, when a game kills you, again and again and again, in the first minutes of the gameplay, because the difficulty to stay alive, is high from the start, that is just bad design, is not fun, is just frustrating. And the way they make the camera move like a extremely drunk cartoon character, when the health is low, is really bad, is already hard to stay alive at that low health, without the camera moving around like crazy, health that btw goes low fast. Man that camera maybe the main cause for my opinion, it almost made me throw up, even turning the effect down in the menu didn't helped, because it still moved to much to me and made it next to impossible to try to survive near a fire, because the game decides to move the character, as if a tornado came and pushed the character away.

That's really cool Dragofer and Sotha, man I really need to play TDM more, I didn't even knew such characters existed in TDM.

Is certainly true that some people are afraid to learn new things, for a time I was one of them, my first foray into programing was with LUA that I liked (because of being a procedural/functional language), was so simple and direct that for a time, I didn't wanted to learn any other programming language, certainly not C++ because of all the bad rep it add, that I now know was mostly bs. But truth be told, C++ has some really stupid design decisions. Btw the best way to learn is to teach others and so I will be glad to help anyone with questions on c++ (I don't code in pure C++ so mostly C thou), within my own capaibilities/knowlege on the language and available time.

I certainly don't agree that only a small fraction of a C++ tutorial is relevant to TDM scripting, why, mostly because DoomScript is pretty much inspired on C/C++ and OOP (object oriented programming), the syntax may be a little different but the concepts are the same in many aspects. You can also manage memory directly in DoomScript (thou is less deep than c++ because of the lack of pointers), just like in c++, you have new and delete, so you can create and delete manually, data from the heap (PC RAM). Second is a static typed language just like C/C++, meaning when you define a variable you need to say what type it is. On JavaScript for example you just say "var whatever = whatever;" no need to say the type, it is inferred automatically by the value you give it, and now, you can do the same in c++ with the auto keyword. ex:. auto myVar = 1.0f. // this will be a float automatically. About classes, imo Objects in doomScript are classes, they are almost a one to one to c++ classes/structs but only with single inheritance, objects have constructors, destructors, methods (functions), virtual functions, internal (static) defined variables and you can put objects inside other objects, just like c++ classes. Printing in DoomScript is also very similar to c++ (and C). C++ cout << "some text: " << someIntvar << "some other text" endl; DoomScript sys.println("some text: " + somefloatvar + " some other text"); C printf("some text: %d some other text\n", someIntvar); The use of C like compiler macros like #define, #if #else and many other similarities.

I comprehend the desire to make everything with the script engine, I was in that position before but this was before I realized how slow DoomScript is, compared to C/C++, how hard it is to debug compared to C/C++ (there's only print debug available), even thou the later languages are "harder" than DoomScript just the fact that you have a debugger, imo make them way easier to work with. And as you are now realizing, how limited DoomScript is and was, for many things, so IMO it would be pretty much impossible (and imo crazy) for the TDM team, to decided to do almost the entire game using the script language, believe me, it would pretty much make the game unplayable for many people, specially for those that have a relatively slow PC but enough to play the game how it is code now. Btw I'm not against TDM team making more deep access available for script, is for them to decided if is worth the trouble.

Oh hell, sorry but forget about the dll, I was assuming TDM engine compilation was similar to original idtech4, but is not, for Doom3 the engine code was compiled into the .exe and the game code into a gamex86.dll, this separated the game, from the engine core and made it very easy to make your won mod and was how TDM was originally made, but on the conversion to standalone, it looks like the TDM team changed how the engine and game is compiled, now everything is compiled into the .exe, game code and all, there's no separate .dll anymore. This means, anyone modding TDM game source code, will need to essentially compile the entire engine and release their own custom executable, instead of just using the original one that comes with the game.

Yes that is right, those are the only buttons you can access, just like the original idtech 4. Yes is very limited but you need too realize that Doom3, was not made to be entirely changed/modded by script alone, you need to get your hands dirty into the c++ code (and IMO is not as hard as you may think). TDM made it way more easy to script more stuff but still, many important functionality is done in c++ and in many cases, is not easy to make it changeable by script, not to talk that DoomScript is way slower than c++. So even thou I don't know if this is the case for MirceaKitsune work, anyone wanting to change how TDM works, in a more deep way, should really think creating a full mod, one that requires its own .dll like d3xp did for Doom3. This does mean coding in c++ and compiling the code. Saying that, it is not hard to make impulses available to the script engine, just like .getButtons, gets the value of usercmd.buttons, TDM engine team can just define a script function returning the value of usercmd.impulse. Perhaps making a TDM feature request, in the bugtracker, will make the team more aware of this.