The text trigger edit takes the location name and looks up the index when compiling. So if you save the triggers before reordering, then reorder, then load the triggers it works.
If you just reorder the locations and reopen the trigger editor it will display the new location names.
So if you swap the "Start Area" (index 0) and "Goal Area" (index 1) locations, then recompile an external trigger file, they will map to the new indices. If you swap them and only open the trigger editor the displayed triggers will have the two locations swapped.
That is also why you can store the location names outside of the normal map data - the triggers only care about the indices.
Reordering locations would break every trigger that uses the location because the triggers refer to locations via index and that would change.
If this is true, why don't triggers mess up while importing them via the text trigger editor?
Through my limited knowledge wouldn't you be able to work around it by right as you reorder the locations, you basically run the process that the trigger editor uses to error check/import the triggers?
It's not too hard just to remap the locations in the triggers, but this would obviously be a low priority feature and anyone using an external trigger editor that wasn't based on locationName (or anything advanced like EUD-mapped triggers/triggers inside the string section) would need to be responsible for their own indexes.
psedo:
locationCopy = locations[location1Idx]
location1 = locations[location2Idx]
location2 = locationCopy
for ( trigger in triggers ) {
for ( condition in trigger.conditions ) {
if ( condition.location == location1Idx )
condition.location = location2Idx
else if ( condition.location == location2Idx )
condition.location = location1Idx
}
for ( action in trigger.actions ) {
if ( action.location == location1Idx )
action.location = location2Idx
else if ( action.location == location2Idx )
action.location = location1Idx
if ( action.number == location1Idx && (action.actionId == ActionId::MoveLocation || action.actionId == ActionId::MoveUnits || action.actionId == ActionId::Order) )
action.number = location2Idx
else if ( action.number == location2Idx && (action.actionId == ActionId::MoveLocation || action.actionId == ActionId::MoveUnits || action.actionId == ActionId::Order) )
action.number = location1Idx
}
}
TheNitesWhoSay - Clan Aura -
githubReached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.
Implementing that isn't an issue, making it intuitive + working with plugins / external programs is a problem.
New version up with a few minor fixes (+ some internal changes that shouldn't be noticeable)
http://www.panschk.de/mappage/maps/(4)Proline%200.5(n).scmWas going to look at this melee using the new SCR ramps but getting that error when trying to open.
Loads fine for me. What does the extended error log say?
Resizing over and over again results in losing all isometric tile data (new isom brushwork turns everything into rectangles). Undoing doesn't fix it. Very frustrating bug.
Undoing should restore the original state. Isom was never designed for resizing, so I have seen resizing end up making single clicks place cliffs across the entire map.
Can you write up a repro series of steps, then I will take a look?
I made a 160x96 map, resized it to 192x96 with a width offset of 16, undo, resized it to 192x96 again with a width offset of -16, then terrained some more before resizing it to 192x96, width offset 16. Isom was broken after that.
Just tried that and it works for me. Wonder if it had something to do with undoing
Try
this map. Resizing to 224x96 with a negative width offset of 8 results in losing isom. Resizing to 224x96 with a positive width offset of 8 creates null tiles that behave oddly when brushed over with isom.
edit: any idea what causes the anywhere location to be editable?
Post has been edited 1 time(s), last time on Sep 15 2018, 2:12 am by Pr0nogo.
I get the null tiles - as I said the isom algorithm wasn't designed with resizing in mind, and I do not have a perfect way of expanding the isom map when the boundaries countain cliffs. I still do not lose isom. I am using the default tile type (water) for new areas.
Anywhere location: Whenever a location is changed the entry in the tree is updated. Since the anywhere location usually is never changed, the UI code did not ignore changes to the location and thus added an entry for it after it was resized.
Well I lose isom every time following those steps. I don't have a custom tileset loaded in the profile and my map isn't saved as remaster only so I don't know what would be different between our setups.
Any desire to allow for multiple tiles to be selected at once from the tileset indexed window? I have thousands of custom tiles and placing them one by one into a palette map is exhausting.
edit: seems like maps with width greater than 256 don't support minimaps, hope that can be fixed too
Post has been edited 1 time(s), last time on Sep 28 2018, 12:00 pm by Pr0nogo.
Been out of town ...
Multiselection in the tileset palette is on my todo list. I just never decided on a good UI for that. Maybe I'll just do it one way and see if I can come up with a better way afterwards
The algorithm to select the minimap colors for maps > 256 tiles isn't implemented, if that is useful its probably a quick fix. (Until it turns out it isn't)
A quick and dirty way to do multiselect is good for now. I expected just shift selecting would work fine.
> 256 is useful for terrain palettes.
edit: and being able to go to display options -> units and disable that would be really useful for doodading and decorating.
Post has been edited 1 time(s), last time on Oct 4 2018, 3:30 am by Pr0nogo.
I'm thinking about adding full pathing preview. That involves a huge amount of work though. Is there any interest?
This is the long path preview, if I send every unit to the same point:
The detailed path is missing, which is a lot more involved.
Prongo: edit: and being able to go to display options -> units and disable that would be really useful for doodading and decorating. <= What do you mean by that? Do you mean not displaying any units at all?
Post has been edited 2 time(s), last time on Nov 10 2018, 9:58 pm by Suicidal Insanity.
I would definitely use the pathfinding preview, though my above requests are more pressing for me personally. Yes, I mean hiding all units and showing only terrain/doodads/sprites plus any overlays.
I think I would use it as well, but I second that it's not a high-priority feature.
Should I require saving as SCX once non-default player colors have been selected?
