Jump to content
The Dark Mod Forums

Newbie DarkRadiant Questions


demagogue

Recommended Posts

7 hours ago, Frost_Salamander said:

... and can't reach the lever.

Well, that could be intentional, 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

3 hours ago, Obsttorte said:

Well, that could be intentional, though.

perhaps, but do we agree it probably should be up to the mapper though?  In one of my scenarios, the 'door' is actually one of those large iron gates that slides upwards.  The AI shouldn't be able to open it without some sort of mechanical assistance.  But yeah, if we're talking about a flimsy wooden door then sure why not.

Link to comment
Share on other sites

36 minutes ago, Frost_Salamander said:

perhaps, but do we agree it probably should be up to the mapper though?

I do agree. And unless someone is against it, I guess it's safe to change 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

@Frost_Salamander@Geep

The desired setups can be achieved by using door_handle_position entities. If a door should not be able to be operated from one side, place such an entity on that side, add it to the dhp of the door (via door_handle_position spawnarg) and set ai_no_open on it to true.

The same setup works for secret doors.

The ai will walk through the door if it is open, but will not open it on itself, even if fleeing.

ai_should_not_handle is not working as intented, but I don't know the exact reason. The forbidden aas areas mentioned earlier on are temporary and used by all doors. By default they get removed once the door is open. I guess the serve the pathfinding algorithm, even though the naming is odd.

As the above way works, I closed the entry and suggest to not use ai_should_not_handle at all, but the above approach instead.

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

9 hours ago, Obsttorte said:

@Frost_Salamander@Geep

The desired setups can be achieved by using door_handle_position entities. If a door should not be able to be operated from one side, place such an entity on that side, add it to the dhp of the door (via door_handle_position spawnarg) and set ai_no_open on it to true.

The same setup works for secret doors.

The ai will walk through the door if it is open, but will not open it on itself, even if fleeing.

ai_should_not_handle is not working as intented, but I don't know the exact reason. The forbidden aas areas mentioned earlier on are temporary and used by all doors. By default they get removed once the door is open. I guess the serve the pathfinding algorithm, even though the naming is odd.

As the above way works, I closed the entry and suggest to not use ai_should_not_handle at all, but the above approach instead.

So I just tested this, and it stops the fleeing AI from opening the door, but he still won't walk through it after it's been opened.  Other AI do though (for example a guard chasing me did go through it).  Not the end of the world but still strange.

1 hour ago, Dragofer said:

Yeah, I mentioned door handling position entities for this a little earlier on.

Yes I remember and thanks.  I wasn't too enthusiastic about it because I don't like the default behavior and these all seem like workarounds.  I had made a mental note to try it if nothing else worked though.

Maybe there is a good reason for not calling this a bug, or not changing it but I'm not sure what it is. Fear of breaking existing missions maybe?

Anyways, I'll put something in the Wiki about it once I'm 100% sure about what's going on here.  thanks @Obsttorte for looking into this.

Link to comment
Share on other sites

If you use a door handling position entity it stops the AI from using a controller as well.  This makes sense in a way, as you are basically saying 'don't enter the door from that direction'.

My requirement is different - I want to be able to say 'only open the door using the mechanism I want to be used'.  If I have a gate that is 20 feet tall and weighs a ton, nobody is going to be opening it by touching it.

I've attached a test map to illustrate.  A guard sees you behind a gate that he should be able to open with a lever. However he can't because I've had to put a door handling position entity in front of it to stop the commoner AI from being able to open it.  If you take away the door handling position, the guard will able to open the gate, but then you get the commoner able to open it with his magic hands.

The other nuance here is that the commoner can't get to the controller because it's behind a locked door that only the guard can operate because it's his station and not open to the public.  It's a perfectly reasonable setup.

aidoors.map

Link to comment
Share on other sites

Quote

Anyways, I'll put something in the Wiki about it once I'm 100% sure about what's going on here.

Sounds good. Since I'm only 2% sure what's going on here 🤷‍♂️, I'll leave any wiki update about all this in your capable hands.

  • Like 1
Link to comment
Share on other sites

18 hours ago, Frost_Salamander said:

My requirement is different - I want to be able to say 'only open the door using the mechanism I want to be used'.  If I have a gate that is 20 feet tall and weighs a ton, nobody is going to be opening it by touching it.

I see what you mean and admit I haven't thought of this specific case before. Can we work under the assumption, that if at least one controller is targeting a door it is not meant to be opened directly?

18 hours ago, Frost_Salamander said:

Maybe there is a good reason for not calling this a bug, or not changing it but I'm not sure what it is. Fear of breaking existing missions maybe?

It appears to me that there is a reason for the door handle entity having those spawnargs. The implementation has some flaws, though. The other spawnarg on the door itself seems to be a leftover of an earlier implementation attempt, which may not got finished or throughly tested. It is a bit redundant. I may take another look to take you case into account.

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

33 minutes ago, Obsttorte said:

I see what you mean and admit I haven't thought of this specific case before. Can we work under the assumption, that if at least one controller is targeting a door it is not meant to be opened directly?

For my scenarios, the answer is yes.  But surely there might be others where you'd want to be able to do both, like in real life (e.g. my flimsy wooden door example).  This is why the mapper needs total control of this ability.

36 minutes ago, Obsttorte said:

It appears to me that there is a reason for the door handle entity having those spawnargs. The implementation has some flaws, though. The other spawnarg on the door itself seems to be a leftover of an earlier implementation attempt, which may not got finished or throughly tested. It is a bit redundant. I may take another look to take you case into account.

Maybe we should just treat is as a new feature request?  You're right in that those other solutions have their reasons for existing, and I don't have a problem with them really because they are meant to solve different issues (although the bit with the AI not being able to go through the door after it's opened needs fixing).

 

Link to comment
Share on other sites

@Frost_SalamanderI've looked at the code and it appears that the intent is to let the ai use a controller if present, but not the door. Therefore I've tested your map and am not able to reproduce the issue. Here are my observations:

  • ai_no_open causes the ai to not open the door at all (neither directly nor via controller), which is basically what the name implies
  • if not set, the ai will only open the door via the controller, not directly (neither armed nor unarmed). In your test map the unarmed ai tried to reach the controller, couldn't do so because of the locked door and made a very sad face, but it doesn't opened the door directly.
  • you have not monsterclipped the controller, which can lead to the ai beeing unable to open the door with it because it keeps blocking it due to standing too close (unrelated to the issue, but a noteable mention). Overall there are pathfinding issue in the test map, probably due to the strange geometry (haven't checked the aas areas, as I would have to lookup first how the command was and it is not the issue here)

I have tested both under 2.10 and svn. Maybe you can make a video of your observation so I can see what you mean, just in case I missunderstood you. But so far it appears to be working as intented.

 

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

34 minutes ago, Obsttorte said:

@Frost_SalamanderI've looked at the code and it appears that the intent is to let the ai use a controller if present, but not the door. Therefore I've tested your map and am not able to reproduce the issue. Here are my observations:

  • ai_no_open causes the ai to not open the door at all (neither directly nor via controller), which is basically what the name implies
  • if not set, the ai will only open the door via the controller, not directly (neither armed nor unarmed). In your test map the unarmed ai tried to reach the controller, couldn't do so because of the locked door and made a very sad face, but it doesn't opened the door directly.
  • you have not monsterclipped the controller, which can lead to the ai beeing unable to open the door with it because it keeps blocking it due to standing too close (unrelated to the issue, but a noteable mention). Overall there are pathfinding issue in the test map, probably due to the strange geometry (haven't checked the aas areas, as I would have to lookup first how the command was and it is not the issue here)

I have tested both under 2.10 and svn. Maybe you can make a video of your observation so I can see what you mean, just in case I missunderstood you. But so far it appears to be working as intented.

 

I couldn't get the commoner to open the door directly either - and I admit I didn't actually test that on this map.  What I was trying to say was if the commoner didn't have a path to the controller he would try to open it directly.  But he does have a path to it in this case which is why it works.  What I missed was that even though the door was locked, technically the path is still there.

So, I think in real (as in mapping) scenario you'd always have a path between the door and the controller because obviously whoever opened the door would need to be able to travel to it after they handled the controller.  So basically my imagined scenario doesn't make any sense.

So maybe it's OK?

If so, a Wiki entry on the doors page warning of this behavior and how to solve it would do the trick I think.  You said it worked for secret doors as well - what did you do there just put the door handling entity on both sides of the door?  In my map I used the func_aas_obstacle and that worked for this.  Not sure what the better solution is.

 

 

Edited by Frost_Salamander
Link to comment
Share on other sites

3 hours ago, Frost_Salamander said:

what did you do there just put the door handling entity on both sides of the door?

One side should suffice. As the door is normally only hidden from one side ;) . But yeah, that's basically it and is preferable as it also allows the ai to pass the secret door once opened (by the player).

3 hours ago, Frost_Salamander said:

What I was trying to say was if the commoner didn't have a path to the controller he would try to open it directly.

I didn't found anything in the code that checks whether the door is reachable from the lever (or vice versa). Besides the question on how feasable this setup is, are you sure this is the case?

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

39 minutes ago, Obsttorte said:

I didn't found anything in the code that checks whether the door is reachable from the lever (or vice versa). Besides the question on how feasable this setup is, are you sure this is the case?

It's a bit of a guess and no I'm not 100% sure.  I'll try to test it again to see.

Link to comment
Share on other sites

Hello TDM crew.

I am wondering what it takes to make a knocked out or dead body to be non-solid to keep ai from tripping over it?

I am trying to deal with a situation where other ai run over a ko/dead body and kick it around.

I have tried $ai.disableClip() and $ai.becomeNonSolid(), but it is still happening.

Ideas?

Much appreciated.

Clint

Link to comment
Share on other sites

You can try setContents(0), but this will also make them invisible to AIs, unfrobable and maybe cause them to fall through stuff. The most practical would be to ensure there's enough space.

Link to comment
Share on other sites

6 hours ago, cvlw said:

I have tried $ai.disableClip() and $ai.becomeNonSolid(), but it is still happening.

Is this because the script events are just not implemented?  I get this sometimes too and wonder if there is a way to tell?  It's just a lot of trial and error it seems.  If that is the case, something in the script reference for each event would be helpful.

Edited by Frost_Salamander
Link to comment
Share on other sites

6 hours ago, cvlw said:

I have tried $ai.disableClip() and $ai.becomeNonSolid()

Is ai in your case the name of the ragdoll entity? Because as far as I remember it is not the same as the initial ai that got knocked out (it gets replaced if I am not mistaken).

The ragdoll to be used or more precisely the respective entity definition is refered to in the spawnarg ragdoll, so you could also try to alter the definition and make it nonsolid from there.

Just now, Frost_Salamander said:

Is this because the script events are just not implemented?  I get this sometimes too and wonder if there is a way to tell?  It's just a lot of trial and error it seems...

If this would be the case an error would be promted in the console.

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

5 minutes ago, Obsttorte said:

If this would be the case an error would be promted in the console.

well I meant more like it's implemented but does nothing just to satisfy interface requirements, like you see in some OO code.  Not sure if that's a thing here or not.

Edited by Frost_Salamander
Link to comment
Share on other sites

5 minutes ago, Frost_Salamander said:

well I meant more like it's implemented but does nothing just to satisfy interface requirements, like you see in some OO code.  Not sure if that's a thing here or not.

Do you have an example? I don't think I ever came across something like 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

1 minute ago, Obsttorte said:

Do you have an example? I don't think I ever came across something like that.

Not off hand no. Say you have an abstract class or interface you need to implement and it has a method called 'doSomething()'.  In the implementing class you have to implement the method, but say it doesn't make sense to have it do anything, so you just implement it and have it do nothing.  There could be various reasons for this, like early in a project and it's just not implemented yet, or bad design, or using base classes from a totally different game... 

Link to comment
Share on other sites

2 minutes ago, Frost_Salamander said:

Not off hand no. Say you have an abstract class or interface you need to implement and it has a method called 'doSomething()'.  In the implementing class you have to implement the method, but say it doesn't make sense to have it do anything, so you just implement it and have it do nothing.  There could be various reasons for this, like early in a project and it's just not implemented yet, or bad design, or using base classes from a totally different game... 

That is clear. But the scripting system isn't object oriented and there are no virtual functions afaik. There might be script functions that are bugged (I haven't tested all of them), but that's rarely the case (out of the top of my head I know of only one script function that I had to fix).

  • Thanks 1

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

On 7/23/2022 at 7:43 AM, Dragofer said:

You can try setContents(0), but this will also make them invisible to AIs, unfrobable and maybe cause them to fall through stuff. The most practical would be to ensure there's enough space.

I am not referencing as any ragdoll that I know of, just the name of the ai entity.

It seems there may be something to KOed ai having a different entity name.  I did $ai.setContents(0) on a living ai and he went invisible but still interacted with stuff.

How might I find the name of an ai AFTER they are KOed/killed?

Thanks again

Clint

 

Edited by cvlw
Link to comment
Share on other sites

6 minutes ago, cvlw said:

I am not referencing as any ragdoll that I know of, just the name of the ai entity.

It seems there may be something to KOed ai having a different entity name.  I did $ai.setContents(0) on a living ai and he went invisible but still interacted with stuff.

How might I find the name of an ai AFTER they are KOed/killed?

Thanks again

Clint

 

The name definitely doesn't change after a KO/kill. Maybe setContents just doesn't work as expected for AIs.

Link to comment
Share on other sites

@cvlwAre you sure it is the ai that you are colliding with? They have lots of stuff attached to them (armor, weapons et al.) and I am not sure whether the content flags get transfered to attached entities upon change.

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

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