[Request] - Reduce size of Blocking Triggers
Post ideas and suggestions on new features or improvements here.
posted on May 10th, 2011, 8:57 pm
I would like the size of the blocking triggers to be reduced to about 50% of what they are now. I know that there is a small blocking trigger available, but the fact that it's invisible in the editor creates problems when trying to block-off a small area.
posted on May 10th, 2011, 9:53 pm
But that would ruin all of the maps that we have now 

posted on May 10th, 2011, 10:07 pm
I know that. But I don't see any other way to do it. The blocking triggers use the A2 asteroid field classlabel, which is hard-coded into A2 to only have one asteroid field. The small blocking trigger adds a second asteroid field, which causes issues when trying to make it visible. Mainly, pathing and visuals.
posted on May 11th, 2011, 12:42 am
You want the devs to make a change that will essentially nullify hundreds of hours of hard work by community mappers alone, just so you can make your own map the way you want it? Is that really what you're asking for here, or am I misunderstanding?
posted on May 11th, 2011, 2:17 am
Why not just ask them to make the small blocking trigger visible in the editor? 
At some point, they may be able to fix any issues with making it visible.

At some point, they may be able to fix any issues with making it visible.

posted on May 11th, 2011, 6:14 pm
Or add a new, smaller, small blocking trigger without changing the old one.
posted on May 11th, 2011, 6:53 pm
I think just fixing the current small blocking trigger would be good enough.
posted on May 11th, 2011, 6:54 pm
Yeah, to do your suggestion to shrink the bigger one would make a hell of a lot of work for everyone else, just to save you a little bit of inconvenience. If it is possible to add a second, smaller one, all good, go for it, but if not... it's not worth the hassle.
Also, you don't need to put "[Request]" in the subject title. This is the Requests section. It's already clear.
Also, you don't need to put "[Request]" in the subject title. This is the Requests section. It's already clear.
posted on May 11th, 2011, 8:20 pm
The thing is, the classlabel used by the triggers is hardcoded to only have 1 asteroid field. If the small trigger is modified to be visible, then it causes huge visual issues because it uses the same model as the normal field and the ScaleSOD command has no affect. It also causes huge pathing issues when made visible.
Some other ideas I had was to make the small trigger a "station" or "scrap" that is only visible in the editor.
The last idea was to completely rework the trigger so it itself is the asteroid field. It uses the asteroid field classlabel anyways, but doing that would cause even more map rework issues than what you have said.
Regardless of what's done, this issue with the blocking triggers has to be fixed.
Some other ideas I had was to make the small trigger a "station" or "scrap" that is only visible in the editor.
The last idea was to completely rework the trigger so it itself is the asteroid field. It uses the asteroid field classlabel anyways, but doing that would cause even more map rework issues than what you have said.
Regardless of what's done, this issue with the blocking triggers has to be fixed.
posted on May 11th, 2011, 9:24 pm
I don't see why a new one wouldn't work, but maybe I'm missing something here.
posted on May 11th, 2011, 10:57 pm
Not a new one, just changing how the program handles the small one by changing it's classlabel.
Or...
We could replace the blocking triggers with asteroid fields since the blocking triggers use the asteroid field classlabel. Which probably won't happen.
Or...
We could replace the blocking triggers with asteroid fields since the blocking triggers use the asteroid field classlabel. Which probably won't happen.
posted on May 12th, 2011, 2:45 am
No, a new trigger would be better because it wouldn't lead to compatability issues with maps that use the current SBT.
Who is online
Users browsing this forum: No registered users and 29 guests