Jump to content
The Dark Mod Forums

Newbie DarkRadiant Questions


demagogue

Recommended Posts

@Geep
No, but several authors have expressed an interest in it previously (including those who've released most of the heaviest FMs) and it's received some discussion.

  • Thanks 1
Link to comment
Share on other sites

I have some user-defined stims (sr_type >= 1000), and I want the response to be attached to the player object. How is this done? The only way I could figure out is to clone the default tdm_player_thief.def file into my mission folder, and modify it by adding my responses to the atdm:player_base object. This works, but it seems suboptimal (and maybe risky?). Is there a better way?

Link to comment
Share on other sites

13 hours ago, joebarnin said:

I have some user-defined stims (sr_type >= 1000), and I want the response to be attached to the player object. How is this done? The only way I could figure out is to clone the default tdm_player_thief.def file into my mission folder, and modify it by adding my responses to the atdm:player_base object. This works, but it seems suboptimal (and maybe risky?). Is there a better way?

Never mind, I figured out a better way. In a .def file, define a custom 'player' that inherits from the default and includes the custom responses. Something like:

entityDef my_player_thief
{
    "inherit"                            "atdm:player_thief"
    // add custom responses
    "sr_class_5"                    "R"
    "sr_type_5"                        "1000"
	...

Then, on any worldspawn, define a spawnarg, "player_classname", with a value of your custom player entity (in this case, "my_player_thief"). When TDM starts it looks for that spawnarg on the worldspawn, and spawns that entity instead of the default one. Since my_player_thief inherits from atdm:player_thief, it behaves just like the default player, except for the changes you add/override.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

2 hours ago, joebarnin said:

Never mind, I figured out a better way. In a .def file, define a custom 'player' that inherits from the default and includes the custom responses. Something like:

entityDef my_player_thief
{
    "inherit"                            "atdm:player_thief"
    // add custom responses
    "sr_class_5"                    "R"
    "sr_type_5"                        "1000"
	...

Then, on any worldspawn, define a spawnarg, "player_classname", with a value of your custom player entity (in this case, "my_player_thief"). When TDM starts it looks for that spawnarg on the worldspawn, and spawns that entity instead of the default one. Since my_player_thief inherits from atdm:player_thief, it behaves just like the default player, except for the changes you add/override.

Jeff,

Could you be so kind and elaborate on that? I do not understand why you had to do it the way you just described it.

What was the original intention? What is the in-game effect or the custom gameplay effect you could achieve with that?

Link to comment
Share on other sites

@JackFarmer For this mission I have a unique projectile (something like a fireball) that doesn't actually damage the player when it hits them, it has some other effect. I decided to implement this using stim/response. So my fireball has a stim attached to it (more accurately, the stim is attached to the "def_result" associated with the fireball). When the fireball 'hits' the player, I want a certain effect - this is implemented by a response. So the response has to be defined on the player object. The technique I describe above enables you to add responses to the player object. (It also enables you to change other player parameters, like walking speed or starting health, by the way).

Maybe there's a better way to do this, but the technique I describe seems to work. Hope this makes sense.

Link to comment
Share on other sites

@joebarnin
Nice work, it's somewhat more sophisticated than the system I had in Down by the Riverside for detecting player proximity to certain entities, which was to bind a nodraw func_static custom stim-emitting cube to the player with a script at map start. Yours is probably the correct way to do it.

@JackFarmer
In my case, I used such a system to make the glowing footsteps appear when the player goes near. Each pair of footsteps was a patch func_static that was hidden at map start, with a Response that calls a script to fade it in in when the Stim attached to the player comes near.

Link to comment
Share on other sites

I've got to ask: Does dist_check_period / hide_distance really not work for anything other than func_static?

I understood they won't affect complex light entities using models and attached lights. Yet distance based hiding won't even function for standard light entities! I was hoping to at least hide some discrete window projectors, this might have helped a lot. Is there really nothing that can be done to enable that feature on any light type?

They won't even work on func_emitter: Those too emit visible particles after I'm well out of range 😭

Personally I can live with this situation but I swear: If anyone's going to say performance is bad on my map, my reply is always going to be "hide_distance is set on lights and particles but the engine doesn't want to respect it" 😛 It's such a simple and effective optimization yet it doesn't want to work in a handful of essential cases.

Link to comment
Share on other sites

Bear in mind that LOD system is very old, IIRC it was designed by Tels and never improved upon much since. Ideally, every entity except worldspawn should be able to use LOD, but it's not an ideal situation.

And yeah, performance is still your responsibility. Either you get to know the engine and design maps to leverage its strengths or you will see players complaining, whether you like it or not.

  • Like 1
Link to comment
Share on other sites

Reported it on the bug tracker, really hope it can be taken a look at. This one feels a little frustrating because it's something both very basic and very effective in improving performance (given how costly lights are), plus I was convinced it worked on lights too till noticing it won't. I'm actually keeping those parameters for small lights on my map in advance, in case the limitation can get fixed soon.

https://bugs.thedarkmod.com/view.php?id=5668

While on technical questions I wanted to ask something else, specifically to other Linux users here: After I reboot my system I'm using about 3.0 GB of RAM. The moment I open a large map in DarkRadiant, usage jumps to nearly 7.0 GB... this is most likely normal. The weird thing is that once I close it, I'm barely down below 6.0 GB. Why does DR permanently fill the memory so much, even after its process gets closed? The system monitor shows DR only using 1.5 GB of memory, meaning the rest might be the inode cache of the files it loaded. I know this likely has to do with large textures of all things... TDM by comparison seems to free its memory better after I quit, so I wonder if something is up still.

This can become an annoyance: I have 16 GB of RAM... when running both DarkRadiant and TheDarkMod to test my map, my system's memory usage ends up jumping to 12 GB eventually which starts alerting the kernel that I'm getting close to RAM limit. I don't have a SWAP partition any more, and currently not enough money to buy another set of memory modules and bring my system to 32 GB. Thus this seemed worth asking about if the memory use can be mitigated.

Edited by MirceaKitsune
Link to comment
Share on other sites

1 hour ago, peter_spy said:

There already was a feature request to extend LOD to other entities, I believe there was more than one. So don't expect anyone rushing to fix this for you, because it's not that simple.

Yes, this is technically a form of LOD. Though I assume hiding is different from setting different LOD models on a mesh. Naturally I'd assume it wouldn't be complicated to make the engine turn off a light when the view is past a certain distance, just as it can be toggled by a trigger... of course I don't know the code and complications often emerge where you least expect them.

Link to comment
Share on other sites

On the issue of attached loot breaking ragdolls and AI: As suggested I tried changing my atdm:loot_amulet_wearable entity to an atdm:loot_base with its model and other properties. On the living AI this still causes the attachment to make the character spin in place, meaning the bad collisions are still there.

I also tried setting "inherit atdm:moveable_loot_base" on the entity, someone suggested that movables might make for safer attachments. However that too has the same effect.

Any other suggestions? I'm kind of stuck on this one.

Link to comment
Share on other sites

@joebarnin@Dragofer

Ah, my mistake, I thought "Player object" would not refer to the player itself but to something else.

Well, if you could bind an invisible, non-solid func-static to the player, then you could give the func-static the necessary stim and distance. But I have my doubts that it will work (have never tried it). However, I was already wondering how you can get the effect that lights activate when you approach and deactivate when you move away:

With S / R that is probably not possible, since only one-time actions are triggered. Hm....

Link to comment
Share on other sites

On 7/12/2021 at 7:06 PM, joebarnin said:

Never mind, I figured out a better way. In a .def file, define a custom 'player' that inherits from the default and includes the custom responses. Something like:

entityDef my_player_thief
{
    "inherit"                            "atdm:player_thief"
    // add custom responses
    "sr_class_5"                    "R"
    "sr_type_5"                        "1000"
	...

Then, on any worldspawn, define a spawnarg, "player_classname", with a value of your custom player entity (in this case, "my_player_thief"). When TDM starts it looks for that spawnarg on the worldspawn, and spawns that entity instead of the default one. Since my_player_thief inherits from atdm:player_thief, it behaves just like the default player, except for the changes you add/override.

Why are you opposed to changing the player's definition? As long as you have your def-file in the FM-folder it will not affect anything other than the FM itself. If I understand your workaround correctly, you are also creating a player entitiy that inherits its properties from the original. I cannot really see any benefit. You only have an additional step.

Link to comment
Share on other sites

4 hours ago, Destined said:

Why are you opposed to changing the player's definition? As long as you have your def-file in the FM-folder it will not affect anything other than the FM itself. If I understand your workaround correctly, you are also creating a player entitiy that inherits its properties from the original. I cannot really see any benefit. You only have an additional step.

As a general rule, I too prefer the most "gentle" way of hooking into default definitions in order to change them from a FM. It can depend on how you look at it, but I feel mission authors should have to modify builtin stuff as little as possible. Thankfully this is usually the case already, with small exceptions such as in this scenario.

Worth bringing up while we're on overriding defs: One limitation I remember running into is that you can't expand an existing definition, by redefining it and having it inherit itself. You have to make your own def out of it, which can be tricky as you also need to make entities reference a different name. It would be nice if this sort of thing could be supported someday:

atdm:my_ent
{
	"inherit" "atdm:my_ent"
	"override_property" "override_value"
}

 

Link to comment
Share on other sites

This is exactly why I asked. I undesrstand the hesitation of changing existing entities, especially if you may have more than one of them in your map and the changed properties may not be suitable for all. For this, you have spawnargs that can be changed in DR (which I assume is what you meant with "but I feel mission authors should have to modify builtin stuff as little as possible. Thankfully this is usually the case already"). The player entity is a special case, because (as far as I know) it cannot be changed in DR. However, there is only one instance on the map, so any changes can only affect this one entity. And as you pointed out, on important advantage of changing the def-file in this case is, that creating a new entity may require you to change other references.

Regarding your suggestion of overriding defs. The way you suggested cannot work, because you create a loop in the definition, in which the definition targets itself. And if you want to change the definition and keep the name, anyway, why use this intermediate step and not simply change the original definition in your map? I cannot see, why your way is norably different from it. Also, the way TDM handles def files is exactly designed in a way to support modification by map authors, with def-files in FM folders taking precedent over core def-files. This way you can change anything you want without affecting/compromising the core files. If you notice a crash or have any unwanted effects, you can simply delete the def-file in the FM folder and revert any definitions to their original form.

  • Like 1
Link to comment
Share on other sites

7 hours ago, Destined said:

Why are you opposed to changing the player's definition? As long as you have your def-file in the FM-folder it will not affect anything other than the FM itself. If I understand your workaround correctly, you are also creating a player entitiy that inherits its properties from the original. I cannot really see any benefit. You only have an additional step.

In general, I feel it's best practice to extend an existing definition, rather than copying it and modifying it. Say, for example, in a future release of DM, the developers make a change to the tdm_player_thief.def file. With my original technique, anyone playing my mission won't see that change (because my mission is using a cloned version of the old tdm_player_thief.def file). With my preferred technique, that change will be maintained, because I'm just extending the existing definition.

Link to comment
Share on other sites

 

On 7/14/2021 at 8:29 AM, JackFarmer said:

However, I was already wondering how you can get the effect that lights activate when you approach and deactivate when you move away:

With S / R that is probably not possible, since only one-time actions are triggered. Hm....

I think there's probably a way to make this happen with a custom s/r and some scripting. I'll think about it.

Edit: here's how. Set up a custom stim near the light, with an appropriate stim radius. The stim fires every 200 ms. Add a corresponding response to the player object. Custom responses call a script. That script looks like this:

if (!light_already_on)
{
	$mylight.On();
	light_already_on = true;
	lightTime = sys.getTime();
	thread checkLight();
}
lightTime = sys.getTime();

light_ready_on is a global boolean, lightTime is a global float. Basically, the response script stores the latest systime that player was near the stim.

The checkLight thread is this:

void checkLight()
{
	if (sys.getTime() - lightTime > 0.5)
	{
		$mylight.Off();
		light_already_on = off;
	}
	sys.wait(.1);
}

Once the light is on, the checkLight thread wakes every 100 ms and compares the current time with the "last time the stim was fired". If it's more than a certain value, the user has moved away and the light is turned off.

Completely untested. Also, the various timing parameters might have to be changed. But it's an idea.

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

On 7/14/2021 at 4:29 PM, JackFarmer said:

However, I was already wondering how you can get the effect that lights activate when you approach and deactivate when you move away:

I do have a downloadable Precursor-style lamp in my Scripting thread, which uses trigger brushes to repeatedly activate a lamp to "keep it alive". As Obsttorte and joebarnin suggest you could also do it by defining a S/R radius, though I've used the trigger brush method to be able to define where exactly a lamp should switch on/off. The problem is that because of a TDM bug, AIs stop activating trigger brushes when they stand still, so my lamps can only react to the player.

  • Thanks 1
Link to comment
Share on other sites

16 hours ago, joebarnin said:

In general, I feel it's best practice to extend an existing definition, rather than copying it and modifying it. Say, for example, in a future release of DM, the developers make a change to the tdm_player_thief.def file. With my original technique, anyone playing my mission won't see that change (because my mission is using a cloned version of the old tdm_player_thief.def file). With my preferred technique, that change will be maintained, because I'm just extending the existing definition.

Ok, this concern I can understand. I am not sure, when the player entity was last changed or how often (if ever) this currently occurs, but I understand that it may cause trouble.

Link to comment
Share on other sites

Here's a fun question to ask. My FM is going to feature both the manbeast and WIP werebeast. Based on the story and what they're meant to represent, I want to make them act a bit more like people rather than monsters.

Which spawnargs should I set on their entities to achieve this goal? So far I configured a few basics:

AIUse AIUSE_PERSON
personType PERSONTYPE_PAGAN
personGender PERSONGENDER_MALE
talks 1

This appears to get human AI to salute them as they walk past each other so that's a start. The creature didn't appear to salute back however. This might be due to the voice pack too: Some of them I leave with the default voice (monsters who can't speak) while others I gave "def_vocal_set atdm:ai_vocal_set_drunk_civilian_01" which fits creatures very well (those monsters that learned to talk). I noticed that giving a human voice set to any animal automatically enables idle chatting, no need to override anything else there... no lipsync of course but that's an understandable limitation.

What about alert and movement patterns? How would I make the manbeast / werebeast search around more like a guard, rather than the default behavior of forgetting you in a few seconds after they lose sight of you? Being able to open doors or operate switches are options in the AI menu so I shouldn't have issues there (except for potential missing animations).

Link to comment
Share on other sites

Need some help here. For language support, I just installed Windows 64-bit Strawberry Perl and downloaded TDM's I18N.pl file. I haven't been able to run it, tho.

When I try this command:

perl I18N.pl --english away0.pk4

I keep getting the complaint:

Can't open perl script "I18N.pl": Permission denied

Giving the full path to i18N.pl doesn't help. I've tried running this command in the Win console with admin privileges, and in the Perl-provided console, but still the same. Tried moving the folder from the d drive to c at the top level, still the same. Inspected the I18N.pl properties, and under the Security tab, see that all accounts can read and execute the file. I tried altering the first line within the .pl file to reflect the actual path to the perl interpreter; made no difference.

The paths to the interpreter and to i18N.pl have no spaces, as recommended by Strawberry Perl. In the registry, the environment/PATH appears to be OK.

Most of the perl forums advice is about linux versions. Anyone else had and solved this?

Edited by Geep
Link to comment
Share on other sites

Scripting question... making something fun I'll hopefully be able to share soon. I have a float time in seconds and I want to convert it to a string in the form "mm:ss". Is there a builtin function to do this, or if not what's the best way to code it?

I managed to get it working for the most part by using:

float t = time_now - time_start;
float ts = sys.floor(t % 60);
float tm = sys.floor(t / 60);
string s = tm + ":" + ts;

This has a problem though: The 0 isn't added at the beginning of each number for one letter values. So instead of getting something like 01:04 I get 1:4. How do I fix this?

Additionally it would be nice to make it cap at 99:99 just in case: It shouldn't ever need to measure more than 99 minutes.

Edited by MirceaKitsune
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

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...