Lag is entirely dependent on the person playing the game. I hope you aren't developing the map under the belief that you will have client side responsiveness as this is 100% impossible with the editor we have at the moment. Correctly implemented trigger based movement systems are just as responsive as a data driven method. There is one simple truth and that is that all commands issued by the client have to travel to battle.net, and the result travels back. It is THIS travel time that is unalterable, uncontrollable, unavoidable and will result in every single movement system having some form of delay which in turn makes any sort of serious attempt at an FPS control scheme impossible.
Ugh I cringe every time I see "lagless" input. No amount of data/trigger editor trickery is going to get rid of the latency between client -> server -> client. You must have read into programmer's lagless data input thread to discover it is not lagless? I love the FPS ideas and kudos for the work that the guys put into it but as it stands this type of game cannot work on SC2's battle.net. Perhaps you have a good connection to the server but for those of us with a latency over the 200ms mark (and that makes up a surprising amount of the b.net population) these games become completely unplayable.
Can you imagine playing SMB with 150-200ms latency? It's a nice idea and multiple height levels are very easy to handle for a 2D platformer but the latency between input will make the game unplayable.
The problem witht he Unit Compare Field validators is that they only compare the static pre-defined unit data. The units I am trying to validate are able to move and turn freely as the player issues them orders. I need a validator that can validate this facing direction at run time.
How do I validate a unit's facing direction? I need to validate wether a unit is facing 0-90, 90-180, 180-270, or 270-360 degrees for use as a term in an actor event.
I would advise taking a detailed look at the default SC2Layout files that manage the exsisting UI. As has already been stated in the thread, the exsisting UI already uses 3D models that are drawn on a special UI layer. It's a little more difficult than you would like and has some restrictions. The exsisting UI models have special built in cameras so you would need some way of editing your model to incorporate one of these. Also, to my knowledge, you will have no way of animating your model beyond default "birth", "death", and "stand" animations as you have no way of sending messages to specific UI objects.
Sixen, was there any information with regards to tools being released for the creation of custom content? I'm very excited about their map marketplace however, I don't see how mappers can create new games with original content if we don't have anything besides incomplete community tools.
Otacon, it's great to see someone working on what is probably the most important tool for the SC2 mapping community. However, as Nintoxicated has expressed that he shall no longer be working on the project, perhaps it is best that you start up your own asset page to more easily keep things updated (that is if you have plan on carrying on with development).
Ye, your problem is the way the engine decides to run actor events, I didn't figure out wether you have some form of control over the ordering or if the engine decides it all at run time. I imagine your current event flow chart looks a bit like this:
Click Unit-> Clicked == 1? -> Set Tint -> Set Clicked == 2 -> Clicked == 2? -> Set Tint -> Set Clicked = 1
I had a similar issue with some things I was testing recently. I have a map file somewhere where I corrected the problem, will take a look to see if I can't find it and post the solution.
A short while back I was brainstorming some ideas for hero arena style maps. In the attached maps you will find a couple of proof of concepts that are in a rather crude test state:
a) Fake asynchronous (client side, unaffected by latency) unit targeting without losing selection of your hero. This lets you target other units without any selection feedback delay from battle.net, all the while keeping your heroes command card available to the player at all times.
b) Multi-Team targeting. This example demonstrates selection for enemy and ally targets at the same time. Selecting a unit on the opposing team does not deselect your friendly target. Targeting a second enemy will deslect your original enemy target while retaining your friendly target.
c) Pre-Targeted abilities. This allows you to perform WoW style spell casting. First select an enemy unit, then use the snipe ability without any additional targeting requests. This can be relatively easily integrated into any exsisting targeted ability.
d) Some camera thing. Just a camera setup I was fiddling around with that felt conducive to an arena style map. Allows for following of your hero unit plus 2 additional targets (1 ally, 1 enemy). Moves around/zooms in and out depending on the position of said units. Can be configured to zoom at different speeds/levels among other things.
I'm not going to make a detailed tutorial about how any of this works, it's up to you to look at the map and figure it out. If you are interested in creating a tutorial of your own detailing this method, feel free to do so. This method uses some custom actors/validators/requirements, and some integration into the trigger editor in order to expose targeting to scripters. Units that you want to function with this targeting method would have to possess the actor events the SCV actor uses (ideally you would create a base actor to define these events and inherit from this actor for targetable units).
This resource assumes that you have a moderate understanding of trigger/data editing, and as such I will not be answering any questions that would be considered basic.
a) Your 3rd party app will generate an entirely new SC2Map based on the map the game was played on and the replay associated with the game. This is a bit cumbersome as every map you generate will have to be uploaded to B.Net in order to play. Perhaps if we had Blizzard supported specifications for how to log in/communicate with Battle.net we could automate this process however this seems unlikely.
b) You 3rd party app will generate a key based on the replay associated with the game while you will have a previously created/uploaded modified version of the map you wish to replay the game on. The map will have some function that accepts a valid key and, from that, recreates the snapshot.
c) Your custom melee map will have functionality that periodically generate a key based on a snapshots of the game. If a player drops the remaining persons will be able to retrieve the last valid key. Your custom map will then have a function that accepts the valid key and, from that, recreates the snapshot.
I believe what you want are terrain objects. If you open up a new map and add the campaign modules to your dependency list you should find a number of different terrain objects they made use of. Are these what you are looking for?
There has already been a lot of work in decoding the M3 format, however I salute you in your efforts thus far. If you are truly interested in delving further into this I would recommend visiting the asset page for Nintoxicated's M3 3DS Max Import/Export Plugin. The plugin itself is a wealth of information and Nintoxicated links back to a number of resources he used in his own work.
There are only two reasons, that I can think of, that would cause this to occur. Either you are displaying your dialog at another point in your map or the value being stored inside player2 is incorrect. I would debug it in this order:
a) Comment out the line of script. If the dialog still displays there is some other portion of your map displaying it.
b) Substitute player2 for a plain integer value, e.g. 2. If it displays, then substitute for another integer. It should no longer display after the 2nd substitution, this means player2 is getting an unintended value.
0
@gamfvr: Go
Lag is entirely dependent on the person playing the game. I hope you aren't developing the map under the belief that you will have client side responsiveness as this is 100% impossible with the editor we have at the moment. Correctly implemented trigger based movement systems are just as responsive as a data driven method. There is one simple truth and that is that all commands issued by the client have to travel to battle.net, and the result travels back. It is THIS travel time that is unalterable, uncontrollable, unavoidable and will result in every single movement system having some form of delay which in turn makes any sort of serious attempt at an FPS control scheme impossible.
0
@gamfvr: Go
Ugh I cringe every time I see "lagless" input. No amount of data/trigger editor trickery is going to get rid of the latency between client -> server -> client. You must have read into programmer's lagless data input thread to discover it is not lagless? I love the FPS ideas and kudos for the work that the guys put into it but as it stands this type of game cannot work on SC2's battle.net. Perhaps you have a good connection to the server but for those of us with a latency over the 200ms mark (and that makes up a surprising amount of the b.net population) these games become completely unplayable.
0
@Pshyched: Go
Can you imagine playing SMB with 150-200ms latency? It's a nice idea and multiple height levels are very easy to handle for a 2D platformer but the latency between input will make the game unplayable.
0
@DrSuperEvil: Go
Hey, thanks for the suggestion!
The problem witht he Unit Compare Field validators is that they only compare the static pre-defined unit data. The units I am trying to validate are able to move and turn freely as the player issues them orders. I need a validator that can validate this facing direction at run time.
0
How do I validate a unit's facing direction? I need to validate wether a unit is facing 0-90, 90-180, 180-270, or 270-360 degrees for use as a term in an actor event.
Thanks in advance.
0
I would advise taking a detailed look at the default SC2Layout files that manage the exsisting UI. As has already been stated in the thread, the exsisting UI already uses 3D models that are drawn on a special UI layer. It's a little more difficult than you would like and has some restrictions. The exsisting UI models have special built in cameras so you would need some way of editing your model to incorporate one of these. Also, to my knowledge, you will have no way of animating your model beyond default "birth", "death", and "stand" animations as you have no way of sending messages to specific UI objects.
0
Sixen, was there any information with regards to tools being released for the creation of custom content? I'm very excited about their map marketplace however, I don't see how mappers can create new games with original content if we don't have anything besides incomplete community tools.
0
@Otacon2k: Go
Otacon, it's great to see someone working on what is probably the most important tool for the SC2 mapping community. However, as Nintoxicated has expressed that he shall no longer be working on the project, perhaps it is best that you start up your own asset page to more easily keep things updated (that is if you have plan on carrying on with development).
0
@puritysdisciple: Go
You sound quite serious about your poject. Out of interest, what is your own personal roll in it's development? Scripting, artwork, sound, etc?
0
@DrSuperEvil: Go
Ye, your problem is the way the engine decides to run actor events, I didn't figure out wether you have some form of control over the ordering or if the engine decides it all at run time. I imagine your current event flow chart looks a bit like this:
Click Unit-> Clicked == 1? -> Set Tint -> Set Clicked == 2 -> Clicked == 2? -> Set Tint -> Set Clicked = 1
I had a similar issue with some things I was testing recently. I have a map file somewhere where I corrected the problem, will take a look to see if I can't find it and post the solution.
0
A short while back I was brainstorming some ideas for hero arena style maps. In the attached maps you will find a couple of proof of concepts that are in a rather crude test state:
a) Fake asynchronous (client side, unaffected by latency) unit targeting without losing selection of your hero. This lets you target other units without any selection feedback delay from battle.net, all the while keeping your heroes command card available to the player at all times.
b) Multi-Team targeting. This example demonstrates selection for enemy and ally targets at the same time. Selecting a unit on the opposing team does not deselect your friendly target. Targeting a second enemy will deslect your original enemy target while retaining your friendly target.
c) Pre-Targeted abilities. This allows you to perform WoW style spell casting. First select an enemy unit, then use the snipe ability without any additional targeting requests. This can be relatively easily integrated into any exsisting targeted ability.
d) Some camera thing. Just a camera setup I was fiddling around with that felt conducive to an arena style map. Allows for following of your hero unit plus 2 additional targets (1 ally, 1 enemy). Moves around/zooms in and out depending on the position of said units. Can be configured to zoom at different speeds/levels among other things.
I'm not going to make a detailed tutorial about how any of this works, it's up to you to look at the map and figure it out. If you are interested in creating a tutorial of your own detailing this method, feel free to do so. This method uses some custom actors/validators/requirements, and some integration into the trigger editor in order to expose targeting to scripters. Units that you want to function with this targeting method would have to possess the actor events the SCV actor uses (ideally you would create a base actor to define these events and inherit from this actor for targetable units).
This resource assumes that you have a moderate understanding of trigger/data editing, and as such I will not be answering any questions that would be considered basic.
0
@Ludwigvan1: Go
a) Your 3rd party app will generate an entirely new SC2Map based on the map the game was played on and the replay associated with the game. This is a bit cumbersome as every map you generate will have to be uploaded to B.Net in order to play. Perhaps if we had Blizzard supported specifications for how to log in/communicate with Battle.net we could automate this process however this seems unlikely.
b) You 3rd party app will generate a key based on the replay associated with the game while you will have a previously created/uploaded modified version of the map you wish to replay the game on. The map will have some function that accepts a valid key and, from that, recreates the snapshot.
c) Your custom melee map will have functionality that periodically generate a key based on a snapshots of the game. If a player drops the remaining persons will be able to retrieve the last valid key. Your custom map will then have a function that accepts the valid key and, from that, recreates the snapshot.
0
@xSteamGearx: Go
I believe what you want are terrain objects. If you open up a new map and add the campaign modules to your dependency list you should find a number of different terrain objects they made use of. Are these what you are looking for?
0
@Ebola0001: Go
There has already been a lot of work in decoding the M3 format, however I salute you in your efforts thus far. If you are truly interested in delving further into this I would recommend visiting the asset page for Nintoxicated's M3 3DS Max Import/Export Plugin. The plugin itself is a wealth of information and Nintoxicated links back to a number of resources he used in his own work.
Good luck.
0
@grenegg: Go
There are only two reasons, that I can think of, that would cause this to occur. Either you are displaying your dialog at another point in your map or the value being stored inside player2 is incorrect. I would debug it in this order:
a) Comment out the line of script. If the dialog still displays there is some other portion of your map displaying it.
b) Substitute player2 for a plain integer value, e.g. 2. If it displays, then substitute for another integer. It should no longer display after the 2nd substitution, this means player2 is getting an unintended value.
c) If it still displays I am pretty stumped.