Staredit Network

Hello, everyone.

I've come up with an program that I hope will benefit the Use Map Settings map making community.

What the program does is open a map CHK file, then scans all triggers that are owned by a selected player. Once those triggers are found, they are duplicated to all other players that you specify. This alone could save some copying in StarEdit, but the real purpose of this program is modifying the triggers to reflect the player they belong to.

For example, suppose you have a start location for player titled P1Location and P2Location. You can set up the program to assign P1Location to Player 1 only, P2Location to Player 2, and so on. So if a trigger is copied from Player 1 to Player 2, and it has a condition or action that references P1Location, it will automatically be changed to P2Location. The same concept applies to switches as well.

The idea is to make adding triggers to maps simpler. All you would need to do is create the triggers of one player that needs functionality, and then use the program to copy the triggers over to other players.

I'm nearing the final stages of a first version of this program, and I have a few more tests I need to run to find any more major bugs, but the program should be completed very shortly. Currently, it is a very primitive design, and you must manually edit a configuration file, though that is fairly simple, and I'll try to include a full documentation an some examples with the program. Once the config file is set up, just run the program. The program itself does not require user input.

Although most triggers should duplicate correctly, you may still need to edit some of them, such as triggers that modify a player's alliance status.

So... I've posted this to see what the mappers think of my idea. I welcome any feedback or suggestions, but don't expect anything too fancy for my first release of the program. I will definitely try to get them in later releases, if I can.

So what do you think? Is this is a good idea?

So are you saying that you select the triggers you want duplicated and which aspect to be changed? What if you want current player but the trigger to be owned by different players using locations with numbers at the end in increments of one?

Well done, I must say. I hope it works

This woulde Uberly usefull in some cases. I've had to copy paste 100+ triggers. Good Luck with the program. Copying 100+ triggers is a huge pain in the , this program would PWN when you would have to do that.

Right now, you can't select individual triggers, but that is something I want to add eventually.

All triggers that belong to the specified player, and only to that player, will be copied. So if you have a trigger that belongs to both Player 1 and Player 2, it won't be copied. And right now, you can't copy forces, only individual players.

The names of the locations aren't a problem. In the configuration file, you need to list the switches or locations to be used by that particular player. These lists are grouped into sets, so if a switch or location is referenced in a trigger, it is replaced by new switch/location from within the same set. Basically, it just means that you can associate each player with their own switch/location. It doesn't matter how the triggers are named. You don't have to name them with numbers as in "P1Location". I just name my own locations like this so they're easier to organize and use. You could name them "PlayerOneLoc" or "RedStart" or whatever.

If a trigger has a condition or action that references "current player", then that is not changed.

If Player 1's trigger has a condition like:
Current Player brings 1 Terran Marine to P1Location
And it is duplicated over to player 2, it will become:
Current Player brings 1 Terran Marine to P2Location

But if Player 1's trigger is
Player 1 brings 1 Terran Marine to P1Location
And it is copied to player 2, it becomes:
Player 2 brings 1 Terran Marine to P2Location

But it will only copy if the players match.
If Player 1's trigger is
Player 5 brings 1 Terran Marine to P5Location
Then it won't be changed. Even though the trigger is owned by Player 1, the condition's parameters reference Player 5, and not itself.

Hope this cleared up a bit how the program operates. Even though it may not copy everything correctly, it should still save lots of time from something you'd otherwise have to do yourself.

Nice idea man. Something that should also be thought of is copying the little triggers inside a trigger box.

This is a great idea , Expecially when making bound's, Instead of just going through and making all the triggers, You can just duplicate them...Cool...

This is something we've needed for a long time.
I never liked doing stuff like this, what a great tool.
Care to attach it?

[EDIT]: Ahh, final stages. Good luck .

OMG i was waiting for tis a long time...lol GOOD job...

sorry for shouting, but i posted leik 5 post abou this...finally some1 did somthing!

GJ again

Isn't this like those macro programs BoltHead and Softwarewolf use to duplicate triggers?

That will be really usefull, but make sure it's compatible with Starcraft Xtra-editor. Since you can past trigger in SF, Xtra would have the samething.

It's could be extremely usefull.

I won't use it cause i don't trust beta things and i'm too lazy to do your configuration file. Hope you will finish it and make it fancy

I think I'm almost done the program. I've run a few more tests, and it seems that all the major bugs are worked out. I just got a few more things to do before I release the program.

As for being compatible with other programs, I don't see why not. Well, StarForge has a bit of a problem, but there's an easy way to go around that. The program takes an input CHK file then creates a new CHK file with the new triggers. These uncompressed map files can be loaded into StarEdit just like a normal map. You can then resave the map in StarEdit as an SCM/SCX map, which any map editing program such as StarForge should be able to read just fine.

And -Juvenil- is too lazy to use my configuration file... well, would you rather spend just a few minutes setting that up, or spend a few hours copying all the triggers yourself? But I do plan on adding a user interface soon.

Well it's not that i'm lazy, it's more that I think those things are too complicated for me. I can't do it my self ,even if you give me the whole damn plan. I just can't... Maybe I'm dumb.

I hate those things, it's chinese to me.

Better idea for GUI.

Have it select which players/forces to copy to, then use a replace thing.

Have a window where you can enter as many values of

"string 1":"string 2"

and if it finds an instance of string 1 (case insensitive) it will replace it with string 2 (case sensitive)

Or have a tab called "n00b" that attempts to do such things automagically and a tab called "expert" where we specifically specify the find/.replace values.

Good idea; simple program. have fun.

hehe, I think everyone's already said this, but I'll say it again. I think it's an awesome idea!

I probably want to be able to choose which triggers would be duplicated somehow, but either way, it'll be so useful.

Yes, the GUI is my biggest concern. The current version is an old DOS program, and I know that alone might make it a bit difficult to use for some people.

I'm currently using an old DOS C++ compiler, but I might be able to compile it as a normal windows console program. I downloaded a compiler only (no editor) from the Microsoft website, I think I'll give it a try. But I want to get away from DOS completely, if I can, and use a normal interface like dialog boxes and buttons. But my windows programming abilities are extremely limited. I'm also considering switching from C++ to Visual Basic, as I think that might be easier to use, provided I can find a free VB windows compiler/editor. But if all that fancy stuff won't work, I'll have to stick with DOS...

im wondering, lets say if you had a location, here1 and here2, would it work? if you duplicated or you musrt have P1 and P2 in front?

gj though.

wondering if you can make it to copy more than just players

thatll be great, i can name units in order. 1.2.3.4....
great for games with levels and such!

Sounds 95% useless to me.

Why is that bolt, will save me alot of time

Mostly because anything major can be worked around with creative triggering. And you never have to "copy" a trigger to another player unless your making changes. Otherwise you just check the applying players.

I'm kinda sceptiacal about something that uses your string names to select the new locations. But I figured if locations was a big enouth problem in the first place you could use the same location for each player just by centering it for each player. This would prevent the need for a extra trigger in the first place.

I think the program seems like it is designed to aid people who have limited triggering experiance so they use it instead of learning a good way to work around it. The more advanced you get at triggers the more you learn to addapt your triggers to work on a more global scale instead of for individual players.

You should be able to if you can make the triggers pure text and do exclusive replacing.

The program has been submitted. Feel free to give it a try, just don't expect it to be bug free... with it being it's first release, I'm not sure how it will work on other machines. I'm already working on newer version with it's own user interface. It won't be a Windows (like a dialog box) program, but will run under the windows console. Combined with a new compiler that I just got to work, development should go somewhat smoothly.


Locations and switches can be named anything. They don't require "P1" or any such symbols in their name. You could name your locations "Adaflooey" and it should still work. I'm planning on adding some automated tasks that will scan for "1" or "P1", instead of having to specify everything manually.


All locations are given a string, obviously, which is how you name them in the first place. By comparing the strings, it can find what location is using that string, and it can change the trigger data to reference a new location. (or switch)


I understand what your saying about locations and having them center themselves over something, and I understand how an expert triggerster will automatically know how to avoid most of this stuff. But what if you're designing something that just won't work that way? This program doesn't just affect locations, it will work on switches as well, so perhaps there's some use there. There do appear to be limits to the amount of triggers that the program can copy without having StarEdit crash, but that's somewhere around 250-300+, I think.

The idea just came to me. I wasn't really working on a map at the time, either, it just suddenly popped into my head, so I thought about it. After looking around for programs that might already do this, and finding nothing, I started working on it. And judging from some of the responses here, most people might have some use for it.

My goal was just to make something that could benefit map makers by helping to eliminate some of the tedious work with triggering.

Instead of just duplicating triggers between players 1-8, I plan on adding support for forces, and some other general features. One of my ideas is to allow you to export triggers, locations, and switches from a map, and reimport them into an entirely new one, with the triggers remaining intact. I don't know how well it will work, it's just an idea right now.

Creent version looks pretty good for first release. keep it up.

You can substitute death counters for "current player" switches so its not really useful in that aspect ether. I can’t think of situation where this would be needed to save a lot of time.

I’m sorry to be the pessimistic ass about this, If you find it useful or some other people then that’s good. Even if your just doing it for the programming experience that’s cool. Don’t bother with the forces and all players (you already done that technically)

Now your idea about exporting the triggers, That’s a good idea. You should be able to get it work pretty well. Even though you rename the locations in Staredit still knows what location it is. (for and example make a bunch of named locations, delete one then remake it) If it didn’t remember the location numbers then I wouldn’t count them properly.

Although it might be more useful to actually use the custom strings to replace the locations in the trigger with the ones in the editor that have the exact same string name. (maybe an option between the two ideas)

i for one dont mind copying and pasting that much... but if u get a program to do it for me then im game

Actually, the only time I really need this is for a grid where each player has their own location so that if you move the grid for one player, you cannot have the same trigger moving a different location. Same with spell casting and waits.