The value "compressed" shows the file's size within the map.
Maps are mpq archives which compress their content.
If the image isn't already in the dds format, you can transform the texture into the dds image format which compresses pretty good on its highest compression level.
If the model wants another format ending, you can just rename it. Only the editor will throw warnings, the game itself can handle wrong file endings.
So if it was e.g. ".tga", you can transform it into a compressed ".dds" and rename the file back to ".tga".
You can always lower the resolution of the images, meaning you resize them in an appropriate image editing program.
If you use gimp, I advise you to get the updated version of the dds-plugin. It was updated like 2 months ago. It fixes a lot of problems gimp had with dds files like accidentally creating rectangular colored areas.
I could imagine that it would make a high templar use psi storm on the best spot automatically without ordering it to use it on a point yourself.
But I'm only guessing, so... it could be totally different.
How about trying it out and tell us what you think it does?
@Rice87: Go
That's how shift works: Add order at the end of the queue. It won't ever cancel the current order.
You can raise the time the unit requires to finish the ability (e.g. add a cast time). Then you can click and then fast hold shift and quickly click again to queue the ability commands.
To cast instant abilities multiple times, you hold the button's hotkey and click around. People do that in the default SC2 game, too. Queuing (= holding shift) is not required.
You would need to create a mod and publish it. Then you would need to modify every map to have a dependency to that mod version and publish these, too.
If you update the mod, you would need to update all map versions to the new mod version (modify dependency, publish), else the old mod version is still used.
I just made a map that can do "unlimited" research displays.
It is saving the text tag reference (which internally an integer) in a data table using the string "tag" and the researching unit's unique tag.
This requires the 1.5 arcade beta as the unit's unique tag wasn't existing/accessible before (I think).
Else you could build a unique tag with the x and y coordinates of the building's position.
Do you by any chance run the trigger debug window when you test for lag? A piece of advice: Don't do that! The trigger debug window is a major source of lag, especially with events for registering damage, which tend to trigger quite often.
Deactivate your trigger debugger or even try to upload the map privately and see, if it lags on battlenet.
Deactivate the debugger's bottom logging panel except for errors. Every update creates a lot of lag (especially before 1.5). So make sure that there don't appear any log messages, if you test for performance. Also, pre 1.5, every new log entry is creating a huge lag on each update. So if that list is filled and a new line appears, it creates even more lag than before.
The debugger's active tab should display the active threads or the activity. Everything with a lot of values displayed creates a big lag with every update. So variables and triggers is bad (especially triggers lags a lot).
If you use 1.5, the one with the code (last tab) is the fastest.
So, in general you can leave the debugger on, you just need to know which settings you need to use to have less debugger caused lags in your map.
You can change the image and the mouse hover image of a button.
With some picture editing skills, you can copy paste the look of the hovered, over-pressed button image twice into a copied button image and use that.
If you extract the pictures and compare them to a button ingame, you should understand which area of each image is used when.
- Thousands of snapshot actors (like building images in the fog) create lag (Disabling visibility of not in that moment required actors fixes that. To recover them, make them visible again.). 9000 is to much. Actors with a model in general could create that lag, too.
- Thousands of units will eat up a lot of FPS. 15k is the limit I think. You shouldn't really come close to that limit. Store the information of not required units in the global data table and recreate them, when required.
- 256 x 256 map size is max.
- Zooming in the camera creates non-visible/reachable areas at the sides of the map. The camera will hit the boundary even if you can't see anything close to it. You can even create a paradox where a wide-screen sees less than a normal aspect ration. If your camera always follows a unit, you can try to improve the situation by raising the followed unit into the air via unit height and lower its actor back to the ground via site operations.
I tried to keep the same unit, so no morphing required.
1. make a copy of marine actor (named marineShield)
2. change the group and unit wireframe of the marineShield actor to the "marine-shield" wireframe.
3. in the marineShield actor events, delete all actor events that either use "Create" or start with the birth of a marine. We don't want that actor to create itself.
4. in the marineShield actor events, delete the actor event "ActorCreation => ValidatePlayer NoMarineShield -> AnimPlay Cover Cover PlayForever 0.0000000". That actor event would have removed the shield, if no upgrade existed on actor creation. But we want the shield to stay on the marine.
5. In the original marine actor, add an event: "Signal" with the name "MarineShield" and chose "Create" as the action and chose the marineShield actor in the create statement.
6. Copy the event we just made with the "Signal.*.MarineShield" and chose "Destroy" as the action.
7. Send a Signal with the name "MarineShield" to the main actor of the unit that should receive the shield.
It works as seen in the attached map.
But this has 1 problem: a unit's group wireframe is not updated, if the game had to display the unit's group wireframe at least once.
Morphing the marine to a new marine (morph ability) would work without that change. But other things like armor upgrades wouldn't work on that unit, I assume.
1. Move the anti air weapon in the weapon list to the top.
2. Enable "Ignore Threat" in the ground weapon.
3. Enable "Continuous Scan" in the air weapon.
Not really possible unless you want to edit every time value in the data.
And even then you might run into "small" problems because the game runs in less cycles.
I think sc2 runs in 1/16 cycles per game second. If you speed up everything by halving every duration, you might have a problem, if something took 3 cycles before. Then it uses either 1 or 2 cycles.
For example that could be a psi storm dealing damage on a faster or slower rate which has a theoretical impact on the game's balance...
- Is it possible to make other models not pick up another model's texture when importing it into the editor?
No, but you can immediately change the texture via "texture select by id" in the unit's actor events, if you added a texture object in the map and a texture declaration in the model object.
0
The value "compressed" shows the file's size within the map.
Maps are mpq archives which compress their content.
If the image isn't already in the dds format, you can transform the texture into the dds image format which compresses pretty good on its highest compression level.
If the model wants another format ending, you can just rename it. Only the editor will throw warnings, the game itself can handle wrong file endings.
So if it was e.g. ".tga", you can transform it into a compressed ".dds" and rename the file back to ".tga".
You can always lower the resolution of the images, meaning you resize them in an appropriate image editing program.
If you use gimp, I advise you to get the updated version of the dds-plugin. It was updated like 2 months ago. It fixes a lot of problems gimp had with dds files like accidentally creating rectangular colored areas.
0
If your "model" is actually a "unit", then you can try to set the unit's "default acquire level" to "none".
0
I could imagine that it would make a high templar use psi storm on the best spot automatically without ordering it to use it on a point yourself.
But I'm only guessing, so... it could be totally different.
How about trying it out and tell us what you think it does?
0
@Rice87: Go That's how shift works: Add order at the end of the queue. It won't ever cancel the current order.
You can raise the time the unit requires to finish the ability (e.g. add a cast time). Then you can click and then fast hold shift and quickly click again to queue the ability commands.
To cast instant abilities multiple times, you hold the button's hotkey and click around. People do that in the default SC2 game, too. Queuing (= holding shift) is not required.
0
Just hold the button to cast it multiple times.
Shift always queues the orders and the current order is the attack order.
0
You would need to create a mod and publish it. Then you would need to modify every map to have a dependency to that mod version and publish these, too.
If you update the mod, you would need to update all map versions to the new mod version (modify dependency, publish), else the old mod version is still used.
0
You can create text tags with triggers and save them in a data table.
The "text" for the text tag would look like that:
You can adjust the icon's size with that.
I just made a map that can do "unlimited" research displays.
It is saving the text tag reference (which internally an integer) in a data table using the string "tag" and the researching unit's unique tag.
This requires the 1.5 arcade beta as the unit's unique tag wasn't existing/accessible before (I think).
Else you could build a unique tag with the x and y coordinates of the building's position.
I attached the map to this post. 1.5 required.
0
Deactivate the debugger's bottom logging panel except for errors. Every update creates a lot of lag (especially before 1.5). So make sure that there don't appear any log messages, if you test for performance. Also, pre 1.5, every new log entry is creating a huge lag on each update. So if that list is filled and a new line appears, it creates even more lag than before.
The debugger's active tab should display the active threads or the activity. Everything with a lot of values displayed creates a big lag with every update. So variables and triggers is bad (especially triggers lags a lot).
If you use 1.5, the one with the code (last tab) is the fastest.
So, in general you can leave the debugger on, you just need to know which settings you need to use to have less debugger caused lags in your map.
0
You can change the image and the mouse hover image of a button.
With some picture editing skills, you can copy paste the look of the hovered, over-pressed button image twice into a copied button image and use that.
If you extract the pictures and compare them to a button ingame, you should understand which area of each image is used when.
0
Here a few I experienced with my diablo map:
- Thousands of snapshot actors (like building images in the fog) create lag (Disabling visibility of not in that moment required actors fixes that. To recover them, make them visible again.). 9000 is to much. Actors with a model in general could create that lag, too.
- Thousands of units will eat up a lot of FPS. 15k is the limit I think. You shouldn't really come close to that limit. Store the information of not required units in the global data table and recreate them, when required.
- 256 x 256 map size is max.
- Zooming in the camera creates non-visible/reachable areas at the sides of the map. The camera will hit the boundary even if you can't see anything close to it. You can even create a paradox where a wide-screen sees less than a normal aspect ration. If your camera always follows a unit, you can try to improve the situation by raising the followed unit into the air via unit height and lower its actor back to the ground via site operations.
0
I tried to keep the same unit, so no morphing required.
1. make a copy of marine actor (named marineShield)
2. change the group and unit wireframe of the marineShield actor to the "marine-shield" wireframe.
3. in the marineShield actor events, delete all actor events that either use "Create" or start with the birth of a marine. We don't want that actor to create itself.
4. in the marineShield actor events, delete the actor event "ActorCreation => ValidatePlayer NoMarineShield -> AnimPlay Cover Cover PlayForever 0.0000000". That actor event would have removed the shield, if no upgrade existed on actor creation. But we want the shield to stay on the marine.
5. In the original marine actor, add an event: "Signal" with the name "MarineShield" and chose "Create" as the action and chose the marineShield actor in the create statement.
6. Copy the event we just made with the "Signal.*.MarineShield" and chose "Destroy" as the action.
7. Send a Signal with the name "MarineShield" to the main actor of the unit that should receive the shield.
It works as seen in the attached map.
But this has 1 problem: a unit's group wireframe is not updated, if the game had to display the unit's group wireframe at least once.
Morphing the marine to a new marine (morph ability) would work without that change. But other things like armor upgrades wouldn't work on that unit, I assume.
0
1. Move the anti air weapon in the weapon list to the top.
2. Enable "Ignore Threat" in the ground weapon.
3. Enable "Continuous Scan" in the air weapon.
I used a Goliath for testing.
0
There was a new update today. Maybe it has been solved. Else report it in the forums.
0
Not really possible unless you want to edit every time value in the data.
And even then you might run into "small" problems because the game runs in less cycles.
I think sc2 runs in 1/16 cycles per game second. If you speed up everything by halving every duration, you might have a problem, if something took 3 cycles before. Then it uses either 1 or 2 cycles.
For example that could be a psi storm dealing damage on a faster or slower rate which has a theoretical impact on the game's balance...
0
No, but you can immediately change the texture via "texture select by id" in the unit's actor events, if you added a texture object in the map and a texture declaration in the model object.