Jump to content
The Dark Mod Forums

Recommended Posts

Posted

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.

Posted

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.

Posted

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

Posted

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

Posted

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

Posted

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.

  • 3 weeks later...
Posted

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

Posted

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.

Posted

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

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

    • Frost_Salamander

      @taaaki Wiki seems broken. Main page works but click any link and:

      · 2 replies
    • Goblin of Akenash

      Another goblin secrets episode on the way with the new update
      Focuses are:
      supporting 100% runs on shadow playstyles
      fixing the softlock
      and a tiny visual upgrade

      · 0 replies
    • STiFU

      Sorry for not being around enough lately. I am extremely busy at the moment. We are trying to build a home and the German bureaucracy is killing me! Meanwhile, child number 2 is underway. 🙂
      · 0 replies
    • cvlw

      Yo TDMers.
      It has been a while.  This past year or so I have encountered some tough family issues, became a grandfather, had a job change, and then Steam offered Dishonored and Dishonored 2 along with all DLC for like 5 dollars.  So... have played that.  What a game; highly recommend.
      I am looking to resume TDM activity soon.
      Clint
      · 2 replies
    • Airship-Ballet

      If anyone would like some ambient sounds for any of their work please do hit me up - I've tons of strings both physical and sampled that I love making loops with
      · 2 replies
×
×
  • Create New...