EPTCustom map/ UMS creators wanted - Page 2
| Forum Index > BW General |
|
KhaosKreator
Canada145 Posts
| ||
|
nlight
Bulgaria58 Posts
On April 27 2017 07:35 KhaosKreator wrote: This sounds pretty neat. Maybe I'll use this when it's done and start making maps again. Given how much stuff I was able to add in the latest updates you can pretty much start using it. The language syntax will be kept stable so you just have to update langums.exe to get new features when they're available. | ||
|
TheFish7
United States2824 Posts
I used to know the editor pretty much in and out but with 0 programming knowledge outside of that I probably won't be much help. | ||
|
nlight
Bulgaria58 Posts
On April 27 2017 08:29 TheFish7 wrote: Wow, really great to see something like this popping up. I used to know the editor pretty much in and out but with 0 programming knowledge outside of that I probably won't be much help. If you have experience with StarEdit or SCMDraft triggers then this should be pretty straightforward for you. Also it can be your foray into real programming ^_^ | ||
|
integral
United States3156 Posts
| ||
|
Glenstorm
United States69 Posts
https://marketplace.visualstudio.com/items?itemName=glenstorm.langums If you haven't used Visual Studio Code before (a different program than standard visual studio), you can grab it here https://code.visualstudio.com/ Here it is on the first test program: ![[image loading]](http://i.imgur.com/1uYjeZ7.png) | ||
|
nlight
Bulgaria58 Posts
On April 27 2017 12:12 integral wrote: Forced player 8 computer and no preplaced units for p8 makes this unusable for a large majority of maps. Just a heads up. There needs to be at least one player whose death counts aren't messed with by having his units die. I picked player 8 pretty arbitrarily. Which one it is I'll make configurable (I guess using player 11 would be better?). Do you recommend using another player id by default? I'm pretty sure I can get rid of the requirement for having a Computer player at all which I'll do today. On April 27 2017 14:56 Glenstorm wrote: I took a little time and threw together a very very barebones vscode extension for langums Really cool, already using it! Thanks. | ||
|
integral
United States3156 Posts
There needs to be at least one player whose death counts aren't messed with by having his units die. I picked player 8 pretty arbitrarily. Which one it is I'll make configurable (I guess using player 11 would be better?). Do you recommend using another player id by default? I'm pretty sure I can get rid of the requirement for having a Computer player at all which I'll do today. It's probably your highest priority to allow choices here, because your project is 100% dead in the water unless you give mapmakers options. Default player 8 and even default p8 computer is fine, but forced is not -- and if that player has preplaced units and those units can die, then you either need to do conditional checks with triggers (e.g. if this unit is owned by p8, don't use it) or allow mapmakers to identify which units they want to use for death counts. The first thing I do when I'm making a map is make a list of the death counts I'm using and how they're being used, so this would not be unfamiliar. A simple input system to let users tell the program: 1. which player/force needs to own the death counts 2. which units not to use for death counts will solve the problem. This will allow users to introduce errors, yes, but it's worth it. One suggestion I have is to use the wiki list of units that can't be killed at all as default, and then allow users to expand these as necessary. Simpler maps won't need much beyond this, and advanced maps usually come with advanced mapmakers who need to be able to choose which units they're using. + Show Spoiler + Goliath Turret I dunno how you coded this, but hopefully it isn't too hard to change. Also consider that for a number of things I want to run death count calcs for every player on the map, not just player 8. I really need to be able to customize which player (and how many) owns any given trigger, and have death count variables stored for every individual player where necessary. This is pretty much the baseline for functionality. p8 only is pretty specific. | ||
|
nlight
Bulgaria58 Posts
- A Computer player is no longer necessary - The main triggers are emitted for Player 1 by default (can be changed with the --triggers-owner option) - The death counts of Player 8 are still used by default for storage, but can be changed now with the --registers-owner option. The first thing I do when I'm making a map is make a list of the death counts I'm using and how they're being used You kind of don't need to do this with LangUMS. The compiler will assign your variables to death counts automatically and more likely than not more efficiently than you can do by hand (at least in theory). Also consider that for a number of things I want to run death count calcs for every player on the map You can do this with the deaths() event handler, it allows you to check deaths for whatever player you want. Or you want to check for several players at once with some exclusion mask? I have something for this planned. A simple input system to let users tell the program: 1. which player/force needs to own the death counts 2. which units not to use for death counts 1 is done in the latest update. I'll consider doing 2 soon. your highest priority to allow choices Absolutely agree, let me know what you'd need. | ||
|
Freakling
Germany1533 Posts
On April 27 2017 18:28 nlight wrote: There needs to be at least one player whose death counts aren't messed with by having his units die. I picked player 8 pretty arbitrarily. Which one it is I'll make configurable (I guess using player 11 would be better?). Do you recommend using another player id by default? I'm pretty sure I can get rid of the requirement for having a Computer player at all which I'll do today. Really cool, already using it! Thanks. Unused players 9...11 would be obvious choices. Neutral P12 for the most part as well, probably (not quite sure how deaths of units from a player who left the game are counted). You could also add some flexibility by detecting players set to unused owner and/or inactive race and use all of their DCs as memory. Furthermore, there are a ton of unused units, which cannot even be placed in a map without crashing the game. These still have DCs, though, which can be used for any player as nothing can mess with them. DCs for invincible-by-default units, such as resources, powerups or Khaydarin Crystal Formations are also usually safe for grabs (unless there are destroy triggers for them). Only a limited selection of units will be used per player, to begin with, so ideally, I guess, you should add an advanced option to manually have map makers specify memory space themselves. Does your program parse units pre-placed for each player in a map when compiling the triggers in the map file? You could then just automatically assign every unit to memory which is neither pre-placed for a certain player in the map file nor has any create or give triggers for that player ; or, for maximum flexibility, but less safe, just add a debugger warning whenever a unit assigned as memory clashes with a pre-placed unit or create/give trigger. | ||
|
nlight
Bulgaria58 Posts
Unused players 9...11 would be obvious choices. Sadly I believe players 9 to 11's death counts can't be manipulated and they can't run triggers, otherwise that'd have been the obvious choice, yes. Neutral P12 for the most part as well, probably (not quite sure how deaths of units from a player who left the game are counted). I have no idea about this one, someone more experienced than me should pitch in and say if it would be ok to use Player 12's death counts as storage without messing up. You could also add some flexibility by detecting players set to unused owner and/or inactive race and use all of their DCs as memory. Great idea, definitely doing this. Only a limited selection of units will be used per player, to begin with, so ideally, I guess, you should add an advanced option to manually have map makers specify memory space themselves. I can do this pretty easily. Look forward to it soon. Does your program parse units pre-placed for each player in a map when compiling the triggers in the map file? Yes, it can. You could then just automatically assign every unit to memory which is neither pre-placed for a certain player in the map file, nor has any create or give triggers for that player, or, for maximum flexibility, but less safe, just add a debugger warning whenever a unit assigned as memory clashes with a pre-placed unit or create/give trigger. Another really good idea. I'll do this also. | ||
|
integral
United States3156 Posts
You kind of don't need to do this with LangUMS. The compiler will assign your variables to death counts automatically and most likely more efficiently than you can do by hand at least in theory. People have been making maps for a long time. Even if the compiler you wrote is really fucking cool, and it is, it's actually straight up insulting to think that it knows what I need better than I do. Efficiency is cool, but unless it's able to interface with the decade of work I've already done, it's really not gonna matter if it saves a few triggers here or there. Coming in with a necessarily disruptive approach is gonna put a lot of people off. I've already got a lot of completed maps. I constantly copy and paste code snippets and modules from other maps I've made. I'm not rewriting my already assigned death counts just so I can use your program to generate some triggers for me. I'm also not gonna rewrite all my already-written modules in your generator just because the compiler wants to assign stuff automatically. Your compiler doesn't know which death counts I'm already using, but I'll tell it if you let me. Maybe your tool is marketed more toward people who don't really make maps much, or have never really made a map before, or who are making a completely new map. If so, I'll back off a bit. But if you want established mapmakers to use this, it needs to be able to work with the things that people have already done. | ||
|
nlight
Bulgaria58 Posts
People have been making maps for a long time. Even if the compiler you wrote is really fucking cool, and it is, it's actually straight up insulting to think that it knows what I need better than I do. I understand. I come from a programming background where we're drilled that "the compiler knows better" from day 1, it's like a mantra (and it's mostly true given a decent enough compiler, which mine most likely ain't yet). Efficiency is cool, but unless it's able to interface with the decade of work I've already done, it's really not gonna matter if it saves a few triggers here or there. This is an unusual perspective for me. I did start with the assumption that langums maps will be made from scratch. Interfacing with already existing ones is definitely something I had not considered until now but I do realize it's important and I'm open to making it work. Could you give me a detailed explanation on how you imagine the interfacing between langums code and your existing triggers to work? Feel free to take some time and test out some stuff in langums to get a feel for it. Coming in with a necessarily disruptive approach is gonna put a lot of people off. I believe it is a small pain for major gains down the road. Do understand though that I care equally for people entering the community as well as experienced members. The tool must be suitable for both and decisions will be made which may not fully fit one side's point of view. Of course the opinion of experienced people weights a whole lot more in my decision process than someone who has never released a map. I'm not rewriting my already assigned death counts just so I can use your program to generate some triggers for me. I'm also not gonna rewrite all my already-written modules in your generator just because the compiler wants to assign stuff automatically. This is understandable. Let's see how to make it work. Your compiler doesn't know which death counts I'm already using, but I'll tell it if you let me. This will be a part of the "integration" facilities I can put in. I'm imagining something like global foo = <Player4, TerranMarine>; can map an already existing death count to a langums variable. Let me finish adding the basic features over the next few days and I'll see how to make this work. On a sidenote, can anyone point me to a list of AI scripts available. Their names should be 4 chars long. | ||
|
integral
United States3156 Posts
This is an unusual perspective for me. I did start with the assumption that langums maps will be made from scratch. That's a pretty huge assumption, glad you acknowledged it. Interfacing with already existing ones is definitely something I had not considered until now but I do realize it's important and I'm open to making it work. Could you give me a detailed explanation on how you imagine the interfacing between langums code and your existing triggers to work? Feel free to take some time and test out some stuff in langums to get a feel for it. Basically just let me tell the program what death counts it's allowed to use and what it isn't, and I'll use it like I currently use my own string generator -- copy and paste the output into my master trigger file. I also don't need (or want) it to auto-generate an .scx file, or even be linked to one. I write a lot of my triggers in modules, separately. An option to output as .txt directly from the script would be great for this. | ||
|
nlight
Bulgaria58 Posts
Basically just let me tell the program what death counts it's allowed to use and what it isn't This is next on my list after I'm done implementing the rest of the conditions & actions that are missing at the moment. I can do you one better though and have the compiler automatically figure out which death counts are unused by analyzing the .scx file. Let me know if that's a thing you'd want. I'll use it like I currently use my own string generator -- copy and paste the output into my master trigger file Would that be in scmdraft 2's trigger format? I'm not aware of StarEdit having a text format for triggers but I may be wrong. | ||
|
integral
United States3156 Posts
Sadly I believe players 9 to 11's death counts can't be manipulated and they can't run triggers, otherwise that'd have been the obvious choice, yes. Can confirm. I have no idea about this one, someone more experienced than me should pitch in and say if it would be ok to use Player 12's death counts as storage without messing up. Not really viable either, for several reasons. Lots of death count uses won't work properly with it. You could try to make it work but it'd be messy. From the quirks and nuances page: + Show Spoiler +
Would that be in scmdraft 2's trigger format? I'm not aware of StarEdit having a text format for triggers but I may be wrong. Yeah. People who want to use StarEdit (I guess they still exist???) can use the auto-generate feature. I can do you one better though and have the compiler automatically figure out which death counts are unused by analyzing the .scx file. Let me know if that's a thing you'd want. lol. It actually isn't, automation be damned, because I'll tell you what I'm gonna want to do: I'm gonna use your program to do some math stuff I've been needing to do for a while, and I'm gonna copy and paste it into my pre-existing maps. Even if it could read ALL the maps and figure out which ones weren't used, it's still better if I can just tell it to use the ones I want it to. On edit: This isn't a huge dealbreaker or anything. As it is I'd just use notepad to find/replace what your compiler came up with, which is more or less fine. I can also extract the .txt file myself by opening scmdraft2 afterwards. Analyzing the .scx file for unused death counts will be useful in other scenarios for sure. | ||
|
nlight
Bulgaria58 Posts
Player8, TerranMarine The compiler will use these death counters as internal registers and won't touch anything else. Keep in mind depending on how complex your calculations are you may need plenty of those. I'd say about 24 is the bare minimum required to operate give or take depending on how many functions/ events you have. You'll probably want to use the --preserve-triggers option also. Soon there will be an easy way to map langums variables to existing (external) death counters to allow for easy interaction both ways. Also I've added a section about integrating with existing maps to the README - https://github.com/AlexanderDzhoganov/langums#integration-with-existing-maps | ||
|
frogmelter
United States971 Posts
| ||
|
nlight
Bulgaria58 Posts
On April 28 2017 01:40 frogmelter wrote: Does this have RNG support? [ie. var bar = rand(0, 10) // returns a number from 0 to 10 inclusive at the bottom, exclusive at the top] It does now. The latest update includes the rnd256() built-in which returns a random value between 0 and 255. Use like: var foo = rnd256(); For now you can scale it yourself using division if you need a smaller range though it will give you a non-uniform distribution but that's maybe not an issue for your use case. | ||
|
Freakling
Germany1533 Posts
Thinking about this one step further, for units/buildings that can actually be built, it also need to be checked whether the player is actually 1. allowed (via unit settings) and able (has a production structure or worker via pre-placement or create/give trigger) to. at least in theory, acquire that unit. There are of course lots of ways around either allowing the player to have the unit (players has workers, but only unbuildable ground, blocked building exits, units come at prohibitive cost, unit building is just use as control buttons and the units are removed immediately upon spawn etc.) or having unit deaths actually affect death counters (if a known amount of units die in a controlled enough fashion, death counters can be adjusted for that). So ideally you should also allow players to force assign-death a specific death counter to a specific purpose. Means a lot more handiwork and potential errors by the map maker, but can also squeeze out that bit of extra memory and control... | ||
| ||
