HMart

Agree and one thing that would be also nice to have would be drag&drop ability, but i'm afraid that will require extensive changes in the c++ gui code.

That to me at least is not new news. they have announced that were working in two games, after they released Soma and that was years ago, so by now they must be almost finishing their new games. What they are, I don't know but I would assume that one, is a new horror game and the other, is something totally new, why, because I know they are intelligent people and they certainly know that making the same type of games, will not make their company evolve, so making two games could give them the opportunity to diversify. But I could be totally wrong and both are totally new genres or both are horror games, let's wait and see.

Don't know if I did it correctly (or in the right place) but like you suggested i made a feature proposal in the bugtracker for this.

In Doom 3 idSoftware used c++ for the most part to include values into gui text strings, using the va("sometext_%i", someIntvalue) function so they never bother to include a idScript equivalent, but I think you can use this: windowDef Desktop { rect 0 ,0 ,640 ,480 nocursor 1 visible 1 // runs every frame!! onEvent{ if("gui::someValue" == 1 ){ set "valueWindow::text" "1" ; } if("gui::someValue" == 2 ){ set "valueWindow::text" "2" ; } ... } windowDef valueWindow{ rect 288,240,32,32 text "0" } } Then on script use the entity.setGuiFloat( "someValue" , 2) Hope this helps. Yes I know about the sys.println (in reality i use c++ with gameLocal.Printf("your text %i", value)) and I used it all the time, but it does have the nasty habit of spamming the console with messages, specially when you print runs inside a loop and imo is very distracting, seeing the constant flow of text, where's the onscreen gui method i implemented by that tut, is fixed and it also supports coloring the text like the console text, is really a case of preference, is not really necessary to implement but now that I did, i use it for some player debug info.

That logic does look fine to me. About the other question, there's ages that I have used idScript and specially TDM version of it, so i can't tell you what script function you would use to print values to the gui it self in TDM, in fhdoom I use the message system (is just a windowdef with a text "gui::message") of the player HUD to show text tips on screen and just use: hud->SetStateString("message", examine_message.c_str()); hud->HandleNamedEvent("Message"); To show values in real time on the player screen (development/ debug purposes) I changed the c++ code by using this tutorial, don't know if that was really necessary but it works for me. http://web.archive.org/web/20050828101016/http://www.planetdoom.com:80/d3cc/tut04.html

This does bring to light that TDM engine needs a way to detect the principal GPU better in laptops, based on my search it seems you just use this exports in the engine for that. extern "c" { __declspec(dllexport) DWORD NvOptimusEnablement = 0x01; __declspec(dllexport) DWORD AmdPowerXpressRequestHighPerformance = 0x01; }

IMO the loss of SteveL in particular and other 4 team members was a big blow to the mod and Bikerdude had some effect on that, so not everything he did was right, but perhaps those that went away only used him has a excuse, perhaps they were already tired of working on the game and biker behavior was just the trigger they needed to go away, lets see if some of them will return after the ban. About the ban itself I don't think it was a overreaction, it came after complaints of plagiarism and Bikerdude changing portions of missions without permission, in at least a case he claimed permission was given only to be dismissed by the author, situations that lead to heated discussions, talks about rules of conduct, how to handle reuse of assets, etc and many warning towards him, according to Springheel, Biker even asked to be banned in some occasions, even made a thread saying that he was going away, because of discomfort he was causing so he was aware things were not fine, only after that and a generous amount of patience from the rest of the TDM team did he got banned, so imo this didn't came out of the blue and was not a knee jerk reaction.

I'm sad that BD add to go but based on the evidence I saw I can't really blame the admins for doing it, I just hope he returns one day, knowing that he did wrong and with true conviction that he will not do the same errors again, if not I can only give thanks for the good work he did the nice missions he helped make and for having some help in making TDM what it is today, almost from the beginning if not from the beginning. About the community breaking after this, that will only happen if the ones that stay let that happen, there's others equally talent mission makers still around and new ones starting, they deserve a stable community don't let this drama get to you, my 2 cents.

Petty it came to that but I comprehend why it add to be done.

Awesome work on the tutorial man thanks for doing it. Btw you can do that dilation effect on Photoshop using the action available on this link

Yes Idtech 4 scripting is very easy after you know the basic concepts, like I said above I started with scripting before going into C and then C++ and it helped me a tonne. For those that don't know it, here is a good place to learn some of the basics on idtech 4 scripting: language syntax scripting basics know that idscript is based on OOP (Object Oriented Programing) so learning the basics of that will also help immensely.

I'm still in 2018 for more 3 hours but happy new year! for those that are already in 2019.

Ok i stand corrected.

That is because the gui dot, is really not being drown where the trace makes contact but is drawn at the center of the screen and in some circumstances the trace contact, is really not where the screen center is, afaik that is because the trace is a 3D trace where's the gui dot is a 2D concept. Personally I don't know how this could be solved, unless the gui dot is made to follow where the trace hits like when you use showtrace in the console.

Not very nice for a first post...also what makes you so sure the missions and its makers are to blame here, when me and others don't experience what you are experiencing? Don't you think that if all the missions were so broken, as you seem to claim they are, that this forum would be filled with users complaining? Do you think is fair to come here and accuse mission makers of being incompetent and not beta testing their missions and not help by telling what version of TDM are you playing with, if you are using the unofficial TDM gameplay mod or not or even tell us info about your PC to see if that what's causing the problems? Btw when someone for some reason get stuck in some geometry, there's no need to reload a save, just bring the game console down (control+alt+key above tab) write noclip 1 and press enter, this disables player physics and makes you able to fly through walls and everything, fly a little above the floor, bring the console down again, press the ARROW UP/DOWN key on your keyboard to navigate the console history, find noclip 1 (or write it again) and change it to noclip 0, this will make you fall unto the floor (so don't fly to high) and you can continue playing, Don't use this cmd to cheat the mission and go through closed doors, it will certainly make you fail to trigger events and cause the mission to totally bug out. BTW i'm not from the TDM team so my opinion or comments are my own.

Don't know about your question about the key, i've not worked that much with the physics engine for the time being, but the physics engine source code is totally open, so you are free to make it work better, you can also take it out completely and change it for something like Newton or PhysX but that perhaps would require much more work.

Fantastic work guys, thanks for the continued work on this awesome game. Decided to nuke my TDM folder and start fresh for this, works great for the most part, only add time to play mission 1: A New Job , only saw two minor problems, in the inn, the cloth of the rich beds had no alpha but it seemed they should, also add crazy LOD popping in this mission, saw it when on the roof looking to the two guards in the street bellow, don't remember ever experiencing that before and at a distance that imo is too short, increased LOD to "better" and it was solved but imo shows LOD is very aggressive in normal option. Played at 1080p with no AA, very nice performance, played with shadow maps on, saw no obvious problems at least in this mission. Btw add to manually enable r_useFBO.

That looks like a naming conflict, is that a map script or a object script? If is a map script did you put your code inside a namespace, to make it unique? If is a object script you need to use define guards to prevent conflicts. namespace mapname { map code } #ifndef __SOMESCRIP__ #define __SOMESCRIP__ object code here #endif //__SOMESCRIP__ hope this helps.

Don't know if this helps but is that ambient cube something like Valve talks here? https://steamcdn-a.akamaihd.net/apps/valve/2006/SIGGRAPH06_Course_ShadingInValvesSourceEngine.pdf

Don't know if is just the mess of modifications i have for TDM, but while playing "rightful property" was unable to use water arrows to turn of the torches, also add the aas out of date error again. I'm playing with the latest 2.07 alpha update 17 and the unificial TDM patch 1.1. Outside of that game was smooth tho.

My thoughts about this is that, even tho is a free game, where the original intention was to make a open tool set for people to make missions, and even tho everyone's map file, is open to everyone to mess with, this kind of practice shouldn't not be condoned, and basic guidelines should be followed, by everyone, no matter how respected within the community you are. This would be my personal guidelines: No copy/pasting of other people sections with minimal change, if you do so ask permission, if permission is giving, still try to change it enough that no big similarities can be discerned, this is so gamers don't feel they are playing the same mission all over again. If you do it without permission (if you are a ass and imo a criminal) at least have the decency to change it enough, so the original author doesn't know, ignorance in this case is bliss, is best to be oblivious then to feel robbed and stop making missions because someone else lacks creativity. Without express permission from the autor, no rework/change, big or small, of other people missions, at least for public release. Even tho they don't own TDM assets, the author spent a large amount of time arranging them on that particular way, and for them that ends felling like their "baby", no matter your opinion that should be respected period. If this means that in the case the author is unreachable, some old mission will stop working, because a TDM engine update needs missions to be reworked, so be it, remove it from the list and wait for the author to complain, small inconvenience to save from dramas like this one.

Just a update on my case, VanishedOne you were right the burn away effect was handled by the script code. On c++ was only the case of using SetShaderParm(parm7, gameLocal.time * 0.001 ); It should have been obvious but I didn't saw it, gameLocal.time changes each frame, i was using a fixed value expecting the material keyword "time" to do the rest but it didn't. Btw the * 0.001 is there to convert milliseconds to seconds, the engine Macro MS2SEC() does the same. This tho don't explain how to get the alphaTest value from the material using other than GetShaderParm...more study for me.

To me that part was ~50fps with single pass on a AMD Ryzen 1800X CPU, didn't tried with single pass off but i assume would be 6 fps or so faster. Btw a got a warning about aas96 or something being out of date when starting that mission.

I'm not sure but is not that expected? Afaik shadow maps are more GPU heavy by design they are just textures after all.