SC2Mapster

Making an update because I changed the title for good and took some major decisions after a first test on Bnet.... heh, with only 2 players, but that was enough to see what directions I could take this in.

Progress / Change log

- Changed the map's title to Temple of Entropy (it was "Probe Cauldron" before :P )
- Gave it an actual background concept
- Changed the players' unit model to a High Templar (was a probe)
- Say hello to the Wakkalisk: First monster which spawns randomly from treasure chests, causes death on touch, and moves randomly
- Added a second monster that hunts players down: just named Brutalisk for now
- Added ability to "erode" tiles with the Erosion Bolt

.....
...EDIT: A limited alpha (Temple of Entropy) is now public on European server. Come join any time if you can find anyone to play it with. I may not need the recruits strictly, but it would still be nice to see if anyone had enough interest to support the project somehow, maybe help with how to refine the gameplay where possible.

I'm using:

Events:

Unit - Any unit is issued an order to Smart Command

Unit - Any unit is issued an order to Move

Actions:

Unit - Order (Triggering unit) to (Triggering order) (Replace Existing Orders)

Is there a better/smarter way to disable order queues without using the order event? This way, by the way, will not work and is not very good since it triggers itself. I have tried "UI - Disable Modifiers for (All Players)", but that doesn't disable the functionality either. Can anyone think of an effective way to disable order stacks?

Temple of Entropy

With an ill-begotten name, the Temple of Entropy brims with ancient treasures. Once a sanctuary of stability, it is now soon to be melted away by perilous lava. Your quest is to salvage what lies hidden in dangerous chests, before the tide comes in, in order to be entitled the High Templar of Entropy.

Maze / Arcade Fix

Temple of Entropy is an arcadey multiplayer map somewhat reminiscient of the classic Bomberman. The map consists of a large platform made out of tiles on top of a lava lake.

At each match start, a temple-themed map of size decided by the players is generated with treasure chests and walls randomly created.
The goal is to move your High Templar around to gather the most Loot Points within a time limit. Every treasure chest holds a Loot Point, and some will also hold additional items and powerups.

Many treasure chests are booby trapped. Some will spawn a monster, others will cause melting of nearby tiles. Depending on your loot angle, some booby trapped chest will melt up to 6 floor tiles in North and South directions, or up to 6 floor tiles in East and West directions. Walls sink and join the floor when melting applies on them.

Players can use this maze-generating mechanic strategically. You can use it to destroy loot for other players, trap another player, or simply dump a competitor into the lava.

Release and Schedule

I want to promise a release before September, beacuse from then on I won't have as much time to work on the map. I live and play in Europe, but until September I may work on this and communicate almost any time of day or night.

What This One Does

I make triggers and things in the Data Editor. I'll also make a soundtrack and some custom sounds. I'm constantly adding things to improve the gameplay towards my goals of making players have fun battling it out minimalistically. The basic mechanics do not offer much nuance, so every feature I can add counts a lot and can break or make the gameplay. After the last update I think I just about doubled the gameplay quality, though all that says is that there's still plenty of room for improvement.

Positions

Textures

I could use some variations for tiles and treasure chests. A member to handle this would be greatly appreciated.

Testing

Anyone who's interested in testing would also be appreciated. Tell me if you are interested in this, maybe with a PM, and we can plan a test session on bnet periodically.

@AdrianXtra: Go

Edit: I posted a reply that was wrong I found out.. I suggested that the triggering unit was not technically dead yet, but a quick test showed that it was according to your condition and I was sorry. How have you setup the unit group?

Uhm, this is probably stupid, but I sometimes can't seem to save map attachments as anything but text documents full of cryptic characters.

I understand the alternative method, I just have to learn about attachments to know how to do it, but in the first method I don't know what you mean by a barrel model?
Anyway, I can try method 2 for now. At first I was moving units through triggers, but that seemed so silly to me so I decided to change most of the map to work through data, which is a huge challenge for me. Thanks a bunch for your help! :-)

Edit: It works! I would have used the Invisible model for the unit actor but the ability couldn't target it, so I used the closed treasure chest and Set Opacity [0,0] though that may seem a little clumpsy.

The messages are called Alerts I think.

These are my guesses:
Try to look in the Alerts tab. Find BuildComplete_[Race] and edit the field "Text" that says "Construction Complete".
As for the icon, I think it displays the Alert icons associated with their build and upgrade buttons. Try and go to them in the Buttons tab and set the Alert Icon field. If they're allready set, I was definitely wrong, but I recommend you try that if you haven't.

I have an actor with the model swap action happening on Behavior.MyBehavior.On. This new model however needs to be offset in order to look right, so I'm trying to make a SOp (Local Offset) create itself on Behavior.MyBehavior.On. It has to be this particular model.

I've done this same thing for a Rocker by simply adding Create to event Behavior.MyBehavior.On. That worked perfectly for the Rocker, but for the Local Offset, it's not working at all, doing nothing. I have tested that my SOp works by having the main actor host it, but that's just a test to see that my SOp was working at a basic level. So the Rocker will create itself when you ask it to, but not the Local Offset?

I'm doing something wrong here.

I made an actor "Chest Vanish SOp" of type Site Operation (Local Offset) ... Parent CActor
Added event: Behavior.ChestVanish.On
Action set to: Create.
Finally, in game I get to the point where the behavior is added and works completely except for the missing local offset.

Ask if you need more details.

Edit: Okay, the Local Offset targets the wrong actor! It targets a model that shows on the unit instead of the unit itself. I discovered this by setting the Y offset to 10 where it became clear that it did work, but on the wrong actor. So what I've tried in order to fix this was setting Content to alias Unit in the create action. Don't ask me why I tried this, I'm clueless. It doesn't seem change anything when I link the unit actor to the SOp with hosting. Besides, seeing from how it worked with the Rocker, it shouldn't be necessary to link them. If I could only think of some good example to look at.
Edit 2: I'm guessing I must use some term to specify the target. I'm currently experimenting with that, but it doesn't seem to be so simple.
E: Nope, can't find anything that works.

Edit: No, I was wrong. I had accidentally linked the spell model to the SOp. I have corrected that, but it means that the SOp is not being created on anything... or is it?
I've attached a picture to get your attention and so you can see what I mean. I want that chest to be offset only AFTER it changes model so its base is always centered on the tile.

If I've confused you, please ask me to clarify anything. I really need this help.

Triggering Unit is clearly not overwritten.

I put 2 SCVs in a map and made a test trigger:

Event

Any Unit is Selected by player Any Player

Actions:

Wait 5.0 Game Time seconds

Kill (Triggering unit)

I selected SCV 1, and right after I selected SCV 2. After 5 seconds, SCV 1 dies, and briefly after, SCV 2 dies. I've never had trouble with using Triggering Unit after waits, although I still prefer to set a local variable to it just because I think triggering unit would be an unnecessary function call to make more than once. It's Last Created Unit and such that obviously aren't safe after waits. I would call it broken if things were otherwise than this.

Edit: I just tried similar with chat event. Any player enter chat string containing "Hamster "
I type "Hamster Boo" and then "Hamster Ball". 8.0 seconds later, I get my debug message with Entered Chat String saying "Hamster Boo", and shortly after "Hamster Ball" in the correct order and all. Seems to work aswell.

Edit: I don't mean to be after you or anything. It just bugs me a little bit to hear this I call a rumor. I tested because it wouldn't be the first time if I felt doubtless while being wrong.

Yes. If it's worth it, I recommend you make a new action definition to set the second variable, which automatically recalculates the first variable. "Set 'My Variable'" for instance.

In case you need to know, it's New -> New Action Definition. Within the new action definition, add a parameter of variable 2's type called "Value" or something. Still in the definition, add an action that sets variable 2 = 'the "Value" parameter' and add other action(s) to recalculate your first variable. When you add this action to a trigger, you fill in the value you want to set it to, and it automatically recalculates your first variable the way you defined.

Ofcourse, you don't have to do this procedure, but it would allow you to update variable 1 and set variable 2 in one simple step if you'd anyway use the same calculation every single time.

I've found this question around on the net, but no answers, about the function called Unit Attachment Point. You give it a unit and a string, the string being a reference to the attachment point, and it should return a world point. But only if you give it a string it accepts, which is the problem.

I used the previewer to find reference names, but those names didn't work (gave me trigger errors). So I tried various variations of the reference name. Trigger errors ftw. I also tried converting presets to strings, but no luck. Anyone able to give it the right strings?

I need it for several things, the current being a third person-controlled viking. When it leans left or right close to the terrain, I need this function to help me tell if one of its wings intersect the terrain.

Quote from SouLCarveRR: Go

Why are you trying to fix something that inst broken.... I pretty sure their square root function is probably as basic as you can get.

To answer that very short: I'm a crazy person.
What's basic depends on what level of precision you want. I imagine you could do with precision to 2 decimals. I kind of assumed their square root was more precision oriented than necessary for a physics engine. I'm also very sorry for making such a dry deal out of something this small and soaky.

Quote from SouLCarveRR: Go

heady stuff to me .... but looping to find the answer through all possible solutions doesn't sound like an optimal way to do it.....

Eh, all possible sollutions sounds a bit extreme. Notice it counts the number of times a previous value starting at 7 can be quadrupled before going past N. But I don't think it's very efficient the way it's done actually. Other methods I've seen did something to the mantissa in a double or floating point. Not possible in Galaxy.

EDIT: I hope keeping this thread will help others to not repeat the same mistakes as me.

Warning: Wall of Text, big science report:

I've compared the way masterxel said. Majority of commenters are right. No matter what optimizations I make, I can't get a custom function to be faster than native square root. I first tried the function as it's written in my first post. SC2's was 44% faster than that! In other words, top post function = slow. I then optimized it to take fixed n and return integer, consequently limiting to 1 function call (+ the function itself), and compared to SC2's Square Root (Integer) instead. SC2's counterpart was still 25% faster.

I tried a lookup table with no custom functions and no precision refinements. This inevitably requires a FixedToInt conversion as you can't lookup with a fixed point number. This seems to run slightly, just a teenie weenie bit faster than Square Root (Integer): Called 4 integer sqrts in Trigger A every 0.0 seconds, and looked up 4 square roots in Trigger B also every 0.0 seconds using same number to find sqrt of. The lookup trigger ran at about 8-9 ms, and square root trigger ran more stabilly at 9 ms. That potential tad of speed ofcourse comes at the cost of a really large array. It should be mentioned that I used FixedToInt conversion for native sqrt (integer) while you don't need to do that. So native sqrt (int) might still be faster if I'd left out the conversion. I didn't think about that when comparing.

Because I was curious, I made a lookup method for Cosine aswell. The speed of this was very similar to the speed of sqrt lookups. And the difference between a table Cosine and native Cosine was the same (i.e. lookup method proved just slightly, slightly faster). I think I remembered not to convert for both functions in this try, so this is more valid info. Try yourself if you want to know for sure.

Conclusion: If anything can work around for speed at all, go for extremely simple lookup table methods. They might win you up to 11% of native counterpart's speed at the very most. I could test everything more thoroughly over what I've allready done, if you want a bigger science report... lol, but I don't feel like it. It's neigh impossible to make speedier workarounds. I'm sorry for stating text walls of things you probably took for granted. Yeah, and don't call functions you don't absolutely need.

The sqrt tests, using 3 periodic triggers, actually caused my almost empty map a big fps drop in single player.

Quote from s3rius: Go

Speed only matters after the game starts losing fps. So unless you call A TON of Sqrts this is a viable alternative.

I was only planning on a few kilo, so it's viable. Though, no more viable than native sqrt. Hope you're all happy with my function for less accurate square roots. Use at your leisure, but don't call A TON ;)

Will look for a more useful waste of the 4th dimension time.

@Kueken531: Go

I don't know under which circumstances I should test or how to track a measurable difference. Can you suggest how I can speedtest this thing? I've tried to assign it a crapload of square root calls and then my function to compare. It's a micro-difference that I can't measure in fps. Testing in that way got silly :)
Makes me wonder if it's worth it, even if we suppose mine was an improvement.

It could be altered to not call anything, though using more multiplications and divisions, and maybe at least use a While loop (is that a function call?)
Finally, consider table lookups with all their issues. To use an array with a size that SC2 will allow, you still need to use one or more Babylon iterations to refine the lookup result. I don't like the lookup workaround, but just wanted to remind you that it's a possibility.

But you're right, we need conclusive tests before it matters what I try to sell you. I could use finding out aswell. Just don't know how.

The function below is not useful in any way. I hope that keeping this thread will warn others from commiting similar mistakes. Before trusting your own workarounds for efficiency, please think and test like I should have.

As I'm in the process of making a physics library and want to do certain trigonometry without too many expensive function calls, I fell for the idea of trying to make a faster square root function. Hopefully it's faster than regular square root. If not, then it was fun making this function anyway. Edit: This proves slower than standard Square Root

fixed gf_BlitzSquareRoot (fixed lp_n) {
    int lv_i;
    int lv_c;
    int lv_b;
    fixed lv_x;

    lv_i = 7;
    lv_c = 1; // counter
    lv_b = FixedToInt( lp_n );

    while( lv_i < lv_b );
        lv_i <<= 2;
        lv_c += 1;
    };
    lv_x = IntToFixed( lv_b >> lv_c );

    lv_x = 0.5 * ( lv_x + IntToFixed( 1 << lv_c ) ); //use this once only
    lv_x = 0.5 * ( lv_x + lp_n / MaxF( lv_x,1 ) );   //repeat N times for increasing precision

    return( lv_x );
}

Edit: Changed it so 1st iteration uses bitshift instead of division. It still needs that last step to gain decent accuracy, but you can remove the last step before return. Removing that will make it very inexact... but still, it'll have pretty much round number precision without it.

Edit: Accuracy Demo (Current)

I don't claim this is better than anything in particular. I've never tried this kind of thing before, and don't know if it's is an actual speed improvement over the normal function. Wish I could find out somehow.
The division is the most expensive part of the function I believe. You can copy the last line and repeat it depending on your needs for more precision and some unknown decrease in speed.
Please give feedback and use it for as much good as you can.