Well this new patch basically caused this map to implode. Here's the issues I've seen so far.
- I need to completely rebuild the taser and reaper pistols, as they were based off of default data apparently.
- I need to redo all of my dialogs, because the patch changed their sizes and they no longer fit on the screen.
- I need to find a bunch more images for my weapon ammunition, as nearly all the terran images have been removed.
- I need to figure out why my weapons aren't doing as much damage anymore. Seriously they all do much less damage now and I have no clue why.
- I need to redo the opening and closing parts of my map as they both are completely broken now.
- Need to figure out why the molotov is now firing forever when I use it (Yay data editor...)
- Need to fix cloak, as it doesn't do anything anymore.
- They changed the model for the shield and it looks ridiculous now, so I'll have to find something new for that.
- They changed what a bunch of doodads looked like. While this wouldn't be a serious issue for a normal map, my map is a sidescroller and I was relying on those doodads to look that way. Now I'll basically have to replace most if not all of them.
And these are only the ones I've been able to find. Who knows how many other bugs have been created that I haven't noticed yet...
EDIT: I've basically decided to halt production on this map until game release. The phase two patch set me back weeks in development, and I really don't want that to happen again.
Well, SC2 is officially out now, and it looks at first glance that I'll be able to resume work on repairs with this. Plus, the contest I have it entered in recently just got a huge deadline extension, so I'm remotivated to finish this and really polish it up again.
I'll need assistance though. There are still plenty of bugs, annoying visual glitches, and things that the phase two beta messed with, and I need testers to report EVERY single thing that seems off. Below is a list of all the things I've caught so far, along with the progress I still have to make. I've fixed over half of the bugs, but its demotivating work having to redo large sections of data and scrap ideas simply because the editor no longer will allow them... Not to mention most of the problems stem from the data editor, which I really still don't like to work with.
Data Editor problems: Grenades have a noticably smaller area of effect and don't do lethal damage anymore. Reaper Pistol and Taser have completely stopped functioning. Molotovs duration of fire is now ridiculously long. Seeker Drone's sight range is drastically reduced. All Weapon Items no longer have the light halo. The model for the Healing Shield was changed, and unless I find a way to rotate it I won't be able to use it anymore.
Most of these problems stem from sloppy use of the data editor back when I first started learning the editor. I edited a lot of default data items, and they all broke when the patch happened. Not only do I have to fix the broken links, but I also have to redo a lot of the work I did to not use any default data, and that is going to take a lot of time.
UI Problems: All the Dialogs will need to be resized and reworked. Over half of the pictures I used for ammunition and other things are no longer in the editor, and a few of them do not have any suitable replacement. This means I'll either have to settle with pictures that don't fit very well, or design my own, which will also take some time.
Trigger Problems: The movement has become noticably more delayed with each keystroke, moreso than before. I have no idea how I'll fix this, and I might just have to live with it.
I still have to do the following: Design 2 more weapons, the minigun and the EMP. Minigun will be easy once I get the reaper pistols working again, but the EMP will be a little annoying (Nothing like the molotov though, that was easily the most difficult weapon to make). Set up the 6 multiplayer modes (Deathmatch, Team Deathmatch, Capture the Flag, King of the Beacon, Zone Control, Juggernaut). (Possibly) Set up 2-4 single player game modes (Speed Trial, Dodge the Seeker Missiles, and maybe 2 others if there is time.) And probably quite a few minor details I'm forgetting at the moment that will end up being horribly difficult to set up in the future.
Of the things left to do, getting the game modes set up is the real big final hurdle to get over. When that is done all that's really left is getting it all balanced out, adding any optional features that don't need to be in the game, and really giving the whole thing a final polish. After Reaper Arena, I plan on either starting work almost immediately on Reaper Arena 2 or taking some time to work on a different project I've been thinking of for the past few months...
I've been having trouble staying motivated on this project, but I still really want to finish it and have it polished and fun. If anybody, anybody at all, wants to assist with some aspects of the map (Particularly the Data Editor, I am seriously beginning to hate that thing) I am open for assistance with this map.
Getting back into the groove of things, I plan on resuming my 3 day updates like I was doing before. Here's v.0.1.9, it doesn't have any new features, but it fixes all of the problems that the previous versions got when the beta 2 thing happened. v.0.2.0 should be a pretty large update.
Uploaded v.0.1.9
Fixes: Molotovs repaired, Healing Shield model changed, Cloaking fixed, Reaper Pistol and Taser repaired, Odd doodads on bottom of map have been removed, Decal on center of map removed, Dialogs are positioned correctly again, Seeker Drone fixed, item halos restored.
Modified Weapons: Grenades now deal 75 damage instead of 100, but their AoE has been increased to 2 (from 1). Flamethrower now deals slightly less damage per second.
I can't fix the custom dialog problems as of yet, because the action used to create it is flat out broken now, but the other things should be working. Tell me if you see anything off if you try the map, any feedback would be very much appreciated.
Getting testing done on things like game variants and multiplayer setups is really annoying with the publishing system, and UI isn't exactly the most entertaining coding to do, but I've been making progress still. Hopefully I'll have a better working multiplayer with a future update, but atleast this release is setting the foundations that will lead to that.
Anyways, here's v.0.2.0. I did a lot for this update and I definitely don't remember all of it... lol. The update is a little shakey, because a lot of features have been added but not actually finished. You'll see things like "Dodge the Seeker Drone" as a new single player option, but it hasn't actually been created, and very few of the new features will be visible unless you are playing a published multiplayer version.
Anyways, here you go...
Uploaded v.0.2.0
Added UI: Pregame menu added. Single Player Modes "Speed Trial" and "Dodge the Seeker Drone" added to menu (Neither are completely finished, but you can do speed trials still). Multiplayer modes Team Deathmatch, FFA Deathmatch, CTF, Zone Control, Juggernaut, and King of the Beacon all added (Only viewable if you are playing multiplayer...)
Multiplayer Functionalities: Added Game Variants Team Deathmatch, FFA Deathmatch, CTF, Zone Control, Juggernaut, King of the Beacon. Only Team Deathmatch currently works, however, and it's pretty barebone.
Many other various improvements...
If somebody is looking for a project, I still wouldn't mind getting some other mappers involved with this.
Hey, seems great... Just tested it out and I love it :)
I do have a question thought: I'm trying to make a jump and run game with the same principles you didi (top view - sideview unit)
Could you explain me how you did that.
As I'm trying to understand your map data, but still cant figure out.
Hey, sorry for taking a while to respond to your request, I just haven't had the time to really get a good reply until now. There's a few things you'll need to do if you want to make the sidescrolling setup like I did, and it does get a bit complicated.
First, you'll need to open your data editor and duplicate one of the actors in the Site Operations (Explicit Rotation) folder (a search for Explicit will find it). This actor has two values you can mess with to get different rotations, Actor - Forward and Actor - Up. You might need to tinker around with the values for a bit to figure out what corresponds where, but the defaults I used to rotate the Reaper to face left and right were "Forward: -1.00, 0.00, 0.00" and "Up: 0.00, 1.00, 0.00" to face Left and "Forward: 1.00, 0.00, 0.00" and "Up: 0.00, 1.00, 0.00" to face Right, and those two should probably cover most of the rotations you will use.
Second, you will need to work with your actual unit actors for a bit. I was pretty sloppy when I did this and you can put a bit more effort in making it orderly if you wish to. To set your newly created rotation actor to your unit actor, you'll need to edit the value "Hosting - Host Site Operations - Operations" and find your rotation actor and add it to the list. The actor will only accept one host site operation, and it's really tricky to get it to switch to a different one (I imagine its probably somewhere in the actor events, if you care to find it) so what I ended up doing is duplicating the unit, creating a "placeholder" unit for a duplicated actor, and gave the second duplicated actor the other site operation. Then, set up an actor event that makes it so when something specific happens (In my case, it was setting the scale of the unit) the current unit's actor is destroyed and the duplicated actor is created. Then whenever I need to reverse the unit's facing, I send the actor message that would trigger this event (By setting the unit's scale to 100% of it's original size, effectively doing nothing). This system is incredibly sloppy, but it does work. If you want to make it more orderly just create a custom ability that you can order your unit to do and have the actor event check to see when that ability is used.
Third, if you've managed to stay with me so far, is to create your game physics through triggers and point updated velocities. Essentially, you'll need to give your unit four variables, an X value and a Y value for the unit's velocity (I have a lot of units affected by the game's gravity, so I used the unit's first two Custom Values as the X and Y), and an X and Y value for the unit's acceleration. In a periodic trigger, create a local point variable with it's initial position set to your unit (If you have a lot of units, then you'll need to use some strategic loops to make sure this point applies to each of them individually each periodic trigger). Then to account for gravity move the point a certain distance downward from its original location. Then account for the current unit's accelerations (For my setup, if one or more of the arrows is pressed, its a constant acceleration in whatever directions are pressed.) and add them to the unit's current velocity. Then add the unit's current X and Y velocities to the point variable, updating its final position. But we aren't done yet...
You'll also need to account for obstacles and other things that may block the unit's movement, as the default response for the unit would be to walk around these obstacles, but we need them to land and move correctly. To do this, we need to set up a velocity "cushion" that constantly checks along a straight line between where the unit actually is and where it is trying to go, and "correcting" itself when the path is blocked. To do this, you'll need a few For Loops and another temporary point variable. The temporary point variable will start positioned where your unit is and for each loop iteration, will move out horizontally a small increment and check its current position to see if it is pathable. If it is, then the loop runs again until it has reached the current unit's X velocity, then another For Loop checks the same thing vertically. If the point is unpathable, then the Unit's original velocity point's x value or y value (depending on the loop) is set to match the temporary checking points x or y value. Finally, the last step is to check the distance between the unit and the unit's velocity point, and if its large enough to warrant movement, then tell the unit to move to that point. The distance check is there so if the unit isn't being told to move anywhere it won't constantly be told to move to the same spot its in.
So yah, take of that what you will, its really difficult to explain correctly. Take a look through the triggers I used to maybe sort of get some idea of what I did a little better. I will say that it is a finicky system, and there is definitely room for improvement, but I'm focusing on getting the rest set up before I revisit this part, so if you would like to take a second crack at it it would really be a good thing. It won't be easy, nothing I can tell you will make it a simple thing to get working, but if you still feel like using it then go ahead.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Well this new patch basically caused this map to implode. Here's the issues I've seen so far.
- I need to completely rebuild the taser and reaper pistols, as they were based off of default data apparently. - I need to redo all of my dialogs, because the patch changed their sizes and they no longer fit on the screen. - I need to find a bunch more images for my weapon ammunition, as nearly all the terran images have been removed. - I need to figure out why my weapons aren't doing as much damage anymore. Seriously they all do much less damage now and I have no clue why. - I need to redo the opening and closing parts of my map as they both are completely broken now. - Need to figure out why the molotov is now firing forever when I use it (Yay data editor...) - Need to fix cloak, as it doesn't do anything anymore. - They changed the model for the shield and it looks ridiculous now, so I'll have to find something new for that. - They changed what a bunch of doodads looked like. While this wouldn't be a serious issue for a normal map, my map is a sidescroller and I was relying on those doodads to look that way. Now I'll basically have to replace most if not all of them.
And these are only the ones I've been able to find. Who knows how many other bugs have been created that I haven't noticed yet...
EDIT: I've basically decided to halt production on this map until game release. The phase two patch set me back weeks in development, and I really don't want that to happen again.
Well, SC2 is officially out now, and it looks at first glance that I'll be able to resume work on repairs with this. Plus, the contest I have it entered in recently just got a huge deadline extension, so I'm remotivated to finish this and really polish it up again.
I'll need assistance though. There are still plenty of bugs, annoying visual glitches, and things that the phase two beta messed with, and I need testers to report EVERY single thing that seems off. Below is a list of all the things I've caught so far, along with the progress I still have to make. I've fixed over half of the bugs, but its demotivating work having to redo large sections of data and scrap ideas simply because the editor no longer will allow them... Not to mention most of the problems stem from the data editor, which I really still don't like to work with.
Of the things left to do, getting the game modes set up is the real big final hurdle to get over. When that is done all that's really left is getting it all balanced out, adding any optional features that don't need to be in the game, and really giving the whole thing a final polish. After Reaper Arena, I plan on either starting work almost immediately on Reaper Arena 2 or taking some time to work on a different project I've been thinking of for the past few months...
I've been having trouble staying motivated on this project, but I still really want to finish it and have it polished and fun. If anybody, anybody at all, wants to assist with some aspects of the map (Particularly the Data Editor, I am seriously beginning to hate that thing) I am open for assistance with this map.
Getting back into the groove of things, I plan on resuming my 3 day updates like I was doing before. Here's v.0.1.9, it doesn't have any new features, but it fixes all of the problems that the previous versions got when the beta 2 thing happened. v.0.2.0 should be a pretty large update.
Uploaded v.0.1.9
I can't fix the custom dialog problems as of yet, because the action used to create it is flat out broken now, but the other things should be working. Tell me if you see anything off if you try the map, any feedback would be very much appreciated.
Getting testing done on things like game variants and multiplayer setups is really annoying with the publishing system, and UI isn't exactly the most entertaining coding to do, but I've been making progress still. Hopefully I'll have a better working multiplayer with a future update, but atleast this release is setting the foundations that will lead to that.
Anyways, here's v.0.2.0. I did a lot for this update and I definitely don't remember all of it... lol. The update is a little shakey, because a lot of features have been added but not actually finished. You'll see things like "Dodge the Seeker Drone" as a new single player option, but it hasn't actually been created, and very few of the new features will be visible unless you are playing a published multiplayer version.
Anyways, here you go...
Uploaded v.0.2.0
If somebody is looking for a project, I still wouldn't mind getting some other mappers involved with this.
Hey, seems great... Just tested it out and I love it :) I do have a question thought: I'm trying to make a jump and run game with the same principles you didi (top view - sideview unit)
Could you explain me how you did that. As I'm trying to understand your map data, but still cant figure out.
I also sent you a pm
Kind regards
@killay: Go
Hey, sorry for taking a while to respond to your request, I just haven't had the time to really get a good reply until now. There's a few things you'll need to do if you want to make the sidescrolling setup like I did, and it does get a bit complicated.
First, you'll need to open your data editor and duplicate one of the actors in the Site Operations (Explicit Rotation) folder (a search for Explicit will find it). This actor has two values you can mess with to get different rotations, Actor - Forward and Actor - Up. You might need to tinker around with the values for a bit to figure out what corresponds where, but the defaults I used to rotate the Reaper to face left and right were "Forward: -1.00, 0.00, 0.00" and "Up: 0.00, 1.00, 0.00" to face Left and "Forward: 1.00, 0.00, 0.00" and "Up: 0.00, 1.00, 0.00" to face Right, and those two should probably cover most of the rotations you will use.
Second, you will need to work with your actual unit actors for a bit. I was pretty sloppy when I did this and you can put a bit more effort in making it orderly if you wish to. To set your newly created rotation actor to your unit actor, you'll need to edit the value "Hosting - Host Site Operations - Operations" and find your rotation actor and add it to the list. The actor will only accept one host site operation, and it's really tricky to get it to switch to a different one (I imagine its probably somewhere in the actor events, if you care to find it) so what I ended up doing is duplicating the unit, creating a "placeholder" unit for a duplicated actor, and gave the second duplicated actor the other site operation. Then, set up an actor event that makes it so when something specific happens (In my case, it was setting the scale of the unit) the current unit's actor is destroyed and the duplicated actor is created. Then whenever I need to reverse the unit's facing, I send the actor message that would trigger this event (By setting the unit's scale to 100% of it's original size, effectively doing nothing). This system is incredibly sloppy, but it does work. If you want to make it more orderly just create a custom ability that you can order your unit to do and have the actor event check to see when that ability is used.
Third, if you've managed to stay with me so far, is to create your game physics through triggers and point updated velocities. Essentially, you'll need to give your unit four variables, an X value and a Y value for the unit's velocity (I have a lot of units affected by the game's gravity, so I used the unit's first two Custom Values as the X and Y), and an X and Y value for the unit's acceleration. In a periodic trigger, create a local point variable with it's initial position set to your unit (If you have a lot of units, then you'll need to use some strategic loops to make sure this point applies to each of them individually each periodic trigger). Then to account for gravity move the point a certain distance downward from its original location. Then account for the current unit's accelerations (For my setup, if one or more of the arrows is pressed, its a constant acceleration in whatever directions are pressed.) and add them to the unit's current velocity. Then add the unit's current X and Y velocities to the point variable, updating its final position. But we aren't done yet...
You'll also need to account for obstacles and other things that may block the unit's movement, as the default response for the unit would be to walk around these obstacles, but we need them to land and move correctly. To do this, we need to set up a velocity "cushion" that constantly checks along a straight line between where the unit actually is and where it is trying to go, and "correcting" itself when the path is blocked. To do this, you'll need a few For Loops and another temporary point variable. The temporary point variable will start positioned where your unit is and for each loop iteration, will move out horizontally a small increment and check its current position to see if it is pathable. If it is, then the loop runs again until it has reached the current unit's X velocity, then another For Loop checks the same thing vertically. If the point is unpathable, then the Unit's original velocity point's x value or y value (depending on the loop) is set to match the temporary checking points x or y value. Finally, the last step is to check the distance between the unit and the unit's velocity point, and if its large enough to warrant movement, then tell the unit to move to that point. The distance check is there so if the unit isn't being told to move anywhere it won't constantly be told to move to the same spot its in.
So yah, take of that what you will, its really difficult to explain correctly. Take a look through the triggers I used to maybe sort of get some idea of what I did a little better. I will say that it is a finicky system, and there is definitely room for improvement, but I'm focusing on getting the rest set up before I revisit this part, so if you would like to take a second crack at it it would really be a good thing. It won't be easy, nothing I can tell you will make it a simple thing to get working, but if you still feel like using it then go ahead.