If anyone has suggestions for improvements, post away.

Current things I plan to do / have done:
- Easier scrolling in the doodad palette
- Remove flag bits 0 .. 11+14 from sprite properties (Keeping only unit/pure toggle, and active state)

Nothing?

The only thing that I can think of may be a quick button next to the doodad or sprite to take you directly to the doodad in the terrain tileset or from the sprite to the doodad, visa versa. Quick links to and from the three things.

Why remove the unused flags?

I think the way unit sprites are handled is poor, they are treated as sprites while the game treats them as units, they shouldn't be a subset of sprites, either it's own "layer" or under units maybe a check box next to the player field "place as unit sprite".

There's no option to not allow unit spites to be placed illegally, or snapped to grid as buildings, creep doesn't show etc. No option to edit unit/sprite ID or coordinates or move them in order.

Maybe show unit sprites in same window as units?

I think Unit sprites count towards the unit limit and not the sprite limit in game so they should do the same in SCMDraft?

A button to convert a unit to a unit sprite and vice versa.

Import/Export Unit and Sprite tables as .csv files.

Unit sprites are units and sprites and neither. That makes them tricky to position in the layers. I have occasionally thought about giving them their own root node in the object tree, and probably will do that, but I think I will keep them in the sprites layer.


If the unit / sprite limit thing is confirmed I'll fix that.

Not sure what you mean by the last one? Import / export the sprites on the map? Why?

unit sprites count toward the map sprite limit (499) and not the unit limit. When they are loaded they are converted to units (and thus count toward the in-game unit limit), but in the map itself they are still only sprites. I also believe map sprites are loaded before map units, but it's been a while since I've looked in to that.

- Have an option to skip unit properties just like starforge, so we can place units with Max HP>167772 at full HP.
- Open source

What do you mean by "the sprite limit in the map"? They are stored as sprites, there's no limit how many you can store in the sprite section only how many starcraft can handle, you can place more than 500 unit sprites just fine. If you have more than 500 pure spites the game will only load the first 500 pure sprites, no matter the amount of unit sprites. If you have more than 1700 units+unit sprites the game chrashes. You can have 400 pure sprites and 600 unit sprites just fine.

Post has been edited 1 time(s), last time on May 11 2017, 3:35 pm by ihjel.

Huh. I didn't realize that unit sprites didn't count toward that limit (and looking at the assembly, I can't even tell where that limit comes from). I just confirmed this too: I placed 500 unit sprites, 500 pure sprites, then 1 more unit sprite. All 501 unit sprites appeared, the first 499 pure sprites appeared and the 500th did not (as expected). So unit sprites placed after the pure sprite limit are still read, just the 500th+ pure sprites are ignored.

So yes, it makes more sense to include unit sprites as more or less real units (or at least count toward unit limit and not sprite limit).

Post has been edited 1 time(s), last time on May 11 2017, 7:23 pm by FaRTy1billion.

I think the limit is in the map loading code to not overload the images / sprites limits.

It must be after the map, or at least the section, is loaded, because I was looking at the code that actually reads the THG2 section. All this does is check that the section size is an integer multiple of 10, and then count down from size/10 for each THG2, calling the same CreateThingy function as iscript and everything else if it's a pure sprite, else if it's a unit then give doors to player 12 and check some stuff (is UMS, some other stuff that I'm not sure of) or if player is 12 then create a unit (with the same function as the UNIT section -- but without as much processing, hence some of the peculiarities of unit sprites) & finally if disabled flag is set then disable the unit. Nothing in that seems to limit the pure sprites. I looked a bit in to the CreateThingy, but it's all pretty standard especially since it's the same function used in-game.

regardless, it does seem that unit sprites and sprites should be treated more separately.

Post has been edited 5 time(s), last time on May 11 2017, 10:34 pm by FaRTy1billion.

Idk if this is the right place for it, but there's a bug when switching between maps using the "window" menu. Every time you switch to a map, scmdraft puts you into the doodad layer and the last doodad you placed is selected and on your cursor. Really annoying bug especially when terraining cause you gotta keep switching layers every time you switch from one map to another. If that requires clarification lemme know. You can recreate the bug by opening 2 maps, placing a doodad on the map, make sure your layer is not set to doodads, switch to the other map, switch back to the original map, and it should show the last placed doodad on your cursor.

Also how about not having the map convert terrain to doodads if they've been placed naturally or converted to just plain terrain?

Butch this is off topic but did you solve that issue with having to close Starcraft to save?

@Butch I fixed the layer switching a while back in the dev version.


Isn't the second thing an option in the settings? I think I added that because for a while starforge didn't write the doodad section.

I'm sure you fixed these issues as well:

• When selecting sprites and clicking properties the sprites aren't selected in the box and you have to click all of them individually to apply changes.
  
• When selecting units it tells you how many you have selected, would be useful for sprites too.
  
• When selecting units you can change their player by changing player, not so for sprites.
  
• When placing sprites, it always shows the unit sprite on the cursor in the colour of player 1 instead of selected player.
  
• Unit sprites aren't accounted for in unit placement, fog of war preview etc.
  
• A sprite owned by an extended player shows a blank field in the player field in properties.

Post has been edited 1 time(s), last time on May 12 2017, 12:42 pm by ihjel.

Not all of those, only most of em. But that is what this thread is for !

Well, I posted most of this elsewhere already, but I guess I have some new things to add.

• maybe remove hard limits for sprites from the editor, just issue a warning to players (and sprite counter turns red or something like that) when the limit of what the engine actually loads is exceeded. This leaves some leeway for first placing sprites and then deleting other ones and possible changes to the limits in future patches.
  
• add an option to convert units to unit sprites (and vice versa)
  
• and/or add most of the functionality for units to to sprites (place buildings on tile, stack, show collision boxes, change unit ID in sprite options, always update player colour and allow for simple player change via keypress/dropdowm menu)
  
• also make the display unit collision sizes option available for both units and unit sprite placement cursors and palettes.
  
• maybe add options for unit wireframe display and bleeding/burning animations for damaged buildings to the editor.
  

Post has been edited 1 time(s), last time on May 12 2017, 3:15 pm by Freakling.

It is already a soft limit in that it can be changed in settings.

You are right, I even remember having tinkered around with it in the past now. You actually need to know its there to change it.

- Provide an option to change the terrain to cursor offset
- Snap the cursor to the top left the terrain square (especially with larger tiles)

I have a problem when doing anything over 32x32. Since the cursor snaps to the middle I can't easily place it along the edge of the map. It would be nice to have an option to have it snap to the 0,0 instead of mid,mid cordinates.