Staredit Network > Forums > SC1 UMS Mapmaking Assistance > Topic: Calling all EUD experts for the cause!
Calling all EUD experts for the cause!
May 17 2017, 3:50 pm
By: Sato  

May 17 2017, 3:50 pm Sato Post #1



Hey guys, after enough whining on the forums, the Classic Games team at Blizzard are now considering some form of baked-in EUD support or other application for them, as far as UMS games go.

Pete Stilwell (Senior Producer of Classic Games) got in touch with me to discuss the issue, but unfortunately I am not knowledgeable about EUDs in-depth.

If you know a ton about EUDs (specifically people like Roy or Farty1Billion) PM me for the email address please :)

Post has been edited 1 time(s), last time on May 18 2017, 5:14 am by FaRTy1billion. Reason: Probably shouldn't be posting people's email addresses publicly



None.

May 18 2017, 1:09 am LoveLess Post #2

Let me show you how to hump without making love.

Can you link us to something about this on the blizzard forums? All of our knowledge and feedback up until now has been in ignorance of UMS in general.



None.

May 18 2017, 2:25 am Veta Post #3



Is there any consensus we can come to before messaging Pete & Co?



None.

May 18 2017, 3:27 am Cinolt Post #4



First off, EUD's should not be considered a "feature". EUD's are and have been a "bug". It makes little sense for a game developer to intentionally introduce an exploitable bug.

"EUD" is an appealing thing only for mapmakers who enjoy studying (closed-source) machine code to devise features that are normally not possible.

So, the most sensible alternative is to just natively include support for desired map features available to the mapmaker, in which case any mention of "EUD" becomes moot and would just become feature requests.

The down-side of enabling EUD Actions is the same downside as letting the players run random .exe's every time they play a new map.



None.

May 18 2017, 4:21 am theskinsurf Post #5



there are so many other things I'd like them to implement in terms of actual features rather than EUDs...



Current project: Star Rogue
Other projects: Triumvirate Defense, Skirmish Islands

May 18 2017, 5:40 am NudeRaider Post #6

We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch

Quote from theskinsurf
there are so many other things I'd like them to implement in terms of actual features rather than EUDs...
Ya, especially some EUDs we don't do what we really want. For example health detection and then setting hp to a % based on that is cool and all, when all we really want is add or subtract HP.




May 18 2017, 7:32 am rockz Post #7

ᴄʜᴇᴇsᴇ ɪᴛ!

Quote from NudeRaider
Quote from theskinsurf
there are so many other things I'd like them to implement in terms of actual features rather than EUDs...
Ya, especially some EUDs we don't do what we really want. For example health detection and then setting hp to a % based on that is cool and all, when all we really want is add or subtract HP.

While we'd like to add/subtract HP, health detection is plausible as well. For example in Temple Siege, mech has 3 different units (weapons) it can use. If you use health detection, you can ensure that the health is mostly identical between the 3 units, much like I did with my first EUD map. Being able to set HP in 1-4 bytes would also be fantastic, and would mean that we could actually do this.

Being able to detect cooldowns with "bring" or something would allow us to detect attacks and create ammo systems.

Being able to determine XY coordinates of a unit is useful. For example if you preplace a unit/building and right click on it, the unit's move target is always the same, allowing you to run a move trigger to enter the building. It would be even nicer if we could detect single bytes and change them rather than detect groups of 4 bytes.

Showing leaderboard for kills of extended units to show deaths would be extremely useful, and replaces custom score almost entirely.

Being able to modify the kill score of units or modify the kills of units while in game would be phenomenal for the kills2cash systems developed.

Being able to create all units including doodads, and ensuring that all units can be cloaked via triggers, and made to be stackable via triggers, and unit sprites being able to be created would be awesome.

Being able to add research/upgrades via triggers would prevent the pointless upgrading people have to do, and would allow computers to become more tough without requiring a second computer.



"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"

May 18 2017, 12:14 pm jjf28 Post #8

Cartography Artisan

To replicate the gist of what we did with EUDS I think 2 actions would suffice...

"Copy Entity Value" - Copies some value into a death counter
     - Entity Group: Unit, Location, ..., Misc
     - Entity ID: UnitID, LocationID, ...
     - Entity Value: Unit Hitpoints, Unit Shields, ..., Location x1, Location x2, ..., Cursor X, Cursor Y
     - Death Counter Unit: Cantina, Cave, ...
     - Death Counter Player: Player 1, Player 2, ..., Player 12

"Set Entity Value" - Sets some value to a death counter
     - Entity Group: Unit, Location, ..., Misc
     - Entity ID: UnitID, LocationID, ...
     - Entity Value: Unit Hitpoints, Unit Shields, ..., Location x1, Location x2, ..., Cursor X, Cursor Y
     - Death Counter Unit: Cantina, Cave, ...
     - Death Counter Player: Player 1, Player 2, ..., Player 12

- Also touch up death counters at the same time so we can set p9-p12.

- This doesn't allow us to create or remove entities (e.g. units, sprites) on the fly or load our own graphics as some people did with EUDs, maybe we could draft a few actions for those too.

With this design Blizzard's work is fairly minimal and we get, on some levels, more power than we had with EUDs.

Post has been edited 1 time(s), last time on May 18 2017, 12:28 pm by jjf28.



Rs_yes-im4real - Clan Aura - jjf28.net84.net

Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

May 18 2017, 1:36 pm FoxWolf1 Post #9



Quote from jjf28
To replicate the gist of what we did with EUDS I think 2 actions would suffice...

"Copy Entity Value" - Copies some value into a death counter
     - Entity Group: Unit, Location, ..., Misc
     - Entity ID: UnitID, LocationID, ...
     - Entity Value: Unit Hitpoints, Unit Shields, ..., Location x1, Location x2, ..., Cursor X, Cursor Y
     - Death Counter Unit: Cantina, Cave, ...
     - Death Counter Player: Player 1, Player 2, ..., Player 12

"Set Entity Value" - Sets some value to a death counter
     - Entity Group: Unit, Location, ..., Misc
     - Entity ID: UnitID, LocationID, ...
     - Entity Value: Unit Hitpoints, Unit Shields, ..., Location x1, Location x2, ..., Cursor X, Cursor Y
     - Death Counter Unit: Cantina, Cave, ...
     - Death Counter Player: Player 1, Player 2, ..., Player 12

- Also touch up death counters at the same time so we can set p9-p12.

- This doesn't allow us to create or remove entities (e.g. units, sprites) on the fly or load our own graphics as some people did with EUDs, maybe we could draft a few actions for those too.

With this design Blizzard's work is fairly minimal and we get, on some levels, more power than we had with EUDs.

The EUD condition I used most was keypress detection, which wouldn't really fit into that model. Second-most was selection detection; not sure where that would fit in, either. I made some use of chat-string detection as well, but I'd be fine living without that one, since it was a pain in the ass, and the main thing I used it for (secret AH systems, yay) isn't needed anymore. EDIT: Also, mouse position was a pretty neat one, even if just for cosmetic effects, like having text highlight on mouseover.

On the "set" side of things, what I miss most is probably the Unit 1049 system for directly moving a location. Flat-out better than any other grid system in all regards: precision, reliability/flexibility, and ease of use.

Post has been edited 3 time(s), last time on May 18 2017, 1:43 pm by FoxWolf1.



None.

May 18 2017, 2:55 pm Doodle77 Post #10



EUDs which only read the game data struct (whatever is hashed and compared between players to detect desyncs) are safe. They can be accommodated while removing the buffer overflow with something like this:

Code
bool __fastcall Deaths(const ConditionData* d) {
   uint32_t deaths;
   
   // make sure d->player/unit are unsigned
   if (d->player >= PLAYER_COUNT || d->unit >= UNIT_TYPE_COUNT) {
       uint32_t offset = offsetof(gameData, unitCounts)
           + (d->player * UNIT_TYPE_COUNT + d->unit)
               * sizeof(gameData.unitCounts[0][0]);
       if (offset > sizeof(gameData)) {
           return false;
       } else {
           deaths = *reinterpret_cast<uint32_t*>((void*)gameData + offset);
       }
   } else {
       deaths = gameData.unitCounts[d->unit][d->player]
   }
   
   //should be the same from here
   
   switch (d->comparison) {
       case COMPARISION_EXACTLY:
           return deaths == d->value;
       case COMPARISION_ATLEAST:
           return deaths >= d->value;
       case COMPARISION_ATMOST:
           return deaths <= d->value;
   }
}


Something similar for Set Deaths would introduce a lot of attack surface, unfortunately, since so much of SC is missing bounds checks.

Here's a list of things that would be nice:
Set vision
Set unit availability
Set hotkeys
Set player color
Set supplies
Set upgrade/tech level/available
Set pauses? (hey why not)
Set location bounds (top/left/bottom/right)

Disable command buttons
Set unit health/shields/energy
Set unit status (dmatrix, stim, ensnare, lockdown, irradiate, stasis, plague, parasite, blind, maelstrom, acid spores)

Post has been edited 2 time(s), last time on May 18 2017, 3:54 pm by Doodle77.



None.

May 18 2017, 4:32 pm Pauper Post #11



I don't know much about EUD but I think a great addition would be an option to detect unit health. There has been SO many cases were detecting user health would of made a map amazing.




May 18 2017, 4:48 pm CecilSunkure Post #12



Health detection, health addition/subtraction, player name detection (string comparisons), keystroke detection (this would have synchronization problems, but still, it's needed), selection detection (condition for what units are selected). These kinds of conditions are very benign and can be introduced without security risks.

The problem with a lot of the EUD conditions were that they hard-code unit IDs, which seem to be assigned at unit creation time. This is a common problem with many trigger-like systems; mapping triggers to in-game units is fairly hard to do technically speaking, and is actually a serialization problem. However, it would still be great to have these kinds of conditions nonetheless! Players can work around unit-ID limitations manually.



None.

May 18 2017, 5:46 pm rockz Post #13

ᴄʜᴇᴇsᴇ ɪᴛ!

If we can detect unitID with bring, it would solve a lot of issues.



"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"

May 18 2017, 6:20 pm CecilSunkure Post #14



Exactly. Players can spawn a unit at a known location, read the unit-ID with a condition, and store it in a death counter. That would be a good workaround.



None.

May 18 2017, 10:39 pm Suicidal Insanity Post #15

I see you !

The unitID that staredit writes is basically they unit's this pointer.

Oh and we should just get a large amount of variables instead of abusing the death counters. Then have triggers to do basic math on em and fill em from map data (e.g. location properties, unit properties) or update map data using them.

Post has been edited 1 time(s), last time on May 18 2017, 10:45 pm by Suicidal Insanity.




May 19 2017, 12:05 am jjf28 Post #16

Cartography Artisan

Quote from FoxWolf1
Quote from jjf28
To replicate the gist of what we did with EUDS I think 2 actions would suffice...

"Copy Entity Value" - Copies some value into a death counter
     - Entity Group: Unit, Location, ..., Misc
     - Entity ID: UnitID, LocationID, ...
     - Entity Value: Unit Hitpoints, Unit Shields, ..., Location x1, Location x2, ..., Cursor X, Cursor Y
     - Death Counter Unit: Cantina, Cave, ...
     - Death Counter Player: Player 1, Player 2, ..., Player 12

"Set Entity Value" - Sets some value to a death counter
     - Entity Group: Unit, Location, ..., Misc
     - Entity ID: UnitID, LocationID, ...
     - Entity Value: Unit Hitpoints, Unit Shields, ..., Location x1, Location x2, ..., Cursor X, Cursor Y
     - Death Counter Unit: Cantina, Cave, ...
     - Death Counter Player: Player 1, Player 2, ..., Player 12

- Also touch up death counters at the same time so we can set p9-p12.

- This doesn't allow us to create or remove entities (e.g. units, sprites) on the fly or load our own graphics as some people did with EUDs, maybe we could draft a few actions for those too.

With this design Blizzard's work is fairly minimal and we get, on some levels, more power than we had with EUDs.

The EUD condition I used most was keypress detection, which wouldn't really fit into that model. Second-most was selection detection; not sure where that would fit in, either. I made some use of chat-string detection as well, but I'd be fine living without that one, since it was a pain in the ass, and the main thing I used it for (secret AH systems, yay) isn't needed anymore. EDIT: Also, mouse position was a pretty neat one, even if just for cosmetic effects, like having text highlight on mouseover.

On the "set" side of things, what I miss most is probably the Unit 1049 system for directly moving a location. Flat-out better than any other grid system in all regards: precision, reliability/flexibility, and ease of use.

Entity Group: Keyboard
Entity Value: Key Down
Entity ID: ASCII Key Code

Entity Group: Selection
Entity Value: Player 1 Selections, Player 2 Selections, ...
Entity ID: Selection Index

The design goals were:
- Easy to implement (they need only add 2 actions and put the rest of the work on us (much like EUDs))
- Easy to control (they can have a static array with the lower and upper bounds for every group/value/id combo)
- Flexible enough to cover all EUD conditions and all trivial actions

I agree if we can get some form of real-variables we should, but we can do death counter math just fine, so I don't consider it a priority.



Rs_yes-im4real - Clan Aura - jjf28.net84.net

Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

May 19 2017, 12:53 am Suicidal Insanity Post #17

I see you !

Your design would mean it would be really easy to implement in the editor, but it wouldn't save any effort on the game/engine side of things and would make it difficult to use.




May 19 2017, 2:04 am jjf28 Post #18

Cartography Artisan

I disagree, all the game/engine side programming would be trivial with this design. You just setup the table with all the bounds checking/data sizes and a pointer to a function that get the pointer to the affected item, 1 entry for each item you want to make editable.

| EntityGroup | EntityValue | EntityIDMin | EntityIDMax | MemorySize(1-4 bytes) | &RetrievalFunction | RetrivalParam |
{"Unit", "Hitpoints", 0, 1699, 4, &getUnitField, UnitField.HITPOINTS}
{"Unit", "Shields", 0, 1699, 4, &getUnitField, UnitField.SHILEDS}
{"Location", "xc1", 0, 65536, 2, &getLocationEdge, LocationEdge.LEFT}
...

Have that table parsed into a map of groups to entity values to the rest of the struct. Then create all the retrieval functions you need...
Map<EntityGroup, Map<EntityValue, EntityStruct>> entityDat;


void* getUnitField(EntityStruct &entityStruct) {
    switch ( entityStruct.retrievalParam ) {
        case UnitField.HITPOINTS: return &scData.units[entityStruct.entityId].hitpoints;
        case UnitField.SHILEDS: return &scData.units[entityStruct.entityId].shields;
        ...
    }
}

void* getLocationEdge(u32 entityValue, u32 entityId, u32 retrievalParam) {
    switch ( retrievalParam ) {
        case LocationEdge.LEFT: return &scData.locations[entityId].left;
        ...
    }
}

...

copyEntityValue(TrigStruct& trig) {
    u32 entityGroup = trig.Number;
    u32 entityValue = trig.Player;
    u32 entityId = trig.Location;

    EntityStruct& entityStruct = entityDat.entityGroup.entityValue;
    u32* dcPointer = getDcPointer(unit, player);

    if ( entityId >= entityIdMin && entityId <= entityIdMax ) {
        void* entityPointer = entityStruct.retrievalFunction(entityStruct);
        switch ( memorySize ) {
            case 1: *dcPointer = *((u8*)entityPointer); break;
            case 2: *dcPointer = *((u16*)entityPointer); break;
            case 4: *dcPointer = *((u32*)entityPointer); break;
        }
    }
}

setEntityValue(TrigStruct& trig) {
    u32 entityGroup = trig.Number;
    u32 entityValue = trig.Player;
    u32 entityId = trig.Location;

    EntityStruct& entityStruct = entityDat.entityGroup.entityValue;
    u32* dcPointer = getDcPointer(unit, player);

    if ( entityId >= entityIdMin && entityId <= entityIdMax ) {
        void* entityPointer = entityStruct.retrievalFunction(entityStruct);
        switch ( memorySize ) {
            case 1: *((u8*)entityPointer) = *dcPointer; break;
            case 2: *((u16*)entityPointer) = *dcPointer; break;
            case 4: *((u32*)entityPointer) = *dcPointer; break;
        }
    }
}

EzPz



Rs_yes-im4real - Clan Aura - jjf28.net84.net

Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

May 19 2017, 2:05 am Roy Post #19

An artist's depiction of an Extended Unit Death

Hey, I'm a bit late on this topic, but I agree with the general consensus: we don't necessarily want EUDs, but we want many of the things they allowed us to do. Going off of the prioritized and requested features from EUDGen2, there are quite a few things that are in high demand.

Units

By far the most requested feature is to be able to read properties on specific units. Now, with EUDs we were limited to referencing units by their index ID (i.e., the pointer to the unit struct in the unit array), which had pros (such as easily being able to keep track of that unit's state) and cons (such as obtaining the ID in the first place, or locating the unit's position on the map for the purposes of interacting with that area). While not ideal, it would be relatively low effort to allow us to reference units by index ID for the purposes of checking things like:

  • Get/Set/Add/Subtract Current/Max HP
  • Get/Set/Add/Subtract Current/Max Energy
  • Get/Set/Add/Subtract Current/Max Shields
  • Get/Set/Add/Subtract Current Kill Count
  • Get/Set/Add/Subtract Unit Movement (Flingy) Speed
  • Get Current Facing Direction
  • Get Current Order (stop, move, attack, etc.)
  • Get Current X/Y Coordinates

These, among other properties, were all accessible with EUDs as long as you knew the index ID. Going beyond this, the X/Y coordinates of the unit can be useful, but it would be useful to extend this to check if a specific unit is within the bounds of a location (in the existing system, we can only be as specific as the type and player owner of a unit, so two Terran Marines owned by Player 1 are indistinguishable from each other).

While having these options available to us is great, working with the index ID is not exactly ideal. What would be ideal is the solution found in the likes of Warcraft III's trigger editor (and also StarCraft 2's trigger editor): variables. Being able to create and assign variables for units would solve the complexity of the index ID issue. Assignment could be as simple as "Set <variable> to <unit type> owned by <player> at <location>", and, like many other triggers that exist today, just take the first matching unit if available.

However, adding variables is likely a significant overhaul of SC's current trigger system, so I understand the likelihood of this is slim. A less ideal but practical solution is better than the ideal, impractical one. Perhaps a happy medium would be to resolve the unit target the way SC does with its other conditions and actions like "Set Doodad State": specify a location, unit type, and player owner, and take the first matching unit.

One last remark on this section: while it never performed correctly with EUDs, more unit order options, like telling units to use an ability such as Burrow, would be a very beneficial addition, if it would be easy to implement.

Upgrades and Technologies

Currently there are no ways to check the upgrades or technologies a player has, nor can we change these via triggers. EUDs made this possible, and it was really as simple as looking at the corresponding location in memory and reading the value. However, since EUDs worked by reading 4 bytes at a time, and upgrades/technologies are stored in single bytes, there were challenges getting precise values for every 3 out of 4 entries. I see no reason why this would be challenging to add as native conditions/actions, and it will open up more possibilities than what we had prior.

Player Information

We're missing a small handful of things regarding players. With EUDs, we were able to do things such as:

  • Get/Set/Add/Subtract Used/Max Terran Supply
  • Get/Set/Add/Subtract Used/Max Zerg Supply
  • Get/Set/Add/Subtract Used/Max Protoss Supply
  • Get Current Unit Selection
  • Get Player Name

Particularly knowing which units a player has selected created a whole assortment of new mapping techniques. This again relied on unit index IDs, in addition to needing to check which "slot id" (position out of 12 possible selected units) the unit was put under, but despite this specificity, many cool things came out of this option being available. Having a native implementation in some form would be fantastic.

Miscellaneous

Since EUDs are just reading from a wide range of memory, it's hard to list out everything that was available to us. Picking out a few key items:

  • Get/Set/Add/Subtract Current Game Speed
  • Get/Set Current Game Latency*
  • Set Current Gamma*
  • Get Key Press Detection*
  • Get Display Text Detection*

Many games are built under the expectation of running under a specific game speed (usually Fastest), and wouldn't operate correctly under other speeds (because Wait actions run in real time). Being able to check for game speed, or even adjust it, would open up several avenues of creativity in mapmaking.

I've marked most of these with asterisks for a specific reason: these values aren't separated out for individual players, but are based on local client values. With EUDs, this means we had to be very careful about not using these as conditions on triggers that affect the game state, or else it would cause a discrepancy that would disconnect/drop players that didn't have matching game states from each other (though as actions they are without such consequence). It stands to reason, then, that if these were to be included as native trigger conditions, there would need to be some netcode rework, which is not nearly as trivial as some other mentioned items in this write-up.

Game Latency was mostly useful as a condition: hackers, or even just people with Cheat Engine open, could locally adjust their latency to gain an unfair reaction-time advantage over their opponents. Using EUDs, we could detect this discrepancy and remove the exploiter from the game via desynchronizing their game state, which causes them to drop from the other players. Like game speed, it would be a nice option as a trigger action to be able to change the game's latency setting.

I recently saw a game that used EUDs to change the game's brightness in the middle of the game to simulate day-night cycles: when night comes around, the brightness levels automatically turn down, and come sunrise, brightness turns back up. This type of simple mechanic could be used for other atmospheric situations (dark caves, power outages, etc.), and again, while it would be an issue to use as a trigger condition, it would be harmless to include as a trigger action.

Being able to detect what keys on the keyboard a player presses is possibly one of the most beloved trigger conditions made available by EUDs, but unfortunately, it does not play nicely in multiplayer, since the values are going to vary per client. While this type of trigger functionality was available on Warcraft III, it came with a small performance penalty: like SC, Warcraft III operated with a latency system that delays taking action immediately to give time to broadcast a player's actions to others, but this didn't apply to trigger events, so key presses would try to send out immediately and halt the game until all players were ready to fire the trigger, which could cause stuttering with players on slower connections. It's unfortunate that key press detection is a nontrivial implementation when it has many very cool applications.

Finally, Display Text is the most complicated thing to detect with EUDs, but nevertheless, many proof-of-concepts have come out of it. One famous example is the ability to detect a very popular hacking program, after which the game could cause them to disconnect from the other players. But other examples can be found as well, such as having a text command that does something in-game. This again can be compared to Warcraft III's excellent text detection system (used in many famous maps, including DotA), though what we could do with EUDs was ridiculously nuanced and limited, and ultimately it's not practical in its current form to try and read game/chat text.

Arithmetic

Finally, what EUDs were most powerful at was the option to let us add and subtract values to things we could normally only set. Particularly regarding units, upgrades, and technologies, being able to say, add 5 health to a unit was as simple as it is to add 5 minerals to a player. I'm sure someone could compile a larger list, but personally, the things I think are most important:

  • "Modify Unit Energy" - Set/Add/Subtract raw value (instead of just set percentage)
  • "Modify Unit Hit Points" - Set/Add/Subtract raw value (instead of just set percentage)
  • "Modify Unit Resource Amount" - Add/Subtract options
  • "Modify Unit Shield Points" - Set/Add/Subtract raw value (instead of just set percentage)
  • New "Set Kills" action with Set/Add/Subtract (corresponding to "Kills" condition)
  • New "Move Location by Pixels" action
  • New "Move Screen Position by Pixels" action

Moving a unit by pixels would be a nice-to-have, but if I remember correctly, it didn't work to just set the unit's coordinates with EUDs, and ultimately, the same effect can be achieved by moving a location on top of the unit, moving the location by pixels, and then moving the unit onto the location.

This doesn't pertain to EUDs specifically, but having multiplication, division, and modulus would simplify a lot of the calculations mapmakers have to do today and open up a lot more practical solutions to problems we commonly face.


Post has been edited 2 time(s), last time on May 19 2017, 3:26 am by Roy.




May 19 2017, 11:35 am Suicidal Insanity Post #20

I see you !

And if they are adding math, may as well include sin / cos / exp / log / sqrt / pow / etc, very little added complexity for a large amount of added flexibility.




Options
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[02:08 pm]
SiKiN -- oh yea and a mech version
[02:05 pm]
SiKiN -- We are working on a Marine version next with a Zergling version aswell. not sure about protoss because of the sprite limits
[02:04 pm]
SiKiN -- I think its done, finaly
[10:00 am]
KrayZee -- :0
[09:36 am]
Suicidal Insanity -- They just have a discord for posting even more memes than they post here ;(
[08:20 am]
SiKiN -- You guys have a testing group for maps? Or a discord?
[06:34 am]
MasterJohnny -- Zoan
Zoan shouted: guys im going to China in 2 days
Bring dust mask things and a mosquitoes net. If anyone asks nothing happened on June 4 1984.
[06:34 am]
O)FaRTy1billion[MM] -- NudeRaider
NudeRaider shouted: FaRTy1billion I'm wondering: Does extended anything (like place extended units for supply) count as euds (i'd guess no)? Do these overflows still work?
I'm pretty sure all extended units and extended players were fixed
[06:14 am]
Pr0nogo -- I mean I get people not wanting to put in the work, it's not easy, but then they'll say as much without people whining in the shoutbox about my posts
Please log in to shout.


Members Online: Roy, jjf28, SiKiN, Wing Zero