Jump to content
The Dark Mod Forums

Newbie DarkRadiant Questions


demagogue

Recommended Posts

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. 

Link to comment
Share on other sites

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.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

8 hours ago, Obsttorte said:

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.

Oh wow: You can't even read the light value at a given origin rather than per-entity? How does anything work without that? I mean doesn't the player script read the light value at the player's location in order to know how to set up the lightgem? If all else fails I'll use the gui value in that case... I was thinking that's a failsafe if other methods are more complicated.

Update: Looked into it and it's a mess I can't make sense of. gui::lightgem_val isn't set anywhere in tdm_base01.pk4/scripts where all TDM related scripts are stored, meaning it should not be working even in the default game! The issue with using getGuiFloat is that it requires a GUI handle, and using one I made myself won't report that value and always gives me 0. I'll wait on further advice on how to approach this.

Edited by MirceaKitsune
Update
Link to comment
Share on other sites

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.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

See /guis/tdm_hud.gui:

gui::lightgem_val

To manipulate you can use lgmodifier:

userEntity.setLightgemModifier("lantern", getIntKey("lgmodifier"));

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

1 hour ago, Obsttorte said:

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.

The engine code contains TDM specific functionality? I thought it only offers functions to compute the light, but such a value would first have to go through a script IIRC. TDM had a lightgem system before idTech 4 was open sourced too, so I assume it was scripted before the code could even be modified unless I'm missing something.

For now I found a workaround for what I need to do, as it doesn't need to know the lightgem value specifically.

Link to comment
Share on other sites

Half the engine started out closed-source (rendering etc.), while the other half (gameplay etc.) has been open-source from the beginning and was modified to create TDM. When the engine went fully open-source, TDM went standalone: 2.0+.

The engine contains a lot of the gameplay coding, a subset of which has been exposed to the scripting system over time. Only some things, like AI, seem to be handled mainly through scripts.

Link to comment
Share on other sites

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.

 

14 hours ago, MirceaKitsune said:

... but such a value would first have to go through a script IIRC.

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.

  • Like 2

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

2 hours ago, Obsttorte said:

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.

How did TDM code its functionality before idTech 4 became FOSS and went standalone then, with no source code to edit? I thought it did so because all specific game code was purely script based.

Not sure how I feel about this. I was hoping only basic functionality was coded in the engine, like the rendering or pathfinding or ragdolls or foot IK and so on: The rest I thought was all scripted... like telling the AI what animations to play, when to become alert, checking when they see an enemy, where to walk to, etc. There is of course code specific to the player or AI, but my belief was it's just common generic stuff (determining movement and visual optimizations and such). IMO this would be the correct way as an engine is usually a general use system... in fact I thought you could still play Doom 3 using the TDM engine binary, obviously not vice versa due to mandatory new features in our engine fork.

Then again I'm learning these days that the scripting system is VERY limited, far more than I thought it was. I'm grateful it allowed for my augmentations mod to be coded in the end, but there's a ton of hooks for modifying player / AI / etc that can ideally be added someday to make modding via scripts possible.

Edited by MirceaKitsune
  • Haha 1
Link to comment
Share on other sites

2 hours ago, MirceaKitsune said:

How did TDM code its functionality before idTech 4 became FOSS and went standalone then, with no source code to edit? I thought it did so because all specific game code was purely script based.

Not sure how I feel about this. I was hoping only basic functionality was coded in the engine, like the rendering or pathfinding or ragdolls or foot IK and so on: The rest I thought was all scripted... like telling the AI what animations to play, when to become alert, checking when they see an enemy, where to walk to, etc. There is of course code specific to the player or AI, but my belief was it's just common generic stuff (determining movement and visual optimizations and such). IMO this would be the correct way as an engine is usually a general use system... in fact I thought you could still play Doom 3 using the TDM engine binary, obviously not vice versa due to mandatory new features in our engine fork.

Then again I'm learning these days that the scripting system is VERY limited, far more than I thought it was. I'm grateful it allowed for my augmentations mod to be coded in the end, but there's a ton of hooks for modifying player / AI / etc that can ideally be added someday to make modding via scripts possible.

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.   

Edited by HMart
  • Like 2
Link to comment
Share on other sites

Quote

.... the lightgem this value hasn't been needed for anything else, hence nobody ever cared to implement a script function for that purpose.

Quote

there's a ton of hooks for modifying player / AI / etc that can ideally be added someday to make modding via scripts possible.

I think we FM mappers need to be less shy in requesting new script API functions (e.g., as New Features in the bugtracker) where existing methods are inadequate, overly convoluted, or non-existent. The case for a new API offering is strengthened to the degree that it's clear it will be generally beneficial across FMs. The bar for this should be particularly low for "...get..." functions. So, in MirceaKitsune's case, I gather something like this is wanted:

float gem = sys.GetLightGemValue(); // as just calculated this frame by engine

sys.SetLightGemValue(MY_HUD_GUI, gem); // pass it on to my custom HUD

The first of these should be easy to justify. The second would take more persuasion.

 

  • Like 2
Link to comment
Share on other sites

Thanks for the clarification, that explains quite a bit! So there's a separate dll for a separate piece of C++ containing some gameplay code... that makes a lot of sense now. And yeah it would be ideal to have more hooks for the simple script system as well, maybe I'll make a list of the limitations I ran into with my mod and suggest some if that's okay.

Link to comment
Share on other sites

Following up on HMart, because there is no longer an FM-specific dll to modify in C++, I'm thinking that it is far less likely that FM authors will seek to change the C++ code. So doing increasingly more of the mod stuff via scripting becomes important. It is a challenge to design this in a way that minimizes slowdowns inherent to scripting.

  • Like 1
Link to comment
Share on other sites

I agree that enhancing the scripting API can only benefit mappers who also script.

A classic example is my needing a way to find out which location a player is in. Being a dev made it simple for me to add exactly what I needed. Generalizing it to retrieve the location of any entity gave us:

 

$EntityName. getLocation();

which has come in handy for other mappers since it was introduced.

 

 

Link to comment
Share on other sites

I think it would be odd to expect mappers to compile code and distribute a dll with their map. On the other hand scripting is definitely something you can expect from most map builders: I tried to make a FM without any scripts, then ran into limitations so I looked up the basics and in a few minutes I easily wrote a script for what I needed. Thus I agree that more focus on scripting would be a good idea, it's very easy to learn / use as well as very powerful with the right abilities.

And like I said there aren't that many missing features! There are mainly two clear limitations that come to mind... more in total but these two stood out: The first is having no way to read the value of the lightgem, which is a big one and can hopefully be lifted easily by adding a $player1.getLightgem() hook (there's already one to set an offset for it). The other has to do with getting and setting the value of the breath, in case you want to modify the air as easily as you can health (there's allegedly an obscure way using the heal function which I might try if all else fails).

Other hooks I could have used was the ability to force the player in crouch mode, or disable run so they're stuck walking and unable to run... I'd have really needed these two for my player damage mod. Also a way to change the volume of player (and why not AI) footsteps, so you can make the player more silent and harder to hear when walking around. Beyond these and a few others the script system offers most of what you need, just requires a few extra touches in my opinion.

Link to comment
Share on other sites

1 hour ago, MirceaKitsune said:

I think it would be odd to expect mappers to compile code and distribute a dll with their map.

Scripting together with script-based systems is already plenty for allowing mappers to make scripted setups in their maps, in my experience. It's more for people in your situation who want to alter how the game itself functions where being able to code would pay off big time, creating all kinds of new script effects.

You can of course open a ticket and hope somebody else implements that, but as it's a community project the most certain and fastest way to make something happen is to contribute it yourself. In particular as someone who's already shown potential in the form of your scripted addon.

  • Like 1
Link to comment
Share on other sites

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. 

 

Edited by HMart
  • Like 1
Link to comment
Share on other sites

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.

  • Like 2

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Quote

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.

Assuming that Obsttorte is talking about the C++ side of script function implementation, not Doomscript...

Please recall how much time (measured in years) and effort it takes to come to a complex C++ system like a game engine and gain "understanding how the whole setup works". That includes not just the code, but the whole process of gaining access to it and developing and propagating a change to it.

So asking if someone who already has achieved that mastery could add a function seems collaborative and not unreasonable. By putting in a formal request, including any attempts at work-arounds, the need is documented, even if it won't be fulfilled in a timely way because of the press of requests. More importantly, if gives other FM authors the chance to comment and say "I could use this too"... thus showing community interest and making it more appealing for a C++ coder to take it on in the near term.

Regarding the slowness of scripting, which HMart reiterated...

Yes, so my abstract design about getting the lightgem value is not really best from a performance standpoint. What would be better is a design where the scripter asks to be notified whenever a value changes, e.g.,

sys.RegisterHookFunctionFloat(LIGHTGEM, myHookFunction, CALL_ON_CHANGE);

where the third parameter is UNREGISTER = 0, CALL_ON_CHANGE = 1, CALL_EVERY_REFRESH = 2)

void myHookFunction(float changedValue)

{

}

There would be something similar for vectors.

In the most evolved version of this, the registration process would involve a linked list, so that multiple hook functions could monitor any given value.

Does this design make sense for MirceaKitsune's actual updating of a custom GUI? I have no idea.

Link to comment
Share on other sites

@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.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

@Obsttorte, sounds fair enough.

I agree that hook functions would be a new feature for TDM. What would be gained is that the per-frame checking is done in C++, so real fast, rather than in an endless Doomscript loop thread. And would only call the slower script upon a change.

Just floating it out there as a thought.

Link to comment
Share on other sites

22 minutes ago, Geep said:

I agree that hook functions would be a new feature for TDM. What would be gained is that the per-frame checking is done in C++, so real fast, rather than in an endless Doomscript loop thread. And would only call the slower script upon a change.

That sounds very much like the Signals system, which lets the C++ continuously check the status of an entity and calls a specified Doomscript if necessary. Some more of that sounds quite good. Though I wonder whether get() functions are that slow, even in Doomscript.

Link to comment
Share on other sites

Ha, I guess it does, now that I reviewed the "Signals" wiki page. Except the discussion above was more about values that were known to the engine, like LightGem value, and not entities defined in scripting, which Signals deals with. Also, the wiki article seemed to hint at some doubts as to how thoroughly signaling was implemented.

I hope your Scripting A - Z efforts might cover Signals and so raise awareness about them.

Link to comment
Share on other sites

8 hours ago, Geep said:

@Obsttorte, sounds fair enough.

I agree that hook functions would be a new feature for TDM. What would be gained is that the per-frame checking is done in C++, so real fast, rather than in an endless Doomscript loop thread. And would only call the slower script upon a change.

Just floating it out there as a thought.

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.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • The Black Arrow

      Any of you heard Age of Wonders 4's OST?
      https://www.youtube.com/watch?v=Q0TcoMGq4iA
      I love how after all these years, Michiel van den Bos still conserves his "Melodic" spirit.
      · 0 replies
    • nbohr1more

      Moddb article is up:  https://www.moddb.com/mods/the-dark-mod/news/the-dark-mod-212-is-here
      · 3 replies
    • Petike the Taffer

      I've been gone for a while, but now I'm back, have a new desktop and I want to get back to making missions and playing missions. And doing other contributions. Waiting for my reset password for the wiki, but I'll take a look at it soon. Hello, all.
      · 4 replies
    • snatcher

      TDM Modpack 4.0 for The Dark Mod 2.12 released!
      · 1 reply
    • nbohr1more

      Congrats to all the busy Dark Mod developers! TDM 2.12 is here!
      · 4 replies
×
×
  • Create New...