Trigger syntax: Always accept numbers/Other EUD input ideas

1 view
Skip to first unread message

rockz

unread,
Sep 29, 2009, 12:53:19 AM9/29/09
to Starforge
I think it would be a nice thing if numbers were always acceptable in
the trigger syntax. For example, P1 would go in the player section of
the trigger, but you can also type in 0 (which is player 1). If
possible, the re-opening of the trigger would revert it back to "P1",
but if not possible (27+ or 256+), it would simply show the number.

Likewise, inputting 0 into a unit's spot would change it to terran
marine, unless greater than 228. Obvious reasons are for EUDs, but
also since it could be faster to input a number instead of typing the
name, especially if you've memorized that particular number. 0 is a
whole lot faster than typing ma), or whatever you've named it to.

There does lie a problem for units/strings which have numbers already
in the name. Perhaps a preceding character would work, or a checkbox
which would disable custom names in the actual trigger editor? That
would actually be useful in itself.

This would also allow for easy use of leaderboard deaths. (Show
leaderboard of kills of unitID+228)

If none of this is possible, or probable, there still could be a
solution. SCMDraft's memory condition isn't very good, but works,
nonetheless. Looking at the trig format, it looks like there are some
unused bits all over the place. Could one of these be used by SFU to
toggle between different, brand new conditions/actions? For example,
if bit 0 is "1" on the flags byte, SFU would read the action as
leaderboarddeaths, whereas if it were 0, SFU would read the action as
leaderboardkills, but everything else would be the same. The same
could go for the memory condition.

Jon Cable

unread,
Sep 30, 2009, 1:38:57 AM9/30/09
to Starforge

All trigger parameter fields should allow a number with a pound sign I
front of it, like # 345

Heinermann

unread,
Sep 30, 2009, 5:12:24 PM9/30/09
to Starforge
SF:U already has all of that and more.
rockz does bring up a good point though, to have user defined
conditions and actions. As it stands, we can't do anything to the sf/
triggers.txt file.
Reply all
Reply to author
Forward
0 new messages