i have questions about the nitty-gritty details of how map entities work.

adamspurgin

L1: Registered
Mar 22, 2010
42
1
i'm working on a project that requires me to know exactly how map entities work, i thought this might be the best place to ask.

  1. if an entity has multiple outputs set to fire on the same trigger, do they fire in the order they are listed? or is it more of a "when the server gets to it" sort of thing?
  2. if they do not fire in order, is there any way to ensure they do?
  3. is there anyway to spawn logic type entities into the map during gameplay?
  4. is there some way to simulate integer division without having to construct an in-game ALU?
  5. let's say i've got a logic_compare with two imputs that are also logic_compare entities. if i know that all the values going into each of those "sub"-logic_compares are going to change before i want the final result, is there any way to keep the "top" logic compare from changing values until each input has updated?

i'd appreciate any help i can get. i don't want to give away too much information as to what i am working on, because then i'd feel like i made a promise that i probably won't keep. just know that if i pull it off, your friends might not bother you with questions about complex entity structures as much.
 
Last edited:

StickZer0

💙💙💃💙💙
aa
Nov 25, 2008
664
647
1. They're in the order shown.
2. Set the delay timer using intervals of 0.05 seconds between each output, this will order them correctly and still fire them all as if instantaneously.
3. Possibly, but it would be better to create them in hammer and disable them until needed.
4. Ask ABoojumSnark.
5. See #4.

I'm serious about 4 and 5, Booj knows everything you'll need to know.
 
Dec 25, 2007
566
439
3. In theory, a point_template could be used to spawn logic entities. In practice? you'd have to try it.

4. math_counter should do integer division. For A / B = C, fire SetValueNoFire with an override of A, then fire Divide with an override of B. Its OutValue should then fire with C.

5. So you always want to wait until both compare_A and compare_B have had Compare fired at them before firing Compare at compare_C? I think this does what you want:

  • logic_compare compare_A (these are your three logic_compares that you have)
  • logic_compare compare_B
  • logic_compare compare_C
  • logic_relay relay_A_ready (starts disabled)
  • logic_relay relay_B_ready (starts disabled)

And the following I/O (OnGreaterThan picked out of a hat for the sake of example)

ENTITY|ON INPUT|TARGET|INPUT
compare_A|OnGreaterThan|compare_C|SetValue
compare_A|OnGreaterThan|relay_A_ready|Enable
compare_A|OnGreaterThan|relay_A_ready|Trigger
compare_B|OnGreaterThan|compare_C|SetCompareValue
compare_B|OnGreaterThan|relay_B_ready|Enable
compare_B|OnGreaterThan|relay_A_ready|Trigger
relay_A_ready|Trigger|relay_B_ready|Trigger
relay_B_ready|Trigger|compare_C|Compare
relay_B_ready|Trigger|relay_A_ready|Disable
relay_B_ready|Trigger|relay_B_ready|Disable

Graphically, the logic something like this:

Code:
compare_A ---\
                    +--> compare_C (values)
compare_B ---/

compare_A ---\
                    +--> relay_A_ready ---> relay_B_ready ---> compare_C (triggering)
compare_B ---/

With this setup, both compare_A and compare_B will have to both compare as "greater than" before both relays are enabled, and only then will compare_C actually do its comparison.
Once compare_C has been triggered, the relays are disabled to reset it ready for next time.
 
Last edited: