Jump to content
The Dark Mod Forums

Obsttorte

Active Developer
  • Content Count

    5917
  • Joined

  • Last visited

  • Days Won

    93

Everything posted by Obsttorte

  1. 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.
  2. 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 m
  3. @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 unders
  4. 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 q
  5. 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). An
  6. 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 th
  7. 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.
  8. "def_projectile" does not refer to the ai's ranged skill but refers to the definition of the entity to use as ranged ammo.
  9. 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.
  10. 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.
  11. 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.
  12. 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;
  13. 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 l
  14. 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 jumpi
  15. 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.
  16. 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 i
  17. 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 inve
  18. How do you plan to do it in the future, as using a gui for such a thing appears to be the natural decision?
  19. 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)?
  20. 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 imp
  21. 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 ca
  22. 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.
  23. Yes. You have to extent the ai's base script. I think Springheel already utilized this as an aberation of my trigger_look script. Probably for "A New Job".
  24. Patches are intented for round surfaces, so edges shared by two tris of the same patch will always have the same Vertex normal and therefore look smooth and round. If you want something edgy-looking, use Brushes.
  25. @MirceaKitsuneLike @Dragofersaid. If lights can have models (can't remember right now as it has been a while) and you use the particle as model, you may even be able to skip the "set _color on flame" part (note that there is a space after set).
×
×
  • Create New...