Jump to content
The Dark Mod Forums

trigger_entityname coul use default "entityname" entry


DeusXIncognita

Recommended Posts

I tried to use a few entity specific triggers, to make an interesting path network.

Not working right yet, but before the map loaded I got an error:

 

 

idTrigger_EntityName 'trigger_Entityname_1' doesn't have 'entityname' key specified

There was also the position mentioned.

 

That was of course solved by including the entityname, to specify the entity that should trigger this Trigger.

But since the 'entityname' property wasn't set from the beginning, nor was visible in the inherited properties, but is required with this triggertype, I thought to mention it here.

Link to comment
Share on other sites

Yes, that's a known problem. I don't know if the code handles a default value (say '-'), which might be why it's left out.

 

I'll file a bugtracker for this and see if there's a way to handle a default condition.

 

Thanks.

Link to comment
Share on other sites

I think it's said in the description of the entity, that you have to set this key. And getting the error is much better then letting the code ignore this stuff and you wondering why the trigger is not working ;)

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

I think it's said in the description of the entity, that you have to set this key. And getting the error is much better then letting the code ignore this stuff and you wondering why the trigger is not working ;)

It doesn't exactly say that in the description:

 

The description says:

Variable sized repeatable trigger that only responds to a specific entity. The entity to be triggered must be named, targeted entities are ignored. Only works on entities that can enter trigger under their own power...if player drops them, there is no effect.
The basic time between firing is a random time between (wait - random) and (wait + random).

 

I guess there was a language barrier coming into it too, as I thought "The entity must be named" meant that the entity must have a name, but now I think it means that the entity that triggers it must be named in the key.

Maybe just add in the description, that the property 'entityname' has to be set for it to work, with the name of the triggering entity as value.

 

You are of course right, that the error has the nice benefit of letting you know you forgot something. But then it would be better to get that in the dmap already, not when starting the map I think. (might not be possible, because of how things work though, I don't know about that)

 

 

The description of the entityspecific trigger_once is even more vague on that subject:

 

Variable sized single-use trigger that only responds to a specific entity. Must be targeted at one or more entities. Only works on entities that can enter trigger under their own power...if player drops them, there is no effect.

 

The basic time between firing is a random time between (wait - random) and (wait + random).

Here it says it must be targetet at entities, not that you have to set the key 'entityname' (you get the same error at map start).

Maybe put it in the description here too, then the one working with it knows how the name of the key that is to be set is (instead of finding out at map start).

Link to comment
Share on other sites

The targets are the entities that get triggered by the trigger once it triggers (so if the entity is inside the trigger, the trigger triggers its targets).

 

You are right, though, that the formulation could be more precise.

 

 


as I thought "The entity must be named" meant that the entity must have a name, but now I think it means that the entity that triggers it must be named in the key.

All entities must have names and just because they have one others do not know about them, so this wasn't an option anyway. :P I'll change the descriptions once I find the time.

How about that:

Instead of

 


The entity to be triggered must be named, targeted entities are ignored.

we could use

 


The entity that should activate the trigger must be specified via entityname.

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

Nearly all triggers use the 'targetNN' spawnarg and a wiki phrase that says "A targets B" means to use those spawnargs. In a few cases, though, where "A targets B" means something else, then both the wiki description and the editor comments should clearly specify what's needed. trigger_entityname fails to do that, and needs to be corrected. I think I filed a bug report to make that happen (Not home atm, so can't check.)

 

Edit: 'entityname' doesn't function like 'targetNN', but the idea still holds: important spawnargs should be defined somewhere. The wiki page does call it out, but there should be some kind of default editor description that describes the key spawnarg this entity needs to work.

Link to comment
Share on other sites

  • 3 weeks later...

Nearly all triggers use the 'targetNN' spawnarg and a wiki phrase that says "A targets B" means to use those spawnargs. In a few cases, though, where "A targets B" means something else, then both the wiki description and the editor comments should clearly specify what's needed. trigger_entityname fails to do that, and needs to be corrected. I think I filed a bug report to make that happen (Not home atm, so can't check.)

 

Edit: 'entityname' doesn't function like 'targetNN', but the idea still holds: important spawnargs should be defined somewhere. The wiki page does call it out, but there should be some kind of default editor description that describes the key spawnarg this entity needs to work.

 

Agreed. And I think the entity def should set a default value, even if this is something like "fill in entity name here". That way the mapper both sees what to do and where, and also the entity def can specify that the value of the key is an entity - there are important distinctions between colors, integers and entity names, f.i. DR knows that if you rename the entity, it also needs to change the value pointing to the entity. Without that definition, DR ignores the value, leading to a broken trigger.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I'm forming an idea of fixing the spawnarg documentation in DR. It shouldn't be difficult to extract all the code that reads spawnargs from the game code and the scripts, along with a line of context either side so we can see what kind of value the spawnarg holds, e.g. an entity name or a color etc. The bit that would need a lot of human time would be deciding which ones to make show up in DR. We wouldn't want ALL the idEntity spawnargs to show up for everything, for example, but we would want *some* inherited spawnargs to show up for some entities. That decision probably needs to be made by a human rather than a script.

Link to comment
Share on other sites

I'm forming an idea of fixing the spawnarg documentation in DR. It shouldn't be difficult to extract all the code that reads spawnargs from the game code and the scripts, along with a line of context either side so we can see what kind of value the spawnarg holds, e.g. an entity name or a color etc. The bit that would need a lot of human time would be deciding which ones to make show up in DR. We wouldn't want ALL the idEntity spawnargs to show up for everything, for example, but we would want *some* inherited spawnargs to show up for some entities. That decision probably needs to be made by a human rather than a script.

 

The old id code had about 50% (or maybe 30 or maybe 80%, I don't know exactly) documentation on spawnargs - and almost everything afterwards by TDM was not documented, until I started the big spring cleaning :)

 

Others then chimed in and we added a lot documentation, but there are still hundreds of not documented spawnargs. The ones that are set on entities can be see in the online documentation http://bloodgate.com/mirrors/tdm/doc/index.html#overview

 

However, that does not cover spawnargs which are defined/used in the code, but not set on any entity def.

 

As for adding them in the entityDefs, I think it is important to cover them all. The editor (DR) can then decide which to show or how, but they should be absolutely documented via the entityDefs. That at least sets their type (int, entityname, color, shader etc.) and a sensible default value and some documentation.

 

It's IMHO better the mapper has a few too much than a few hidden spawnargs.

 

DR also already decides which sparnargs to show where, I think it depends on the base type of the entity. F.i. idLights get different spawnarg shown than idTrigger, which makes sense.

 

But generating the list of missing spawnargs and their type from the code usage is probably easier than doing it manually like in the past.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

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

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 1 reply
    • 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
×
×
  • Create New...