Jump to content
The Dark Mod Forums

Newbie DarkRadiant Questions


demagogue

Recommended Posts

13 minutes ago, AluminumHaste said:

Yeah that's exactly what it is. You have to go View->Options->View Tab->Uncheck Hide extensions for known file types

That did it. Crisis averted!

Thanks taffers, you guys are the best.

  • Like 2

As my father used to say, "A grenade a day, keeps the enemy at bay!"

My one FM so far: Paying the Bills: 0 - Moving Day

Link to comment
Share on other sites

Is there any protocol for gabbing about what one has discovered, when experimenting with getting something to work in TDM?  I guess so long as I'm polite, people aren't forced to read it...

I've been trying to get some teleported AI to follow paths, so created a small test map for the purpose.

One thing I hadn't seen mentioned is that the test map requires that some AI (dummyAI) already be in the test area of the map at start.   It can't be in a sealed room or a room that it can't exit from - it has to be able to access the test area where the teleport and paths are.  Otherwise nothing related to pathing of the teleported AI (t_AI) will work.  The dummyAI needn't be pathed, and it can be removed at any time before or after the teleportation.  (I guess it tells the engine that dmap has to do the area calculations...)

The wiki article 

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

is correct in explaining that it's best to target t_AI at a path_waitfortrigger, which in turn targets the first path_corner of t_AI's route.  So to avoid yet another script I had a trigger_once target both the atdm:teleport and t_AI.  That plan (is the only plan that) seems to work every time.

One can target t_AI at a path_corner, but that only works in a half-ass way and the path_corner must target a looped path.  The looped path doesn't have to loop back to the original path_corner, it can be a closed loop somewhere along the way.  However, it appears to be absolutely arbitrary which path_corner in that series that t_AI will head to first, except it seems to be rare if ever that t_AI will head to the original corner it's targeted at.  It changes arbitrarily with each dmap of the same setup.  So that's hardly recommended.  

Why didn't I do it the correct way from the start?  Best not ask that question, but at least now I feel confident that I can set up a more complicated in-game scenario. 

  • Like 1
Link to comment
Share on other sites

I guess it doesn't hurt, but it's not really a post where you ask for help, so I would say this isn't the correct topic and you would possibly not get the correct feedback. Create a new topic if you want to discuss this further.

Edit 22 dec: Reading it now, this is actually kind of a weird post I did back then.

Edited by datiswous
Link to comment
Share on other sites

@datiswous

Pathing teleported AI is a legitimate topic.  If you can't see the questions that I've been addressing in my test maps, leading to my post, that isn't really my problem.  There's no way I can know what the experts on S/R, scripting and pathing might contribute to expand my understanding, if they should feel motivated.

Link to comment
Share on other sites

1 hour ago, geegee said:

Is there any protocol for gabbing about what one has discovered, when experimenting with getting something to work in TDM?  I guess so long as I'm polite, people aren't forced to read it...

I was answering this question, but I see that my post wasn't helpfull to you.

Link to comment
Share on other sites

1 hour ago, datiswous said:

I guess it doesn't hurt, but it's not really a post where you ask for help, so I would say this isn't the correct topic and you would possibly not get the correct feedback.

Make up your mind.

Edited by geegee
Link to comment
Share on other sites

5 hours ago, geegee said:

Is there any protocol for gabbing about what one has discovered, when experimenting with getting something to work in TDM?  I guess so long as I'm polite, people aren't forced to read it...

I've been trying to get some teleported AI to follow paths, so created a small test map for the purpose.

One thing I hadn't seen mentioned is that the test map requires that some AI (dummyAI) already be in the test area of the map at start.   It can't be in a sealed room or a room that it can't exit from - it has to be able to access the test area where the teleport and paths are.  Otherwise nothing related to pathing of the teleported AI (t_AI) will work.  The dummyAI needn't be pathed, and it can be removed at any time before or after the teleportation.  (I guess it tells the engine that dmap has to do the area calculations...)

The wiki article 

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

is correct in explaining that it's best to target t_AI at a path_waitfortrigger, which in turn targets the first path_corner of t_AI's route.  So to avoid yet another script I had a trigger_once target both the atdm:teleport and t_AI.  That plan (is the only plan that) seems to work every time.

One can target t_AI at a path_corner, but that only works in a half-ass way and the path_corner must target a looped path.  The looped path doesn't have to loop back to the original path_corner, it can be a closed loop somewhere along the way.  However, it appears to be absolutely arbitrary which path_corner in that series that t_AI will head to first, except it seems to be rare if ever that t_AI will head to the original corner it's targeted at.  It changes arbitrarily with each dmap of the same setup.  So that's hardly recommended.  

Why didn't I do it the correct way from the start?  Best not ask that question, but at least now I feel confident that I can set up a more complicated in-game scenario. 

1. By placing and removing a dummy AI you force aas32 calculation in the relevant area because if at map start there is no AI in the relevant area, no aas32 will be generated for it. The easier way is simply to use the entity "aas32_flood" and place it on the ground brush of the relevant area. Thus you can avoid the stuff with the dummy AI.

2. I would suggest that the teleported AI starts with no target path_corner, after teleportation you can add a path_corner with the entity "atdm:target_changetarget":

target ---> name of AI

add ---> name of desired path_corner

 

That should makes things much easier.

 

 

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

9 hours ago, geegee said:

One can target t_AI at a path_corner, but that only works in a half-ass way and the path_corner must target a looped path.  The looped path doesn't have to loop back to the original path_corner, it can be a closed loop somewhere along the way.  However, it appears to be absolutely arbitrary which path_corner in that series that t_AI will head to first, except it seems to be rare if ever that t_AI will head to the original corner it's targeted at.  It changes arbitrarily with each dmap of the same setup.  So that's hardly recommended.  

Why didn't I do it the correct way from the start?  Best not ask that question, but at least now I feel confident that I can set up a more complicated in-game scenario. 

I don't 100% get, what you did there, but it sounds as if the AI has several path_corners as targets. If this is the case, it will choose one at random and go there. If I remember correctly, they can even be weighted: as an example you can give the AI two targets and make it head for one in 30% of cases and the other in 70%; it can add some randomness to AI paths, which can be interesting. There is a wiki-page on how to set these random paths up. If you want to make sure that your AI always takes the same path, give it only one path_corner as a possible target.

Regarding AAS I would like to expand on what JackFarmer already wrote (and you figured out yourself): Any area that an AI should walk in has to have the respective AAS (if it is not there, you will get the error message "AAS out of date" in the console), which is created during dmap. For this at least one entity with the respective AAS needs to be in this area. Either this is an AI or a AAS_flood entity (As JackFarmer wrote). If you want to check which AAS_flood entity you need for which AI, you can check the "use_aas" spawnarg of the AI. By the way this is also a common problem, when creating an elevator, since any floor that no AI starts on, will not have the respective AAS created during dmap. The need for the AAS_flood is mentionen on the elevator wiki page.

  • Like 1
Link to comment
Share on other sites

Hi destined.  Yes, this is strange AI behavior, but I had nothing much to do for awhile so re dmap'ed the test area over and over trying to figure it out.  Nope, the AI only targeted one path_corner.  I have to go out now but I could attach the .map file later (only 280 lines) after reproducing that configuration.

I experimented with giving the paths the "chance" spawnarg but there were no results relevant to what I wanted the AI to do, which is, port in and immediately start one exact path to a destination - after which all hell breaks loose.   I know that "chance" works when doing what Sotha calls "RIT" random interesting things, but in those cases the AI isn't teleported in and aimed at a corner to start.  The AAS_flood/elevator example is good (and interesting) to know.    For elevators I use grayman's prefab almost untouched and so far have escaped the horror of trying to set that thing up - now I know a bit more about what it is I'm pasting in there.

Hi JackFarmer.  I cloned your crane setup from hhtlc into a testmap just to see how it was done.  Not in a million years would I have figured out those rotate stoppers!  Anyway, in the test setup that worked every time I didn't have the teleported AI targeting a corner, but a path_waitfortrigger.  The path_waitfortrigger then targeted the corner of choice.  When I triggered the teleport entity, because I wanted the AI to start the path at once I used the same trigger_once to target the AI, and the AI was triggered the same instant it popped into the test area.   If I wanted the AI to pause before starting the path I'd have the trigger_once target another trigger_once with a delay on it, targeting the AI. 

The info on how I could use the atdm:target_changetarget is going to be put to use in another area where I have some very complex pathing.  I didn't know you could target an AI to add a path_corner.  I've been using the changetarget targeted at a corner, then changing the corner it's pointed at.  Having it target the AI might simplify things considerably (knock on wood).

Link to comment
Share on other sites

9 hours ago, geegee said:

 

I experimented with giving the paths the "chance" spawnarg but there were no results relevant to what I wanted the AI to do, which is, port in and immediately start one exact path to a destination - after which all hell breaks loose.   I know that "chance" works when doing what Sotha calls "RIT" random interesting things, but in those cases the AI isn't teleported in and aimed at a corner to start. 

 

have you tried this approach as well?

grafik.thumb.png.2e6a694f011d37e964d57b9e2b4e4928.png

The entity Trigger Random selects the targets with evenly weighted chances.

 

Edited by JackFarmer
Link to comment
Share on other sites

2 hours ago, JackFarmer said:

have you tried this approach as well?

No, I've never used a trigger_random.  So far, all my changetargets have been from loop to loop to terminate, the several AI being separately triggered to pace around their own distinct paths.   I haven't incorporated RIT yet.

Link to comment
Share on other sites

4 hours ago, STRUNK said:

I'm trying to get the textures on patches right, but I can't get it to work.
Here's a part of @Obsttorte's video where he does what I can't get to work: https://youtu.be/GfBh6Lhox7o?t=3407
My texture stays streched and bend although I think I do exacly what is done in the video ...

It looks like you're trying to copy-paste a texture (2D project) from a brush surface onto a patch. Just copy the texture from the brush surface with MMB, then paste onto the patch with ctrl + MMB - this will project the texture onto the patch. If the brush surface is not in the same plane as the patch you'll get a stretched texture.

  • Thanks 1
Link to comment
Share on other sites

A footnote to my posts re. difficulties with teleporting AI and pathing.  

My aim is to teleport in reinforcements to both sides of an ongoing battle, with the reinforcements teleported to areas well away from the battle and ordered to take paths toward it,  only then to react and join the fight.  I did tests to ensure that those areas are distant enough so visual and sound alerts can't reach.  The paths are taken if the AI isn't teleported in - and the AI join the battle.  But AI teleported in are pre-alerted to everything happening in the location provided by the info_location, even if the teleport area is blocked by info_portalsettings with sound_loss spawnarg.  Since they're alerted they won't take the paths and since they can't see or hear the battle they run around in circles, cursing almost as loud as I am.  To keep the AI unaware on teleporting in it's required that the teleport area be in a distinct location provided by an info_location - and then they'll be obedient and follow the damn paths!!

Link to comment
Share on other sites

Is there something weird about the origins of projectile entities?  I'm trying to determine the origin of a rope arrow after it has struck something, but the value I'm getting back is in a completely different part of the map (quite far behind and below where the entity is actually sitting).

I'm doing something like this, and it's called from a trigger_touch when the arrow hits it:

void checkArrow(entity ent)
{
    string className = ent.getKey("classname");
    if (className == "atdm:ammo_ropearrow_stuck")
    {
        vector entOrigin  = ent.getOrigin();  // this is waaaaay off
    }
}

 

Link to comment
Share on other sites

23 hours ago, Frost_Salamander said:

Is there something weird about the origins of projectile entities?  I'm trying to determine the origin of a rope arrow after it has struck something, but the value I'm getting back is in a completely different part of the map (quite far behind and below where the entity is actually sitting).

I'm doing something like this, and it's called from a trigger_touch when the arrow hits it:


void checkArrow(entity ent)
{
    string className = ent.getKey("classname");
    if (className == "atdm:ammo_ropearrow_stuck")
    {
        vector entOrigin  = ent.getOrigin();  // this is waaaaay off
    }
}

 

I've figured this out - I think the arrow had a bind parent, so using getWorldOrigin() instead gave me the proper origin.

Link to comment
Share on other sites

I've just noticed that the 'timescale' console command only works if you have 'uncap FPS' set to 'off'.  Is this something that is common knowledge?  Are there any other settings that affect it?

Either way, it should be in the Wiki page where the command is mentioned as my first thought was it must be a 2.09 bug because I used it quite a few times before I switched.  I'm happy to update the Wiki - how do I go about getting an account?

Link to comment
Share on other sites

@Frost_Salamander, in Time, frames and ticks, Stgatilov wrote, under "Important cvars/timescale":

"I think it should only work without uncapped FPS"

So perhaps it's already covered sufficiently on the wiki? There seem to be on-going discoveries of problems with the newish uncapped FPS feature.

My experience RE a wiki account is that newbies will likely be rebuffed, but if you've successfully released an FM and been around contributing in a positive way for a while, then a PM request to one of the old hands with admin privileges (which is not me) will be favorably received.

Link to comment
Share on other sites

1 hour ago, Geep said:

@Frost_Salamander, in Time, frames and ticks, Stgatilov wrote, under "Important cvars/timescale":

"I think it should only work without uncapped FPS"

So perhaps it's already covered sufficiently on the wiki? There seem to be on-going discoveries of problems with the newish uncapped FPS feature.

My experience RE a wiki account is that newbies will likely be rebuffed, but if you've successfully released an FM and been around contributing in a positive way for a while, then a PM request to one of the old hands with admin privileges (which is not me) will be favorably received.

Hi @Geep thanks for that.  Well, we can say it definitely doesn't work with uncapped FPS on, so it would be cool if someone added a note here: https://wiki.thedarkmod.com/index.php?title=Console_Useful_Controls#Notes

Re: the Wiki - I don't know who all the 'old hands' are, or if they will respond, and the thought of spamming random people with DMs makes me uncomfortable quite frankly.  Perhaps that's by design and if so, it's working.

Link to comment
Share on other sites

48 minutes ago, Frost_Salamander said:

Re: the Wiki - I don't know who all the 'old hands' are, or if they will respond, and the thought of spamming random people with DMs makes me uncomfortable quite frankly.  Perhaps that's by design and if so, it's working.

@Springheel @greebo are among those (admins) who can enable the wiki for forum users. That said, if I'm not misremembering there was talk about automatically allowing any validated forum member (with a few posts?) to log into the wiki for making edits. The rationale for not doing this automatically may have been troubles with spambots in the past.

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

      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.
      · 1 reply
    • 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
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...