tl;dr

-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.



---

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:


-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).



-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).



-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.



-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.

I'll say up front that I didn't read your post in detail, but when it comes to maps vs mods, to me, it seems to come down to a few core issues.

First off is the precise definition of a mod. I personally don't have the experience or knowledge of what seemed to have taken place with what's generally known "SC Modding".
The way I see it, "mapping" is nothing more than producing an .scx/.scm file that can be played/distributed on battle.net, and "modding" is everything and anything else that modifies the files that came with the original SC:BW disc.

Mapping of course is limited by how its handled by StarCraft, but obviously is much more accessible. Modding in my definition has no limit because you're modifying StarCraft itself, but would then be less accessible because of deployment/security issues.

So in my view the amalgamation of "maps" and "mods" as if they were originally mutually exclusive entities seems kind of noninsighted. Maps are predicated on StarCraft, or whatever mod of it, in the first place.

What EUDs/EPDs do is beyond what's normally considered possible with maps, and because they meddle with internal RAM, all the topics associated with it are really nothing more than a subset of the topics about the SC engine itself.

EPDs/EPDs vs Mods would then simply be two ways of the same action of modifying StarCraft, each with their own pros/cons.

So, it does not make sense to me to make a mod that "solely" enhances the map. If you want something playable by vanilla SC, make a map. If you want to extend StarCraft, make a mod. Maps made with that mod would simply be maps designed for that mod.

I'm not refuting that there can be a lot of discussion regarding how maps can "interact" with a modification of SC, I'm just saying that it seems to me to be a purely "mod" thing rather than something that would seep into a vanilla SC UMS "map" realm.

Agreed. Mixing modding with mapping can lead to another JASS.

Maybe we can seperate modded mappings and stock mappings.
- Stock mappings : Do fucky things with extreme stock tricks. Mapping is more fun, but it's hard to express my thought. Creating integer division algorithm with Deaths/SetDeaths?
- Modded mappings : Can express your thought more easily, but will lose your map's portability.

Example)
You can manipulate location's coordinate very easily with modding. But to do that with stock mapping, you have to create mobile grid and use some precalculated table to precisely create & remove units to get the 'right' spot. Annoying, really. You even cannot create mobile grid in a map with hundreds of bullets flying around.

P.S) Since I'm EUD enthusiast, I'd like to ask if EUD is considered modding here.
P.S 2) Circut map is pure stock.

Post has been edited 2 time(s), last time on Apr 26 2014, 4:56 pm by trgk.

There have been attempts at mixing mapping and modding, such as SCMLoader which allows you to use modded files inside the scm itself. Other than a few things to play with it, nobody ever really seemed to use it (even those aware of it). The biggest hurdle I see is convincing people to use it, even if they do trust the software. There would have to be enough quality maps already made that would require such a plugin for them to want to run the plugin or have it at the ready. Otherwise, it's easier just to not use it and ignore it.

Although I am reminded of a Korean plugin I sometimes hear about ... So it's not absolutely impossible.

In which case "modded mapping" is just "modding". I agree with Yoonkwun, "mapping" is defined by its accessibility. Anything that requires mods is no longer relevant to mapping.

But that's fine if this conversation is being approached as "modders discussing new modding ideas". Although it seems more accurate to call it "map-specific modding" or something.

okay, really, I didn't expect this thread to still veer in this direction. I don't care about these silly pedantic issues.

I am solely concerned with what new experiences can be generated by using {whatever you decide is mapping} and {whatever you decide is modding} together. That is, if you ever had an idea that you decided was too difficult or impossible to accomplish through stock SCMDraft, triggers, and EUD calculators (and whatever other tools you are already familiar with and regard as mapping tools), then I merely present extra tools that might traditionally be called modding tools.

@yoonkwun: Okay, but I don't /care/ about any of that. In fact, can we just let that issue of "seeping into vanilla SC realm" die? It hurts this thread.

@Farty: SCMLoader was a failure because it wanted to constrain itself to respect random accessibility. I want to entirely disregard accessibility to focus purely on what new experiences can be made.

@Azrael: None of that matters because I want to focus the technical capabilities that both fields provide when combined.

Can we please move the discussion to things that are not typically possible or practical in mapping instead of getting caught up in these other side-issues that entirely depend on the potential worth of combining techniques together (which is exactly what I am trying to discuss)?

I'm not trying to talk this down or anything, I'm absolutely for anything that mixes modding and mapping. I love the concept and the possibilites, which is why I love EUDs and modding and stuff so much in the first place.

Also I still have all the TrigPlug stuff. xD


Post has been edited 1 time(s), last time on Apr 26 2014, 7:44 pm by FaRTy1billion.

@Farty: Would you mind uploading that somewhere (into the DLDB or something)? It is a pretty important thing, although I am no longer sure if it is still necessary.

---

@public:

I want to make sure I am clear in what I am talking about, since it seems to be such a confusing issue.

I define mapping as: creating *.scm and *.scx files. Mapping techniques involve anything that can be doable with SCMDraft 2 and creating such SCM and SCX files. This /accurately/ defines mapping.

I define modding as: anything that involves DatEdit, FireGraft, TBLPad, PyMS, etc... that changes StarCraft's base files on a global scale, and creating *.mpq or *.exe files that can be loaded (by MPQDraft, etc.) or ran (directly double-clicked), respectively.

A mapmod is then: a SCM or SCX that is meant to be run while a mod is loaded.
We can subdivide mapmods into two categories: strict mapmods and loose mapmods.

A strict mapmod: an SCM or SCX that simply does not function as intended at all without its corresponding mod loaded. That is, the map without the mod is unplayable. Multiplayer strict mapmods would require all participating players to load the corresponding mod, else a desynchronization will be sure to occur.

A loose mapmod: an SCM or SCX that functions as intended without its corresponding mod loaded, but might be underwhelming in terms of aesthetics and so on. That is, the map without the mod is playable. In fact, multiplayer loose mapmods would entail only local changes that do not interfere with synchronization.



---

I want to make it clear that the invention of an accessible way to play strict mapmods without having to restart SCBW depends /entirely/ on the quality of strict mapmods. I created this topic to discuss what possibilities there are in strict mapmods because they have the potential to be far better experiences than "maps that are not mapmods", and hence would prompt the creation of such an invention.

That is why it is so necessary to discuss specifically what can be done with strict mapmods while ignoring all other issues (safety included, because mods have been around for a long time, and there are currently no strict mapmods or even loose mapmods floating around). Pedantics must also be put aside for the time being for the sake of experimentation.

---

EDIT:

TL;DR


Post has been edited 1 time(s), last time on Apr 26 2014, 8:42 pm by Sand Wraith.

I can, but the issue is there is no easy way to view/edit the triggers. poiuy was working on a trigger editor that supported them, but I'm not sure if it was ever complete.

"@yoonkwun: Okay, but I don't /care/ about any of that. In fact, can we just let that issue of "seeping into vanilla SC realm" die? It hurts this thread."

Like I said I've got no problem with that, just don't see why it's in the forum "SC1 UMS Theory and Ideas" where 99%+ of the topics are about vanilla SC UMS.

cuz I don't know much about mapping, neither do most modders anyway. Also, modding forums are pretty dead. Most importantly, I need to present this to people who can map convincingly so I can get an accurate idea of what mapmods can become when great modding and great mapping come together.

I'm working on Birdie's server and I'm trying to exploit the potentials of server-side code to modify memory and such without requiring the user to download anything onto his/her computer. If I can get my hands on SCMLoader's source code or if someone wants to remake that, I can try to put it in before the server's release. I'm sure that this would definitely help the popularity of mapmods since no one would have to download anything special since the mod is in the map file.

I am now publicly releasing a developmental version of VFSRST, my mapmod project, as a technical demonstration.

Download from MF: http://www.mediafire.com/download/nlhnwf9ydmi6e25/VFSRST_dev_pack_3_2014-04-29.zip

(EDIT: DLDB mirror http://www.staredit.net/files/2955/ )

PLEASE READ THE "readme.txt" FILE.

This version of the mod is suitable for SCBW v1.16.1. Feel free to compile the mod's data yourself -- in fact, I have included nearly all files (excepting those files that I trimmed that are not absolutely necessary to minimize archive size) I think are relevant to the project, including compilation notes for the mod, play-testing notes, source code for plugins and iscript files, some development files, and more!

I may produce a video showcasing VFSRST if I have more time.

Please feel free to look through the plugin (particularly game.h and those files in the VFSRST folder), the iscript, and the map. They are the most interesting aspects as all three sides (standard modding, plugin code, and mapping) intersect to create effects.

Post has been edited 1 time(s), last time on Apr 30 2014, 3:40 am by Sand Wraith.

PyMS's trigger editor (PyTRG) has supported TrigPlug for a looong time.

Okay, thanks. I will look into it when I can.