Obsttorte

https://wiki.thedarkmod.com/index.php?title=Objectives

@RedNoodles You can define custom stims and let the ai react to it by either adding a response to all ai's in your mission or by altering the scriptobject used by the ai, where you have to add a response in the init routine and define a script function with the respective actions to take place upon stim. Here you can find a similar setup: Here torch entities are stimming ai's to inform them they are there, and ai react if they are searching, but the basic functionality is similar to what you are aiming for.

The error message basically tells you what's going on. In line 90 of your script whatever is standing in front of the '.' cannot be interpreted by the scripting engine. So either the naming is wrong or something else got messed up during your renaming journey. Note that the setup was intented as a proof of concept only, not as a fundament to build upon and that it's been ages when I hacked it together. I cannot remember any single step of what I've done back then.

I know. I was refering to Geeps proposal for using it in a custom gui. That case is already covered by the code. The reason getGuiFloat returns zero is that you are probably using it wrong. The first argument is the gui handle of your gui. I am also not sure whether the second argument is "gui::lightgem_val", it could also be just "lightgem_val". As stated earlier it is GUI_HUD (corresponding to the integer 1 iirc, but you can use GUI_HUD). It is predefined and very unlikely to change.

The value of the lightgem is passed to the gui via the code. There is not much to improve here. And for general scripting it might be a bit faster, but the effort seems comparable high imho. When HMart mentioned the differences in speed between script and hardcode I guess he didn't wanted to neglect the useage of scripts, but only stressed that common stuff should be and is hardcoded (in difference to what Mircea was expecting). That doesn't imply that you have to optimize every corner of a simple script function here and there. And yes, reading out a value via script every frame may not be the fastest approach, but the overall effort is neglectable compared to the other stuff going on each frame. I was told performance might be an issue with some of my scripts in the past were stuff is checked per frame, but it never was. So unless you are going to perform thousands of calls per frame I highly doubt one has to care much about that aspect.

@GeepYou don't need to understand how the whole engine works to implement a rudimental script event. Of course if the information required are of a more complex nature the setup can become more complex. However, my approach has always been to ignore everything I assume is not important to me, and thus far it worked pretty well (well, mostly ). In addition I may add that I never said that one should not ask for help, I only stated that one cannot expect that any request will be fulfilled. This may not be important if there is no hurry in adding a new feature, but as far as I understand it Mircea is searching for a solution to something he is currently working on, so I don't expect him to be willing to wait a few years hoping someone may come up with the desired script. Trying to implement it oneself or searching for a workaround seems more feasable imho. In regards to your approach, there is no need to pass the lightgem value to the script first if it is intented to end up in a gui anyways, as the value is passed to the gui system by default. But if a script event gets implemented it will surely just return the currently stored value (calculated this frame). Hook functions as you described it are not part of the script system, and the code would need to check whether the value has changed every frame anyway, so there is not much gained by that.

In general one should not expect others to implement script functions for them unless those appear extremely useful or some of the coders is really bored (that is rarely the case, as there is still a bit of a lack in that regards). On the other side script funtions are normally quiet rudimental, so implementing them isn't too hard once you understood how the whole setup works. In most cases you can copy what is already there and alter it to fit your needs. Furthermore trying to find a workaround within the limitations of the current systems also has its benefits, as one can learn quiet a lot about scripting and other systems as well as the engine in general. Informations that can only prove useful on the long hand (there is a reason I have turned into a jack of all trades over the years - I am always looking for workarounds ). @MirceaKitsune: Even though there are no script events implemented exactly for your needs, there are workarounds. Reading the lightgem value via the gui is, as stated earlier on, possible. It's not the most direct way but, hey, it works. Modifying the breath is what the breath potion is doing, and yeah, iirc it utilizes the heal function (which is not obscure imho, regenerating health or breath is almost the same, so it makes sense both can be achieved via the same function) Disallowing players to run can be achieved via immobilization (think of player carrying bodies). Crouch would need more investigation, but it may be possible to utilize the animation system for that (if there is no immoblization for that either) Changing the player/ai footsteps volume is probably achievable via modifying the specific sound shaders combined with altering the ai's sensivity to propagated sounds. I thought about that in the past (player is harder to hear in loud environments), but never really implemented it. It appears to me that you are a bit too focused on the script events, expecting that there is one for every single (often very specific task). Try to think more outside of the box. There are guis, materials, shaders,objective system and Stim/Response to your disposal (and maybe something I have forgotten), and all of them can interact with each other.

AI isn't handled mainly through scripts either. The script mainly handles the way anims are played (allowing to tweak stuff without source code changes). Similar to that it handles some weapon and tool functionalities to allow easy tweaking. Everything more complex is handled by the code. Why do you think so? In Doom3 I suspect scripts were mainly used for setups (scripted sequences where monsters break through walls for example) that would be to nasty and error-prone to be setup via triggers but are not worth the effort to be hard-coded (for example because they are unique). And for stuff that might need continuos tweaking (not only in some basic values that could be handled via spawnargs but in the actual behaviour). The player code contains over 12,000 lines of script, ai is cluttered over several dozens of files of which the main one contains almost 14,000 lines (some of which are comments, though). And those files normally only contain the stuff special to the player/ai. Common code can be found in other files. Do you really want to put all of this into (slow and restricted) scripts?! That wouldn't work. It is actually quiet the opposite. Everything is handled via the source code, and only those things will go through scripts, guis or whatever that are intented to go through them.

The lightgem Value is directly passed to the gui. It needs to be computed in the source code anyway so why should the implementation be to take the detour via scripting. And besides the lightgem this value hasn't been needed for anything else, hence nobody ever cared to implement a script function for that purpose. (Note that only some specific aspects of the game mechanics are implemented via scripting, mainly because in the beginning of TDM there was no access to all parts of the source code.) The gui handle is an integer that is used to be able to refer to a specific gui. For the lightgem it is some one-digit number iirc. You should be able to find the correct one via testing. But as the lightgem belongs to the hud gui it is probably 1 (aka GUI_HUD, see tdm_defs.script). Once you have the correct handle to the gui you can read out the gui variable from there.

There is no script function to directly read out the lightgem value. But said value is passed to the lightgem hud gui, so you can read it out from there. You first need to get the handle to the corresponding gui and than you can retrieve the value via getGuiFloat(). The name of the gui variable can be found in the lightgem hud gui file. I fiddled with this stuff years ago so there is a chance you may find somehting useful in my mapping thread. Not sure, though.

"def_projectile" does not refer to the ai's ranged skill but refers to the definition of the entity to use as ranged ammo.

Note that "A New Job" iirc uses a modification of my "player looks at something script" that does more or less what you seem to be aiming for. In regards to traces I wouldn't bother too much as long as you only perform one trace per frame. The game also needs to check whether something frobable is in front of the player and it doesn't cause much issues either.

You could try reducing the scanFov spawnarg on the respective camera. If that doesn't work, you may be able to manipulate the look of the view by using only a part of the texture.

Just so I understand you correctly. You aim to create a mod that will automatically turn current (and future) FM's into cyberpunk missions?! And you expect everything to work out in regards to gameplay?! That's probably not going to work. I always assumed that you either want to create your own missions or provide a fundament for others to create missions on. In that case the placement of items would obviously be up to the mapper and your problem is solved.

angToForward should already give you the desired vector, only normed (so of length one). So pos_end should be calculated like this: pos_end = pos_start + 1000.0*ang_fwd;

The actions executed by the spyglass and readables are fixed and specified in the guis used their. I am not a houndret percent sure how it behaves with object manipulation, that might be hard-coded. If there are three things you would like to have reverted (spyglass, objects and readables) and only one where not (inventory) I would suggest trying to flip the respectives keys in the settings for the time beeing. Making these settings customizable would require at least changes in the guis for the main menu as well as the spyglass and readables and maybe additions to the code to at least store the settings.

Attack speed is more or less depending on the animation speed. I am not sure to which degree this is adjustable mid game as I haven't worked much with animations yet but it is possible to replace animations with other ones via script. So you could have several attack animations of the same type differing in speed. You wrote that the player cannot live without his head or torse, but I fairly doubt it will increase its lifespan if his arm gets chopped off. Movement can be restricted via setMoveHinderance(...) (to make him slower) or via Immobilizations (to disallow jumping or climbing). In regards to the air lowering I suggest taking a look at the breath potion script. I think it utilizes the heal function which can also get negative arguments to lower health or, in this case, air amount. If I may share my opinion I would like to state that I was no big fan of the health system in the first Deus Ex. Having the overall health amount spread over several limbs makes it hard to really judge on how harmed you are and the effects caused by wounded body parts is either neglectable (low damage) or becomes such an annoyance, that players will probably tend to reload their last safe (high damage). And if they don't wanna do the latter as too much progress would get lost, they may have to live with the consequences for a while (annoying and after a while even frustrating) or will immediately heal the wounds, which leads back to the case were the effects are neclectable. In return I don't really see any benefit caused by this system, especially in a game were the player avoids confrontation and fights anyways. Just my two cents, though.

Is there a reason for that behaviour? Otherwise it would be more logical to allow to have brushes with several mirrored sides and render them all as mirrors.

I agree with HMart and may add, that concepts of oop have also found their way into other aspects of Doom3 and therefore TDM. You just have to take a look at entity definitions and the entity class tree. The concept of inheritance plays an important role here. Of course you don't need to know about every aspect of programming just to be able to make proper use of scripting, but you definetely need the basics. What aspects are important and what not is something hard to judge by someone new to that matter, but experienced people can tell you. I did so in the past and my experience is that people simple don't want to, as they don't want to deal with how graphic engines work to improve the performance of their missions or to deal with modeling programs etc... If there is a wiki article people somehow expect it to be simple and fast to learn. But if you point them to anything longer than five sides things get uncomfortable. If everything else fails you can still ask someone else for help

In the case were the player has no inventory item selected he has one selected, just none with a visible symbol and with no effect when "used". Can't remember the name of the entity def right now but its behaviour could be changed so it performs the desired action instead, so perfectly doable. In regards to the GUI I would suggest to alter the inventory grid gui, so that it opens up a menu with several ingame menus instead as usual in other games. So the player presses the key for the inventory grid/map/objectives and a menu opens that allows him to choose between checking his inventory, taking a look at the map, check objectives or to spend skill points. This way you wouldn't need a specific key for the "skill tree page" but instead the player could use the menu of said gui to get there. Maybe even the best idea in that case to stick to only one key or replace one of the existing ones if you don't need them (for example if you merge objectives and map screen) if you don't want such a menu. Altering the main menu gui wouldn't be much of an issue as you only need to rename one of the strings there. So you wouldn't even have to touch the associated gui files. In regards to the skills that affect weapon behaviour (firing rate, precision et al.): those are mostly handleable via the weapons scriptobjects. Making those attributes changeable shouldn't be much of a deal in most cases. If there are more skills you think of and don't know how to implement I would need to know more to tell you whether (and probably how) to implement those. In regards to modding TDM via dll's. I don't know much about those specific aspects of programming to exactly tell you on how easely it is to create custom dll's to alter the behaviour of the source code or to add features to TDM without having to rely on or wait for future updates. It sounds like a promising approach. @HMart or any of the other more skilled coders might be able to tell you more on this matter.

How do you plan to do it in the future, as using a gui for such a thing appears to be the natural decision?

When I wrote I've stumbled upon it either I've meant five years ago or so, and stating its restrictiveness wasn't a complaint, just a determination. On another note Mircea is requesting feedback on a very specific key. @MirceaKitsuneAs you want to know whether the use key is pressed or not, can I assume that you intent to utilize it for something else then its default usage and/or want to replace the current inventory (as otherwise you may get into conflict with the use response of the currently selected inventory item)?

getButtons returns a specific part of the user input, but not the impulses. class usercmd_t { public: int gameFrame; // frame number int gameTime; // game time int duplicateCount; // duplication count for networking byte buttons; // buttons << that's what gets returned signed char forwardmove; // forward/backward movement signed char rightmove; // left/right movement signed char upmove; // up/down movement short angles[3]; // view angles short mx; // mouse delta x short my; // mouse delta y signed char impulse; // impulse command << that's what you are looking for byte flags; // additional flags int sequence; // just for debugging public: void ByteSwap(); // on big endian systems, byte swap the shorts and ints bool operator==( const usercmd_t &rhs ) const; }; The values it can hold are const int BUTTON_ATTACK = BIT(0); const int BUTTON_RUN = BIT(1); const int BUTTON_ZOOM = BIT(2); const int BUTTON_SCORES = BIT(3); const int BUTTON_MLOOK = BIT(4); const int BUTTON_5 = BIT(5); const int BUTTON_6 = BIT(6); const int BUTTON_7 = BIT(7); I've already stumbled upon this in the past as I've came with the same expectation as you did when discovering the function getButtons(). But it is indeed very restricted. Forwardmove/Rightmove/upmove is also accessible via getMove(), but that's it. Impulse are not accessible.

Flooding the map (what can cause leaks) is not done due to performance, but for pathfinding. So it may not affect performance all too much (unless you have lots of AI walking around) but may cause issues with pathfinding. You can use the pointfile to track down the leak. Once you get used to it it is fairly simple. If you still encounter issues and/or often stumble into having leaks you may overthink your mapping workflow, too. The Substract Tool can cause brushes to be split up into lots of smaller brushes and does not grant you any control over how the splitting is done, which can lead to malformed brushes thats surfaces consisting out of long thin tris, of which the first one can be bad for performance and the latter can cause you graphic issues. The tool is perfectly fine for cutting axis-aligned cuboid holes into an axis-aligned cuboid brush, for example when making doors or windows, but if used to create details the result is not good and the tool should notbe used for that purpose. Although I personally think that never was the intention behind it. So or so details shouldn't be worldspawn either way.

The function expects the entity as argument. Entities are referenced via $ in combination with their name. So if the entity is called atdm_key_simple_iron_dark_1 the reference is $atdm_key_simple_iron_dark_1 (so the name with a $ in front). Don't use "", those are for strings.