-Mappers should experiment with strict mapmods (maps that require a certain mod to be ran).
-Mods have incorporated plugins within them to alter StarCraft memory. There are regions of SCBW memory that are both readable and writable by both maps and mods, permitting two-way communication (and possibly rendering local memory available to global memory).
-Ignore large-scale issues of accessibility and portability because those issues are secondary to how GOOD a mapmod can be. (If mapmods are very good, then we will be able to recognize them as worth the time to create accessibility and portability solutions.)
---
2014-04-29
http://www.staredit.net/353383/ -- TECH DEMO HAS BEEN RELEASED! Based on my developmental project, VFSRST -- Download: http://www.mediafire.com/download/nlhnwf9ydmi6e25/VFSRST_dev_pack_3_2014-04-29.zip (MF)
Download (DLDB mirror): http://www.staredit.net/files/2955/
---
Table of Contents
tl;ldr
Introduction
Stage 1: Modding and Plugin-centric Accomplishments
Stage 2: Mapping Accomplishments
Stage 3: Mixing Problems and Solutions - A Case Study
Stage 4: Summary
Closing
---
Introduction
I have been thinking about the advancements in StarCraft memory mapping and its applications in maps and mods. I am a modder, not a mapper, and so I can only speak of modding's advancements. That I am no mapper is also a prompt for me to open this thread in this particular forum: the mapping community appears to be doing some very novel things as of late (some of which intersect with modding's capabilities, though this might be considered natural due to both mapping and modding converging on reading and altering StarCraft memory at runtime).
I want to open this thread to consolidate modding and mapping capabilities together in a way that might make creating experiences in StarCraft transcend both fields in order to create something unique, remarkable, or novel, or even subvert the laborious process of creating certain things with one technique alone by mixing them.
I would like to note that in this context, I define mapmod to be a map for which there exists a mod whose design is solely to enhance the aforementioned map. There are many other legitimate ways to define mapmod, but here, I will try to stick with the definition provided in order to focus the discussion in a UMS or campaign oriented manner.
Side Note
---
Stage 1: Modding and Plugin-centric Accomplishments
To begin, I would like to bring to attention two examples of modding accomplishments:
(A) http://www.staredit.net/353200/ - This post contains a video demonstrating high-quality music (!1) playing in a very dynamic manner (responding to combat) (!2).
(B) http://www.staredit.net/topic/15790/ - An article I wrote myself detailing exploiting sigorder or OrderSignal, a concept that, as pastelmind notes, is something not fully understood (to my knowledge).
Now, as far as I am aware, (A) bring up two subpoints of immediate interest to mappers: (1) about high-quality music (and sounds, and also arbitrary sizes when assuming pre-distribution of files), something often sought after by mappers, and (2) dynamic music which might be programmatically extremely difficult with mapping alone. Mapping's problems concerning sounds and music can be solved with modding, and from my own experiments with (1), even if in a fairly hackish manner.
Through (B), features such as poisoned standard attacks, area healing by a constant amount, making a Zealot jump into the air and striking a heavy blow as he lands, and casting multiple spells directly from a unit's command-card (without switching to a dropship to drop units or similar systems) are all possible. As I am not fully aware of mapping capabilities as of late, some of these effects might be replicated in mapping (but then ask how difficult it might be to implement such a feature in mapping alone?)
---
Stage 2: Mapping Accomplishments
I keep this short as I am not a mapper and I do not closely follow mapping. I will only briefly summarize my own findings -- assuming the reader is an experienced mapper, feel free to fill any blanks with your own insights and post them.
I see self-modifying triggers, a terrain tracer, and even a map replicating a circuit module. These are all extremely cool. With EPDs, I see that you can read a player's screen, unit HP, and so on. At this point, mapping and modding intersect because many of these EPD techniques and memory manipulation coincides with plugins and their capabilities to directly read and modify memory without having to go through the trigger system. (This or other basic modding could save string space -- another aspect that I know is important, although with the thread on extended strings, I am no longer so sure.)
I will go ahead and say that I have seen even more incredible things randomly, including the works of Korean mappers in drawing to the screen or minimap an anime picture in mapping. (Though the same note goes to modding as well -- they are very busy!)
---
Stage 3: Mixing Problems and Solutions - A Case Study
This chapter is a case study based on a personal anecdote.
About a year ago, I was working on a project for NudeRaider's (IIRC) contest in which the rules were set so that either maps or mods could be entered. I decided at that time to work on a mapmod and see how far I bend StarCraft to my will. Although I never finished it (but even now I wish I was working on it!), I had accomplished a few particular things relevant to the discussion.
Here are the key points of the case:
Unique spell-casting reminiscent of WC3 (or WoW or Dota or LoL) buttons + cooldowns. Take the Zealot: uniquely, it had a full command card of 9 buttons, 5 of which were new spells, and those that were active spells would "grey out" temporarily after being cast.
-Obviously, here, the main point is that the Zealot had spells that were represented and activated all through the standard StarCraft interface (to the extent that it requires no extra aspects to cast and coordinate spells - it was all "click spell" then "click target" or "click terrain" if necessary).
This was because the system required that each spell/button be available only when a certain unit (I had selected 4 power-up type units to represent cooldowns) was alive, otherwise the button would grey out (with the tooltip of "ability not learned/on cooldown").
-Here, the mixing of mapping and modding begins. The mod aspect is that the ability and its tooltip and so on are all integrated into SCBW itself, immediately readable and accessible. As well, the button itself was only available when an arbitrary unit was "built" (alive).
The Zealot itself would trigger plugin code through B, sigorder usage, and the mod would communicate to the map. The map would then kill and restore the corresponding cooldown-control powerup, making available again the spell button.
-Mapping and modding intersect; in the mod, the Zealot has been set to jump into the air and then land with a destructive slash (with graphic indicator and unique non-SCBW sound) on a target unit, forcing it to stop attacking for several seconds. At this point, the Zealot's animation tells the Zealot to flip a certain bit (binary bit, like the switch in triggers) in its sigorder field. The Zealot deals its special damage through StarCraft's standard weapon system.
-At this point, the plugin takes over: it finds that the Zealot has the certain bit set in its sigorder. It then modifies the Zealot's victim target so that the target's cooldown is set to a high, valid number, forcing it to stop attacking. It then sets the death counter of a certain unit for a player (let this unit be one that is reserved for this exact purpose).
-At last, the map takes over: the plugin had just set a death counter which is readily, easily accessible by the map. A map trigger reads that the death counter has been set to a particular value and kills the correct powerup, then begins counting a cooldown (in fact, this cooldown timer can be controlled/counted in either the map or the plugin -- I personally chose the plugin because I am familiar with coding in C++). When the cooldown is finished (and the cooldown can be just another death counter readable and modifiable by both map and mod), the map reads it and appropriately restores the correct powerup, restoring the Zealot's ability to use its jump attack spell.
The map could communicate to the mod when it wanted to play or stop music. I had 7 different 320kbps MP3s, of which all 7 could be played successfully.
-This is something I feel particularly good about showing the mapping community: as mentioned before, the death counters are accessible to both map and mod. Thus, I easily detected certain events in the map through triggers (such as the beginning of a boss battle) and set a reserved death counter.
-My plugin then read that death counter and then wrote into the mod's directory a blank "signal" file. In turn, I had written an external app that detects the presence of this "signal" file and consumed it before playing the appropriate music file, a 320 kbps MP3, via a C++ library I found on the net.
---
Stage 4: Summary
1) Maps and mods (particularly: plugins) can communicate with each other through mutually accessible memory locations. Some memory locations of interest off the top of my head: unit deaths (EUD and EPD!), minerals, vespene, even unit HP, shields, and energy...
2) If a map cannot perform a certain read or write easily, it can delegate the task to a plugin. The plugin can perform some complicated math or operation, including saving or loading data to the disk, exponents, complicated logic, and so on.
3) If a plugin (mod) cannot perform a certain task easily, it can delegate the task to the map. In particular, the map can easily cause victory or defeat, set the next map, create units, remove units, and probably more accurately keep time than a plugin can (a large basis of basic plugin techniques is the nextFrame() function, which naturally only can have accuracy up to 1/24 seconds, as opposed to the 1000+ Hz hyper triggers can run at IIRC).
2 & 3) In short: if a task is hard for the map, then use the plugin/mod. If a task is hard for the mod/plugin, use the map.
4) Mods, and particularly the plugin portion of a mod, can do /really/ funky things. I predict that it is entirely possible (and in some respect, trivial) to allow a Defiler to summon an Overlord -- an Overlord of Scourge that is! Such a Overlord could be the center of a pinwheel whose arms are made of Scourge that explode on contact with any enemies. (Imagine an addition sign, +, made of Scourges centered on an Overlord. The Scourges will rotate clockwise in a coordinated manner around the Overlord, i.e. + -> x -> +, and exploding on contact with units that are not owned by the Defiler's player.)
Indeed, due to the potential of plugins, entirely new interface elements can be introduced through internal StarCraft graphic libraries or even external graphic libraries.
---
Closing
As a matter of practical safety considerations, plugin code would /have/ to be open-source in order to be trusted. There is no telling what a malicious user could do with a plugin (delete system32? Write a keylogger onto the disk?). In this line of thought, any non-map elements (mod and plugin included) would have to be able to be reconstructable or compilable by an end-user to ensure safety, AFAIK.
(I personally wish to leave this matter aside though, as admin and community can deal with relevant policies. Please take away from this post the desire to mix mapping and modding, and not necessarily for play by others.)
I will try to follow this topic for as long as possible and answer as many modding-related questions as I can. I hope that the accomplishments above can spur any ideas.
Post has been edited 6 time(s), last time on Apr 30 2014, 3:41 am by Sand Wraith.