Campaign Creations

Every time Mesk complains about some arbitrary limit, I wonder how filthy rich he is that his computer could run 3 instances of Starcraft 2 at the same time.

WB wrote:

IskatuMesk wrote: Mundane, arbitrary limits are the bane of men.

Ever think that it just appears arbitrary to you because you don't know the reasoning behind it?

No, I know the reasoning. There's reasoning behind limits like the sprite limits in sc1 but not in things like this.

Every time Mesk complains about some arbitrary limit, I wonder how filthy rich he is that his computer could run 3 instances of Starcraft 2 at the same time.

Starcraft 2 is not a demanding game.

I think the operation limit is to prevent infinite loops from freezing the game and forcing it to quit (not like there aren't plenty of other ways for badly-scripted triggers to do that). I don't know if the actual number of the limit is restricted by the game's integer size limit.

And yes, coders don't like this hard limit either.

There is an easy way to freeze the game - an infinite loop spawning something big or a ton of particles. There is no way to stop malicious users from locking a game. Hell, right now I know of a way to crash any game I join for everyone in it. Arbitrary limits won't stop that.

How are you crashing the game?

RazorclawX wrote: Every time Mesk complains about some arbitrary limit, I wonder how filthy rich he is that his computer could run 3 instances of Starcraft 2 at the same time.

I laughed.

RazorclawX wrote: Every time Mesk complains about some arbitrary limit, I wonder how filthy rich he is that his computer could run 3 instances of Starcraft 2 at the same time.

It's actually the super computer that runs all electronic activity in British Columbia believe it or not. That's why we aren't as hick and Canadian as every other province, with the sole exception of Toronto but that's a city.

Okay, so the thing that I was working on last night... I pretty much got it to work the way I want it to. 

Almost.

I have a unit, and I can make it float in an arc independent of the map terrain.  (If it jumps on terrain that it sloped upward, it does not magically make it jump higher)  That much I am very happy with.  HOWEVER, when this floating unit passes over the edge of a cliff, if will ALWAYS flail spastically.  I imagine this is because the height of the terrain is changing too quickly for the trigger to fliudly change the unit height. 

Now, I noticed that for air units, the slope up a cliff is much smoother.  But like I said earlier, it makes the unit lift off the ground as it gets closer, when I don't want it to float.  Maybe I will have to do some crazy workaround where I change the unit to flying if I detect that it's going over a cliff edge...

THAT JUST MIGHT WORK

EDIT:  Okay, how do I use the Catalog Field Value Set action?  Or is there another way to change a unit's Mover value?

For the Catalog Field Value Set action ...

Basic explanations : http://www.campaigncreations.org/forum/http://www.campaigncreations.org/phpBB3/viewtopic.php?p=37642#p37642
Extra explanations for array parts : http://www.campaigncreations.org/forum/http://www.campaigncreations.org/phpBB3/viewtopic.php?p=38511#p38511

They got screenshot and map examples. All in this very same thread. :p

Something that is a bit ridiculous yet probably time-saving for quite a few that doesn't know how to duplicate a SC2 unit with minimal hassle.

Basically, when you duplicate a unit, duplicate ONLY its actor when you are prompted to duplicate a unit's references. A duplicated actor will carry over its model, sounds and other references without having a duplicate of those to have a unit with the same model and such.

Also as of Patch 13, duplicating that way will also carry over the unit's research references (and possibly one or two more references that didn't carry over before).

Probably should have posted it earlier.

Do we have confirmation that content filters have been removed from map publishing?

Master Jademus Sreg wrote: Do we have confirmation that content filters have been removed from map publishing?

From Blizzard, I didn't really check about it to be honest for any recent news.

Details I do remember :
1) I do remember that words that can be considered censored according to the in-game filter (as in the one you can turn on/off in your SC2 options) might be censored in a #$!$ fashion on some map's text.

2) Blizzard did remove some previously censored words out of their censor list.

To try to give you some answers (since I am aware for you that it is the most important point), I decided to make some concrete tests with the word "God" and "Shit" for censor tests. I only modify a specific part of the map and I attempt to publish it at this moment.

Censored for :
Map's Name (error :  "unacceptable word : god")
Map's Extended description (no error but give me an error without any info that I cannot publish)

Not Censored for :
Map's Author
Map's Basic description
Map's Loading Screen (any of the aspects)
Map's Triggered Shown messages (direct string)
Map's Modified Unit-type (modified Baneling's unit name for this case)
Map's Buttons (both direct name and tooltip)
Map's Weapon Name

The above tests also include the SC2 Mature Filter at ON to see if they become ##!@#$ and they didn't.

I didn't test other things but honestly, it seems to be only the map's name and map's description. While in theory Blizzard could extend the publishing censoring to the aspects they don't currently check, I don't see much point since there is the mature filter that could do the job.

Personally, unless Blizzard extends their publishing censoring on the aspects they don't, the censoring is probably mostly minor and just to avoid seeing theoretically bad descriptions on the map names when you choose a map over b.net (like a screenshot "proof" that gives them a bad reputation for battle.net itself due to that or something ridiculous like that).

Since it doesn't censor trigger text, it imply you don't have to worry that you have to modify your story just to pass the censor after all. Same for units/abilities/etc 's names.

Thus, unless you are truly a hardcore believer about anti-censoring stuff, it's something that you probably could tolerate since you pretty much just need to ensure two things (map's name + extended description) pass the filter.

EDIT : Forgot the screenshots

Based on your findings, I find this reasonable.

So an important part of discovery I found is something to allow many more variables-like data without hitting the dreaded trigger limit.

It's data tables. Global data tables to be specific (didn't poke local ones since I am not sure of the difference). Yep, they don't go against the trigger limit and doesn't seem to cause any real issue as far my tests were done. On top of it, they work in multiplayer too (tested with Mr. (aka BilltheEmu)).

So with a safe 65*65*65 3D array (without any real script), you could get 274625 Integers in your map.

With a data table, I did reach 700000 integers before slowing down. I did let it reach 3,000,000 integers despite the considerable slowdowns (due to my every 0.01 sec event trigger + loops of 1000 of data writing in it).

IMPORTANT NOTE : While I had no problems writing directly into the data table, I had problems when it came to show up the value directly. For example, an Integer off data table converted into a String shows nothing instead of the value. The safe way seems to put the data table's value into a variable and then use said variable's value after.

You can erase a data value's name field so I guess it might be important to do to avoid slowdowns if you use data tables in a large scale situation.

Note I only tested with Integers so I don't know if there are odd issues with other types of variables or even a mix of them into the data table.

Below are my test maps about it. Note that during my multiplayer test with Bill on the first test map, I was auto-dropped at phase 4 (more or less loops thought 270000 integers before it happened)