Hello all, allow me to first introduce myself, as I don't normally browse this section of the forums. I am a modder whose ancient "claim to fame" is a mod called STF, short for Starcraft Team Fortress. A new modding application has been created by Poiuy_Qwert called LocUnlock, which for the first time ever allows modders to use locations in melee games. This opens a huge number of possibilities, but also poses a few challenges. In an UMS map, you set up and control everything on a single map. In a mod using LocUnlock, a player could use any map.

For over a decade, locations could not be utilized by modders (unless coupled with an UMS map), until now. I was always a modder, never a mapper, so my knowledge of the triggering system is basic at best. I would really like to utilize LocUnlock in my latest mod project, but the lack of foreknowledge limits my creativity with it. I simply don't know if some things are possible, or if there is an advanced way to accomplish my gameplay goals.

That is why I am here, in the hopes that those more versed in the art of triggering can answer certain questions I have. My first question was born from discussion inside LocUnlock's thread, but drifted into more UMS-related inquiries.




This was outside his realm of expertise, so I come to you guys, the mapping gurus, with the same question.

If you give a CC to another player, anything in progress is canceled and the inputs are given back to the player. Also, the building is deselected if you have it selected. That means if you have the trigger running constantly, you won't be able to select it.

http://www.staredit.net/topic/4581/

This thread essentially deals with the same thing, because Oyen wants to set hp to a %, which involves detecting the unit in the first place. I think the best way is to use burrowed zerglings under the buildings, and using the "command" condition to detect how many zerglings and buildings there are in the game. You'd need one for each possibility, and to actually get the zergling under the building, you first have to center on the building (which requires that the buildings be given to another player.

Another problem arises with buildings which have been lifted.

This is an excellent solution. Luckily, by virtue of being a mod, I can create an invisible, invincible, unselectable flying unit to act as my detector.

What about centering a location on every Geyser on a map? Since the amount does not change, I wouldn't need a constant detection cycle, but I don't know if there's any other way due to the amount always varying between maps.

Centering on geysirs is not possible as they are not units, but terrain. You can, however center on buildings (Extractor, etc.) built on it.
Or even much simpler, just preplace a location above every geysir, as geysirs won't move or be killed there's no need to ever recenter.

Preplacing would not be possible, as it's not an UMS map. Because it is a mod, it can be played on any map, each of which has a different amount of geysers at different locations.

As for Geysers being terrain, technically they are a unit, as they have a unit ID in units.dat. This is where modding and UMS mapping diverge, as I can change that kind of stuff.

There is actually a checkmark option called "Location Triggers" under the StarEdit tab in DatEdit. If that allows the Geyser to show up as an option for centering a location, then I've got something. If so, my original question stands: "What about centering a location on every Geyser on a map? Since the amount does not change, I wouldn't need a constant detection cycle, but I don't know if there's any other way due to the amount always varying between maps." Any ideas?

What's the problem here? Just run your cycle once placing a location on each one.

I'm just curious, is there a specific instance you want to know this for?

You could instantly cycle through the buildings, in a single trigger loop, by using Binary Count-Offs and adding a useless remove unit action at the end, to make sure the Bring command updates properly between transferring units. If you want to read more about that last part, it was discussed here.

Of course, as discussed, this would cause problems with how it would cancel any units being built, so that's definitely a problem, but you seem to have already solved that.


Lulz. There is geyser terrain, I'll give you that, but the actual geysers you build on are units.
Also, he cannot simply preplace, as this will vary between maps.

I believe geysers, just like any other unit, can be given to another player, so you could cycle through them just like you do the buildings, and give each a location, while this might take a bit of brute-forcing, it should work, and then when you're finished you can just give them all back to Player 12.

You're probably right. They kinda work like mineral blocks. Sry for the confusion.

About the cycling: you only need to do it at the start of the map because - and that part of my post was true - they are immobile, so there should be no problem.
After the cycling, as Falk said, just give them back to P12.

Anyone happen to know or have an idea about how well the AI handles itself after ownership-swapping?

Here's a n00b question: We have the normal 1-8 player slots, and 12 is Neutral who owns all the resource nodes and critters. What of 9, 10, and 11? I ask because with ownership-swapping for the Geysers, who could I give it to (since 1-8 could be taken by normal players on larger maps)?


Do you mean whether I'm asking just to ask, or if it's going to be applied in my mod? If I can get them to work, then most likely yes. I'm doing a lot of crazy stuff in this mod.


The issue really comes down to establishing a location for each geyser. I need it to detect when a unit goes near it. Constant cycling would be problematic.

Hm, I just had an idea. Is this possible?

1. I have the first trigger check to see if 0 of unit X exists, and if not it would center Location A on a geyser and create a unit X. If more than 0 of unit X exist, do not run. Give Geyser to Player Y.

2. If 1 of Unit X exists, center Location B on a geyser. Give Geyser to Player Y.

3. If 2 of Unit X exists, center Location C on Player 12's Geyser. Give Geyser to Player Y.

4. Etc, with Locations D-Whatever amount I want to reserve.

5. If Player 12 has 0 Geysers, give all of Player Y's Geysers to Player 12.

So instead of cycling, I have the triggers go by how many of Unit X exist to determine which premade Location to center on a Geyser.

Post has been edited 1 time(s), last time on Oct 2 2008, 2:13 am by Hercanic.

Dedicate a number of locations for geysers, a reasonable limit, like 14.

Neutral brings at least 1 geyser to anywhere
----
Center Geyser 01 on Geyser for Neutral
Give 1 Geyser for Neutral to Player Y

Do this trigger for each location predesigned to then give them all back to Neutral

Cool, so it'd work? Thank you.

Is this possible: When a location detects unit X, Y, or Z, execute a trigger on the owner of X/Y/Z?

To clarify:
You have 2 choices:
- Cycle through them all the time or in intervals - you need only 2-3 triggers and 1 location
- Use 1 Location and 1 trigger per possible geysir at the beginning of a game.

Cycling seems problematic, so I won't go into details, Falkoner outlined the necessary triggers anyway.
But yes, you can use one of P9-11 for the cycling. This is recommended. They are neutral players which won't attack or run triggers, but giving units to and from them (by using a trigger owned by one of P1-8) works fine.

The static way is obvious too: Have as many triggers as necessary that look like this:
P12 brings at least 1 geysir to anywhere
Center Location x on geysire at anywhere
Give 1 geysir at anywhere to Player 9

... repeat

Then the last trigger: (order is important)
P12 brings at most 0 geysir to anywhere
Give all geysirs at anywhere to Player 12

Problem is you only have 255 locations, which may sound a lot, but it really isn't for large projects. So plan carefully.

About the AI:
AIs are not passed on to other players upon giving the units.
If possible the computer that has received the units will use the units according to his current AI.
If at anytime a computer player has no units, all AIs are cancelled.

Post has been edited 1 time(s), last time on Oct 2 2008, 3:12 am by NudeRaider.

Yes. Triggers are checked player by player.
When you have a trigger owned by All players, and have a condition with a player or group of players in the argument (e.g. Player X brings Y to Z) then the player that is currently checking the condition to be false or true becomes the so called "Current Player". You can reference to that player in conditions and actions.

Actually, players 9-11 are extremely useful, and I don't think I've made a map yet that doesn't use them since I learned about them.

Basically, they are neutral computers, that take up no slots, however, they cannot have their own triggers, therefore no Current Player triggers, such as AIs, can be used on them, like player 12, they retain the color of units given to them, however, unlike player 12, they do not retain alliances, and by default are enemies with everyone, however, due to their odd nature, they do not have proper vision with themselves, so they don't auto attack, and when attacked, will often follow the attacker rather than attacking back. If you want more info, do a search, there's a lot to know about them.

As I said, you will need to brute-force the locations a bit for the geysers, but it should work out.


Really, this is just a faster way to do it than making a separate trigger for each possible combination, but it makes it faster.

You need seperate triggers because of the locations (there is nothing like "Current Location").

Everyone, thank you for your answers.

How far into a location does a unit need to be for it to be detected at that location?

A location will detect a unit if it is touching it even the slightest bit.