Hey dudes, since PAC maps are taking off a bit i thought we should have a thread for the discussion of how to make them, and what changes to the PAC scripts are desirable or necessary.
so here we are! ;)
this is a quote of the basics of PAC mapping.
Quote from: stdout on October 27, 2014, 08:42:29 PM
teknotiss, to switch between building modes click on the icon that's off in space over on the left. If it's not there, then add a cprl core and attach Temp.crpl to it. Save and reload and then the button will appear.
To make the nullifers, just build them as usual, making sure each one is in range of a PZ. When you're done, go into the map and advance one frame ("N").
Now find a nullifer that you're sure is going to get killed early. I always choose one near a live emitter. Mouse over that and on your keyboard press "G". That triggers the script that will save all the nullifer positions and will then remove them. When you see all the nullifiers disappear then you know it worked.
Here are the notes I copied from stewbasic (they have been edited by me slightly):
QuoteHere are the steps to finalize the map:
* Increment one frame to make sure all the scripts have run their "once" sections.
* Save to one of the slots, eg 3, in case you want to come back and make more changes.
* Put your mouse over the trigger unit and press G. This will cause Temp.crpl to record the trigger unit, record all of Abraxis's units, reset game time and destroy the nullifiers and itself.
* Save to another slot, eg 2.
* Zoom out so that the build tab doesn't end up in the thumbnail image.
* Go to edit mode and finalize the map.
* Copy WorldEditor/MapName/save-2.cw3 to Finalized/MapName/MapName.cw3 (replacing the existing file).
* Play the finalized map as usual.
Another note: I think you can't move the totems without changing things in CRPL. So you may notice in my PAC maps, the totems are always in the exact same place. :)
If you have any trouble at all, feel free to send me the map that you've made and I'll look at it and troubleshoot problems and what-not. I can also finalize a map for you and send it back to you for you to check and submit to CS.
you
can just use a previous players map to get going (i did! ;)) and that quote should help.
feel free to ask me for clarity on it since i got it to work ok at least once.
but if hubs and stdout can collaborate on a better pre-finalising script that'd be really cool.
also it'd be nice if stdout or hubs could make a plain map (say 150x150 ish) with all the cores and their attached scripts laid out neatly (and visibly) for people like me to use a template.
feel free to post any questions or suggestions about PAC maps all you players only types, we want feedback on the mechanics from you too!
Hubs and stdout, please jump in here and deal with any coding questions, i hate coding so i don't want to have a headache while trying to explain the in's and out's.
cheers in advance dudes, and here's hoping there's lots of PAC maps to come! 8)
I would prefer a much smaller template, because last time when I resized a PAC map the map became unplayable. Something like the standard map size or miniland map size would work for me (I simply don't have enough inspiration in one week to fill a huge 150x150 map, and I prefer to skip sluggish endgames). I hope the totems positions aren't hard-coded in the scripts to allow easy moving, but I can live with fixed totem positions.
I have a map here called "blank_slate" that is a modest sized map and it's what I use when I start a new PAC map. It is an old version, though, and doesn't include the new updates like the bertha fix and the emitter size fix.
I'll try to get it updated and then upload it here.
Alright, I just finished tidying up my blank slate PAC map. You'll find it attached below. Just load it up in your projects area and you'll see a fairly barebones PAC map ready for your changes. It has incorporated all the updates I've made to the PAC code.
With this blank slate, anyone should be able to create a PAC map with very little work. You don't have to change any CRPL code. Just edit and then follow the finalization procedures outlined above. Ideally Hubs or someone will take this blank slate and tidy it up further and make the finalization process much easier.
Quote from: J on December 03, 2014, 12:53:39 PM
I would prefer a much smaller template, because last time when I resized a PAC map the map became unplayable. Something like the standard map size or miniland map size would work for me (I simply don't have enough inspiration in one week to fill a huge 150x150 map, and I prefer to skip sluggish endgames). I hope the totems positions aren't hard-coded in the scripts to allow easy moving, but I can live with fixed totem positions.
really? cos i had no issues i could see so far in massively increasing one map and shrinking by a few cells another.
can you remember what happened? if we can replicate it we may be able to strengthen the code
fair enough on the size though ;), perhaps a few template maps? 50x, 100x, 125x, 150x, and 200x maybe? until we can work out if resizing is always going to be an issue that is
Quote from: stdout on December 03, 2014, 04:14:57 PM
Alright, I just finished tidying up my blank slate PAC map. You'll find it attached below. Just load it up in your projects area and you'll see a fairly barebones PAC map ready for your changes. It has incorporated all the updates I've made to the PAC code.
With this blank slate, anyone should be able to create a PAC map with very little work. You don't have to change any CRPL code. Just edit and then follow the finalization procedures outlined above. Ideally Hubs or someone will take this blank slate and tidy it up further and make the finalization process much easier.
cool cheers dude!
now if hubs can add in, and clearly label the new stuff (i don't want the AC dropper in my maps yet, but i do like it, so i want to be able to disable it simply, and i want the emitter size fix too!), i'll try resizing up and down that map and see if it breaks.
if not i'll do a few size's of template and attach all of them to the first post and presto we will have a newbie PAC mapper go to spot!
Sizing the map up shouldn't be a problem. It's sizing it down that can be problematic. Cores can be trimmed away when the map gets smaller.
The blank slate map I included above it fairly small, should be fine for everyone's needs. You can make it bigger without problems. I don't know if it will work to move the totems.
Quote from: stdout on December 03, 2014, 04:33:34 PM
Sizing the map up shouldn't be a problem. It's sizing it down that can be problematic. Cores can be trimmed away when the map gets smaller.
The blank slate map I included above it fairly small, should be fine for everyone's needs. You can make it bigger without problems. I don't know if it will work to move the totems.
in that case having all the core's in the upper left corner should prevent sizing down, but if we just make the template quite small (50x50? ???) then it'll be fine to get bigger and i'm not sure we could make one smaller than 50x. a challenge for j or nextidea i guess? ;)
Having a small blank slate would be nice and I may give it a shot.
What I do when I want to make a small map, though, is I just use a small area of the overall map. My recent map (Texensis) is like that. The entire bottom half of the map is completely unused.
I've had issues with resizing as we'll. a lot of the cores are outside of the map boundary and get trimmer or the app crashes. Stdout I noticed you had that giant void space at the bottom of your map but I'm pretty sure that slows the game down. Each frame it's going to check all that space for moving creeper and whatever other checks that are done on each cell. That's why larger maps are almost always lag heir than smaller. That's been my experience anyway.
If anyone has any improvement ideas for PAC maps let's get those here as we'll. in my template map I want to capture any improvements we need so there there aren't a bunch of maps with different controls.
One I've seen already is right click to deselect.
Thanks for the info on map size impacting game lag. That makes a lot of sense and demonstrates the importance of getting a smaller map as a blank slate.
The right click deselect should be abandoned. It's used for panning and I don't think we should mess with that.
middle mouse to cancel would be good, but that's not as important as a simpler finalising process.
perhaps a core that says "press me before finalising" that we can click on once we've done the editing? that way it can run a frame, log all nullifier positions and set up for finalising (perhaps even finalise for us?)
Different people have different custom controls. (I use right click for deselection and left the middle mouse button with panning, though i have never used it)
I often wonder what Virgil makes of all this.
He knew he was turning something loose when he gave us the keys to his castle by including CRPL - but I doubt he ever thought it would be so popular, or peoe would take it so far.
Play as Creeper?
A year ago I wouldn't have thought it was even possible!
I'm making headway on the new template. It will basically be a single core in the top right corner of the map with nothing else present. You can build up the human base as much as you want and map out the terrain. I'll have hot keys to place starting emitters and spore towers. Totems can be built anywhere. The code will pick up each one at the start of the game. You should be able to resize the map without issues because the map will be mostly empty.
As long as you don't unpause the game you'll be able to select units and change their settings such as Bertha auto target or cannon target digitalis only or AC sprayer release excess AC or fighter/bomber targeting. Once you unpause the game or increment a frame by pressing "N" the temporary core will create all of the other cores and delete itself. At that point the map will be perfectly playable as a PAC map. As long as you save in edit mode you can unpause, play test, then reload to adjust, and repeat. Finalizing a map should simply be to increment by 1 frame, save, and finalize.
I also got the nullifier stuff squared away and have optimized Abraxis by completely rewriting it. It did a check to see if units trying to be rebuilt are in range of a relay or collector. It's actually unnecessary because the building will just sit unbuilt until it can connect to the network and start getting packets. This should massively speed up the game because it took a lot of time to check for connections. You'll also be able to add in nullifiers very easily in the code and they should always work correctly as long as they are near a PZ. It also lets you add units to start building at the start of the game easily such as additional berthas or thors.
Let me know what you all think about that process (current PAC authors and prospective ones too!). Is that easy enough? You should be able to knock out a PAC map without using CRPL. And if you want to add extra CRPL scripts to the gameplay I'll have a really easy and clear way to do it.
Wow, Hubs, what you're describing sounds -AWESOME-. I love it.
Sounds awesome Hubs. Take all the time you need to squash bugs because it will probably the template for a lot of maps.
agreed that this is a great effort from you hubs, once you're sure you've got it sorted let me know and i'll chuck it onto the top post! 8)
just had a thought, could we get a clear current target for the spore towers? if i use "t" i have to maually rest all towers, in the end game it'd be really useful to have "y" be clear spore targets and let them aim themselves at whatever units again.
here's hoping 8)
That would be a great feature.
You can select any spore tower and click on "T" and that causes all spore towers to aim for that spot.
To be able to select any spore tower and click "Y" to cause them all to go into auto-targeting mode would be perfect.
Love the idea about the "y" key for towers. That would definitely make the end game easier.
I'll check the code and see how easy that would be. I love the idea! So many times I've wanted that feature!
What does everyone think about adding a "Y" function for emitters to unsupport all emitters? There's been a few instances where this would have been nice in early game when I'm trying to push on two fronts.
Quote from: Hubs on December 05, 2014, 09:24:46 PM
What does everyone think about adding a "Y" function for emitters to unsupport all emitters? There's been a few instances where this would have been nice in early game when I'm trying to push on two fronts.
That'd be nice.
What I always do is if I have an emitter that is being supported, and I want it disconnected, I just destroy the emitter. That causes all the other emitters to drop back to normal mode. But then that leaves me having to wait a few seconds before I can build something new in its place.
So yes, a Y function for emitters would be good.
It would be very convenient if you could re-aim a spore tower by selecting the cross-hairs rather than having to scroll and find the tower. Much as you can re-aim a bertha either by selecting the bertha or its cross-hairs.
So I wanted to give everyone a quick update on the PAC template. It's coming along really nicely. The map finalization process works great and I have some help text on the map in edit mode to help. I've implemented the "Y" function for emitters and spore towers so that all emitters will stop supporting and return to normal mode, or if you have a spore tower selected all towers will go to auto target mode.
Quote from: RrR on December 06, 2014, 06:14:47 AM
It would be very convenient if you could re-aim a spore tower by selecting the cross-hairs rather than having to scroll and find the tower. Much as you can re-aim a bertha either by selecting the bertha or its cross-hairs.
I agree! That would be a very helpful feature. I think to do this (because you wouldn't always see the selection ring around the spore tower you selected) it would be helpful to show the spore target ring at the mouse so you know you're targeting for a spore tower. This would apply to normal spore tower targeting as well. I've already implemented it and it's kinda nice. I have it scaled down to about half the size of the normal target so it doesn't get in the way. For spore tower selection via its target, it makes sense to only have it work when the red target is showing (which occurs when the tower is at least 80% charged). That leads me in to another idea...
How would everyone feel about a toggle to always show spore tower targets? Right now it only shows when 80% charged, but I could create a toggle button (perhaps "U") that could switch between just showing when they're almost ready to fire and always on. Thoughts?
That would be nice, but it would only be for manual targeting, since Auto targeting should be like with Berthas, where only after a certain charge level it selects a valid target.
Thanks for making cross-hairs selectable.
Having the targeted spore towers always showing their target, and then changing colour/size shortly before they fire, would be a useful option.
It would also be useful to be able to pause all spore towers, to make synchronised spore firing easier.
Concur with all the above.
Quote from: RrR on December 06, 2014, 10:21:35 AMIt would also be useful to be able to pause all spore towers, to make synchronised spore firing easier.
I second this. Right now it's quite time consuming to make them all synchronize. Making that more efficient and intuitive for the player would be a most welcomed improvement.
How about a button that just resets all spore tower countdowns?
It seems like a lot of the ideas people are having could be solved by allowing easy picking of multiple items much like you can in the regular game. For example, double clicking on a spore tower would select all spore towers in the nearby area or using a selection box to select all items within it. I don't know if that is even possible, but it seems like that would solve a lot of the issues without having to create buttons or hotkeys for each type of action.
Quote from: mzimmer74 on December 06, 2014, 11:21:40 AM
It seems like a lot of the ideas people are having could be solved by allowing easy picking of multiple items much like you can in the regular game. For example, double clicking on a spore tower would select all spore towers in the nearby area or using a selection box to select all items within it. I don't know if that is even possible, but it seems like that would solve a lot of the issues without having to create buttons or hotkeys for each type of action.
I really like the idea but it would be difficult to implement. Double click to select near by towers plus shift click to add to selection plus drag box select. I can look at the code but no promises!
I think a button that resets all spore towers would be perfect.
Or maybe just set them all to match the tower with the most time. I'll try to do that.
Quote from: Hubs on December 06, 2014, 01:12:59 PM
Or maybe just set them all to match the tower with the most time. I'll try to do that.
perhaps a delay by "x" secs function for the towers? that could help a bit with spore assault timings.
not critical though, multi select is more of a wish! ;)
A button that resets the timer on all the spore towers wouldn't help they way I play much.
When I synchronise the spores, I launch the spore furthest from target first, then launch the others as this spore passes by their tower, so the spores all reach their target at (ideally) the same time.
Synchronised landing rather than synchronised launching. Yes I micromanage.
If this could be automated, it would save a lot of fiddling (but I accept that it is much more work than resetting the timers). Just having an all tower pause button would save half the effort.
Selection box as a whole is easy to implement if you have 2 functions, button press down, and button release, just take the coordinates of the first and the second, and you have a box, but then there are also specific types of units, so maybe with priority? If you have structures type x and y, select only x (with higher priority), which may be a bit harder, i have coded very little, so i don't know if there are GetUnitsWithinRectangleCoords functions or anything like that, well only GetUnitsWithinRange or something, but that's for a circle.
Hm, it will probably be too complex (both to implement and use), but a button to both reset timers and target that spot (T style), but with smart timer resets( i.e the furthest becomes 20 seconds, and the rest depending on the distance the spores have to travel so they land at the same time (within 1 second accuracy if the timer is int based), so i'd guess up to about 30-40 seconds depending on map size). Like how RrR does it manually.
Technically this should be simple to implement, but it will probably confuse the new players too much to have 5 buttons doing select all and do something.
Somehow get the tower the farthest from the target point and set it's distance to a variable (let's say BaseDistance) and BaseTimer, then for every selected tower (or all if selection never gets implemented) and set the timer to BaseTimer+(BaseDistance-CurrentDistance)/SporeSpeed, where BaseTimer is the timer for the first spore launch (currently set to 20-19 seconds), SporeSpeed is the current spore speed and CurrentDistance is the distance between the specific spore tower and the target point.
Quote from: DestinyAtlantis on December 06, 2014, 01:58:31 PM
Selection box as a whole is easy to implement if you have 2 functions, button press down, and button release, just take the coordinates of the first and the second, and you have a box, but then there are also specific types of units, so maybe with priority? If you have structures type x and y, select only x (with higher priority), which may be a bit harder, i have coded very little, so i don't know if there are GetUnitsWithinRectangleCoords functions or anything like that, well only GetUnitsWithinRange or something, but that's for a circle.
Hm, it will probably be too complex (both to implement and use), but a button to both reset timers and target that spot (T style), but with smart timer resets( i.e the furthest becomes 20 seconds, and the rest depending on the distance the spores have to travel so they land at the same time (within 1 second accuracy if the timer is int based), so i'd guess up to about 30-40 seconds depending on map size). Like how RrR does it manually.
Technically this should be simple to implement, but it will probably confuse the new players too much to have 5 buttons doing select all and do something.
Somehow get the tower the farthest from the target point and set it's distance to a variable (let's say BaseDistance) and BaseTimer, then for every selected tower (or all if selection never gets implemented) and set the timer to BaseTimer+(BaseDistance-CurrentDistance)/SporeSpeed, where BaseTimer is the timer for the first spore launch (currently set to 20-19 seconds), SporeSpeed is the current spore speed and CurrentDistance is the distance between the specific spore tower and the target point.
I agree that it wouldn't be that hard to implement a selection box by itself but there is so much going on with other mouse interactions with the build buttons, digitalis placement, tower building, fields, targeting, and supporting. Without very careful programming you would end up with "collision" which means you unintentially are triggering multiple things at once such as targeting and selecting towers at the same time. Someone else is welcome to try to implement that if they have the patience for it :)
For the spore targeting synchronized landing of spores should be possible with the method you described but it could get complex with large maps in which it takes over 20 seconds to hit the target. Maybe 10% of the hardcore PAC players would use it effectively. You also start getting into way too many commands with all this automated micro management. Players gotta play a little too :)
Ok, so here's where I'm at with the template:
For creating a map, it's extremely simple now: basically create the map then play. It converts to a PAC map after one frame, so you can keep it paused and press "N", then save and publish. For testing just make sure you don't save after it converts, although I have a really easy way to convert it back to an editable state. I also added shortcuts "U" for emitters and "I" for Spore Towers which will create them while you're building the map.
For the actual game added "Y" for emitters to stop supporting and all go back to normal mode, or "Y" for spore towers to all go to auto target mode.
When a spore tower is selected you will now have a smaller version of the target circle under the mouse. This should help to indicate that you have a spore tower selected and that you can set a new target.
When a spore tower's target is shown (In red when it's about to fire) and you don't already have a tower selected, you can click on the red target. This will select the tower for you and you can set a new target (A lot like berthas in the normal game)
I also completely rewrote Abraxis, which is the AI that rebuilds stuff, so that it runs about 10 times faster. It used to check for connections and a bunch of other stuff but I found a much simpler way to do it. This has two main effects: (1) your game should run with a lot less lag on larger maps and (2) buildings will rebuild much faster (especially on large maps). The old script would only attempt to rebuild 10 buildings per frame. The new one attempts 25 per frame.
Temp.crpl has also been completely rewritten. On the template you start with a blank map and one core that has Temp.crpl. When the map loads it completely removes all PAC cores (other than placed towers) so that you should never have an issue with finalizing a map. If you accidentally save your map in PAC mode, all you have to do is add a core, give it Temp.crpl, then save and reload your map. It will completely return it back to edit mode. This script will also display the steps to make a PAC map in game in edit mode.
I also plan on including a ReadMe document that will completely explain how to create a PAC map. I'll also include instructions on changing some of the parameters, such as emitter amount, and instructions for including additional crpl scripts to the gameplay for new scripted events.
Wow, this sounds amazing Hubs! I guess I'll have to get back into this... wonder what kind of goodies I can make with PAC maps... :P
Outstanding, Hubs. You're bringing an early Christmas present for many of us.
Quote from: Hubs on December 06, 2014, 09:49:12 PM
Ok, so here's where I'm at with the template:
Spoiler
For creating a map, it's extremely simple now: basically create the map then play. It converts to a PAC map after one frame, so you can keep it paused and press "N", then save and publish. For testing just make sure you don't save after it converts, although I have a really easy way to convert it back to an editable state. I also added shortcuts "U" for emitters and "I" for Spore Towers which will create them while you're building the map.
For the actual game added "Y" for emitters to stop supporting and all go back to normal mode, or "Y" for spore towers to all go to auto target mode.
When a spore tower is selected you will now have a smaller version of the target circle under the mouse. This should help to indicate that you have a spore tower selected and that you can set a new target.
When a spore tower's target is shown (In red when it's about to fire) and you don't already have a tower selected, you can click on the red target. This will select the tower for you and you can set a new target (A lot like berthas in the normal game)
I also completely rewrote Abraxis, which is the AI that rebuilds stuff, so that it runs about 10 times faster. It used to check for connections and a bunch of other stuff but I found a much simpler way to do it. This has two main effects: (1) your game should run with a lot less lag on larger maps and (2) buildings will rebuild much faster (especially on large maps). The old script would only attempt to rebuild 10 buildings per frame. The new one attempts 25 per frame.
Temp.crpl has also been completely rewritten. On the template you start with a blank map and one core that has Temp.crpl. When the map loads it completely removes all PAC cores (other than placed towers) so that you should never have an issue with finalizing a map. If you accidentally save your map in PAC mode, all you have to do is add a core, give it Temp.crpl, then save and reload your map. It will completely return it back to edit mode. This script will also display the steps to make a PAC map in game in edit mode.
I also plan on including a ReadMe document that will completely explain how to create a PAC map. I'll also include instructions on changing some of the parameters, such as emitter amount, and instructions for including additional crpl scripts to the gameplay for new scripted events.
cool dude! that is great, we'll whack that completed map at the front of this thread (or i'll start a new one and see if we get it stickied)
i particularly like the bertha style target selecting. was gonna ask but forgot! ;)
and the simplified setup and also seemingly simple resetting of the PAC scripts is excellent.
code monkey of the month award for you dude!
runners, and what to do about them?
i was sort of thinking we could have runners nests on ore mines, but it'd mean no ac for abraxis if a mapper didn't want runners ???
and i do want them sometimes, but not spawning from towers or emitters.
what to do? ::)
suggestions?
Aside from a fifth button for runner nests that can be disabled by the map maker?
Quote from: DestinyAtlantis on December 08, 2014, 02:59:49 PM
Aside from a fifth button for runner nests that can be disabled by the map maker?
i was under the impression that'd be tricky, but it would be the simplest solution yes ::) ;)
My position on runners is that while they can be used a little bit, they are not as useful as you'd hope. They only travel on live digitalis, and by the time you get that near a human target, you're already in pretty good control of the situation. So the runners just end up running around, not disabling much, and not giving much benefit to the player.
I'm with stdout in this one. They aren't really useful. If we could think of a way to make them help the player I think I could add it as an optional setting. Really the range of their stun is the biggest issue. Can that be changed in crpl? Or has there been a crpl runner made?
Quote from: Hubs on December 08, 2014, 06:39:46 PM
I'm with stdout in this one. They aren't really useful. If we could think of a way to make them help the player I think I could add it as an optional setting. Really the range of their stun is the biggest issue. Can that be changed in crpl? Or has there been a crpl runner made?
i dunno about runner scripts, if the could be targeted perhaps?
maybe if they could seek to get to a point that you place like a spore tower?
Sounds like a phase 2 project. We don't want to get bogged down with scope creep (pun intended)
A CRPL runner nest that allows you to target points with digitalis that makes all the runners go there.
Quote from: Asbestos on December 08, 2014, 07:21:14 PM
A CRPL runner nest that allows you to target points with digitalis that makes all the runners go there.
Seconded.
Template is mostly done now. Working on full instructions and going to publish a map soon, plus a surprise for everyone :)
Quote from: Hubs on December 06, 2014, 09:49:12 PM
I also completely rewrote Abraxis, which is the AI that rebuilds stuff, so that it runs about 10 times faster. It used to check for connections and a bunch of other stuff but I found a much simpler way to do it. This has two main effects: (1) your game should run with a lot less lag on larger maps and (2) buildings will rebuild much faster (especially on large maps). The old script would only attempt to rebuild 10 buildings per frame. The new one attempts 25 per frame.
btw I originally didn't check connections (http://knucklecracker.com/forums/index.php?topic=14499.15), but I found that Abraxis became slow to respond once a lot of units were dead; checking ~40 dead units which were connected to something alive was faster than checking all ~200 dead units even with the extra connection logic. Does it still respond faster near endgame?
hey man, you've been quiet a while, welcome back sort of thing! :)
what do you think about the new changes etc? 8)
Quote from: stewbasic on December 13, 2014, 04:27:24 PM
Quote from: Hubs on December 06, 2014, 09:49:12 PM
I also completely rewrote Abraxis, which is the AI that rebuilds stuff, so that it runs about 10 times faster. It used to check for connections and a bunch of other stuff but I found a much simpler way to do it. This has two main effects: (1) your game should run with a lot less lag on larger maps and (2) buildings will rebuild much faster (especially on large maps). The old script would only attempt to rebuild 10 buildings per frame. The new one attempts 25 per frame.
btw I originally didn't check connections (http://knucklecracker.com/forums/index.php?topic=14499.15), but I found that Abraxis became slow to respond once a lot of units were dead; checking ~40 dead units which were connected to something alive was faster than checking all ~200 dead units even with the extra connection logic. Does it still respond faster near endgame?
I have it set to check 25 units per frame to prevent lagging. When the snapshot is taken it puts all the units in a single list instead of tracking the three states of alive, building, and dead. As it cycles through the list it just checks if the space is clear with no creeper, building, or grown digitalis. If nothing is there it builds the unit. Most PAC maps have 200-400 units so every building gets checked every 8-16 frames. So the build speed will be consistent throughout the game. The script is pretty light so it could tolerate checking 50 or 100 units per frame but I find that a lot of the time a unit will start building and get destroyed immediately because the cell next to it has creeper. That creates a rapid explosion every frame. The new script doesn't do this quite as badly because it doesn't rebuild every frame.
Also stewbasic, I gotta say great job on the PAC scripts. Most people probably won't get into the crpl much, let alone understand it, but I went through everything and it's really good stuff. You'll have the primary credit in the template I'm publishing soon.
Thanks Hubs and teknotiss! I'm on vacation so catching up a bit on forums and maps etc :P. It's great to see all the improvements being made. I'm looking forward to trying out the template; it sounds like finalizing will be a lot smoother :D.
I like the idea of building runner nests on ore deposits, since they're useless to the creeper at the moment. I was thinking that the runner nest could consume 1 creeper to produce a runner, and do so once per frame up to some cap on the number of runners. That way the rate at which you pump out runners is determined by how fast you can get creeper onto the nest.
stewbasic, I want to say thank you to you for providing this initial code base. It has given thousands of hours of enjoyment to a lot of people.
Quote from: stdout on December 14, 2014, 07:41:08 AM
stewbasic, I want to say thank you to you for providing this initial code base. It has given thousands of hours of enjoyment to a lot of people.
I'm glad people are enjoying them, and thanks to you guys for making more of the maps, especially Hubs for all the work on the template.
Quote from: stewbasic on December 14, 2014, 07:30:38 PM
Quote from: stdout on December 14, 2014, 07:41:08 AM
stewbasic, I want to say thank you to you for providing this initial code base. It has given thousands of hours of enjoyment to a lot of people.
I'm glad people are enjoying them, and thanks to you guys for making more of the maps, especially Hubs for all the work on the template.
I mainly did it to fuel my PAC addiction :)
Is this the right place for PAC enhancement suggestions? Because I've got a couple!
1) I agree with stdout that runners are tough to utilize, as I experienced on his map with spore towers spawning one per spore launched. Is it possible, through CRPL, to get the target of where a spore lands? Perhaps spawn a runner at the target if the spore lands on live digitalis? Maybe even briefly energize a radius of digitalis (if it's not on a PZ, of course, to prevent exploits)? Have a "charge" mode like emitters, where spores fire half as often, but spawn a runner/live digi on land?
2) Use totems to spawn gravity wells, exactly like how forges work? Not sure how to handle the cooldown for this, but it sure would be neat to augment the Field tool.
Quote from: Stave on December 15, 2014, 07:20:01 PM
Is this the right place for PAC enhancement suggestions? Because I've got a couple!
1) I agree with stdout that runners are tough to utilize, as I experienced on his map with spore towers spawning one per spore launched. Is it possible, through CRPL, to get the target of where a spore lands? Perhaps spawn a runner at the target if the spore lands on live digitalis? Maybe even briefly energize a radius of digitalis (if it's not on a PZ, of course, to prevent exploits)? Have a "charge" mode like emitters, where spores fire half as often, but spawn a runner/live digi on land?
2) Use totems to spawn gravity wells, exactly like how forges work? Not sure how to handle the cooldown for this, but it sure would be neat to augment the Field tool.
I really like the gravity well idea. I could see it as a special ability with a cool down that speeds up as you get more emitters.
I just want to echo the shout-out to Stewbasic for the original idea, and to all of you for picking it up and running with it. PAC maps are absolutely great to play - they have so much replayability (if that's a word :D) and give me hours of fun. Thank you all for the hard work.
A gravity well might act as a very efficient bertha-bait. This might be useful, but might not be what you wanted.
hmm a reverse singularity could be very useful, perhaps as a creeper powered artifact or something?
I made a few tweaks to the template (attached) to make finalization even smoother:
* PAC conversion is triggered by clicking the help text and confirming a dialog. This means you can play in "human mode" without removing the temp core.
* Nullifier placeholders can be placed by pressing 'J', removing the need to edit Abraxis.crpl (and can be changed in edit mode to other unit types)
* All conversation text is near the top of GameFlow.crpl to make it easier to edit.
* Starting conversation shows at map start instead of after 1 frame.
I updated README.crpl to reflect these changes.
I'm still working on improving unit selection (mainly supporting selection of multiple units). I'll merge my changes in with the template once that's done.
Quote from: stewbasic on December 18, 2014, 05:19:24 PM
I made a few tweaks to the template (attached) to make finalization even smoother:
* PAC conversion is triggered by clicking the help text and confirming a dialog. This means you can play in "human mode" without removing the temp core.
* Nullifier placeholders can be placed by pressing 'J', removing the need to edit Abraxis.crpl (and can be changed in edit mode to other unit types)
* All conversation text is near the top of GameFlow.crpl to make it easier to edit.
* Starting conversation shows at map start instead of after 1 frame.
I updated README.crpl to reflect these changes.
I'm still working on improving unit selection (mainly supporting selection of multiple units). I'll merge my changes in with the template once that's done.
oh cool, cheers dude, maybe worth holding off a bit on my next one til you've added those unit selection changes? good job man 8)
Quote from: teknotiss on December 18, 2014, 05:48:43 PM
oh cool, cheers dude, maybe worth holding off a bit on my next one til you've added those unit selection changes? good job man 8)
Sure, I should have it ready sometime this weekend.
Christmas really is coming early this year.
Hey stewbasic, how hard would it be so that when you press J it shows the nullifier but then doesn't let you place it if you're out of range of a PZ? One thing I've found when making these maps is I often create the nullifier just outside of the range of the PZ.
In the regular gameplay (non PAC) it shows the circle radius so you can easily see where the nullifier can legally be placed. A similar functionality sure would be helpful. But it doesn't seem like it would be an easy fix... I figured it doesn't hurt to at least mention this as a wishlist item. :)
Quote from: stdout on December 18, 2014, 09:24:29 PM
Christmas really is coming early this year.
Hey stewbasic, how hard would it be so that when you press J it shows the nullifier but then doesn't let you place it if you're out of range of a PZ? One thing I've found when making these maps is I often create the nullifier just outside of the range of the PZ.
In the regular gameplay (non PAC) it shows the circle radius so you can easily see where the nullifier can legally be placed. A similar functionality sure would be helpful. But it doesn't seem like it would be an easy fix... I figured it doesn't hurt to at least mention this as a wishlist item. :)
I usually select the nullifier from the "vanilla" build menu to see the circle radius before pressing J. But it should be possible to do something in CRPL. I wouldn't want to completely prevent placing them out of range in case someone wants a different unit placeholder (or just places PZ's afterwards).
Quote from: stewbasic on December 18, 2014, 09:34:30 PMI usually select the nullifier from the "vanilla" build menu to see the circle radius before pressing J.
Smacking my head. Of course, that's the perfect solution. I'll do that from now on and will retract my request. :)
I just released a new map based on the latest template. What a pleasure that was! Thanks to both of you (stewbasic and Hubs) for your great work on this. What used to be a hugely painful process is now smooth and enjoyable. I'm already thinking of ideas for future maps.
Creating a PAC map is so easy now that I might even upload one soon ;D
(however I need to come up with a good name first)
What's the right way to handle forge upgrades now?
I can build the forge but how do I give it the numbers so I can upgrade items? Do I have to connect totems to his network and let it run for a while, then go back and erase the timer? That's the only solution I can currently come up with.
Edited to add: the above idea works fine but if you already have a map with lots of emitters and spore towers it can be hassle to run the map for a while to build up forge strength. If there was a good solution it would be more convenient for later, but this is not a priority item.
Quote from: stdout on December 19, 2014, 02:23:45 PM
What's the right way to handle forge upgrades now?
I can build the forge but how do I give it the numbers so I can upgrade items? Do I have to connect totems to his network and let it run for a while, then go back and erase the timer? That's the only solution I can currently come up with.
Edited to add: the above idea works fine but if you already have a map with lots of emitters and spore towers it can be hassle to run the map for a while to build up forge strength. If there was a good solution it would be more convenient for later, but this is not a priority item.
This isn't a full solution, but it's what i did for a recent PAC map. Just add resource packs with a few thousand aether and plop siphons on them. Siphons work way faster than totems, so you can get 1,000 aether pretty quickly with a handful of siphons going - then when you have enough, just remove the siphons and resource packs. I've scoured the wiki for a way to set upgrade levels or aether level, but i haven't found anything yet. As far as dealing with a map that already has emitters and spore towers, i would just remove them, then add 'em back - it's simple to add them with U and I in the PAC template.
Great idea on the siphon. :)
Regarding the thumbnails, I'd recommend fully zooming in and moving the camera to the bottom of the map (so that the panels are below the map). This also minimizes the text on the spore towers.
Quote from: J on December 20, 2014, 06:32:20 AM
Regarding the thumbnails, I'd recommend fully zooming in and moving the camera to the bottom of the map (so that the panels are below the map). This also minimizes the text on the spore towers.
I'll include this change in the next version. I assume the thumbnail rendering is otherwise independent of zoom level?
stewbasic, while I have you here, can I ask you a question?
I am currently working on an "epic" map that's gigantic and intended to force the player to have to go around the edges and build up a powerful network of spores and emitters before finally taking the way over-powered central area. My map is basically done and I think it's one of my best, but it is crazy slow. There's so many things going on that even at 4x speed, it is playing at less than real time.
Are there any features that you think I can disable to make it go faster? One thought that I had was to turn off the nullifier building code, but I'm not even sure if that'll make a big difference.
So do you have any ideas of where the actual bottlenecks in the code might be so I can optimize around them?
Edited to add: I changed Abraxis.crpl to only check 1 unit per frame instead of 10 and that seems to have a pretty good impact on speed. I'm not sure if there's anything else I can do.
Reducing the number of abraxis units could help so the game doesn't have to process as much each frame. So instead of having a field of 40 reactors just put 4 on PZs. Same would go for a bunch of beams: 10 regular could just be 2 or 3 on PZs. the rest of the scripts they don't really do much each frame - just a couple of simple checks. Maybe the Bertha boost could run less often?
Good advice, thanks Hubs!
Another way you could speed up gameplay is to make emitters product more creeper and the spore towers fire faster. Then give Abraxis some upgrades to fire rate, build speed, and packet speed. Then to make the creeper flow faster use SetCreeperFlowRate and SetCreeperFlowRateOnDigitalis.
Mainly reducing the number of Abraxis units as Hubs said. At some point on my first map (when I had ~60% of the map covered by units) I turned off all the scripts and found that an excessive number of units caused a significant slow down without any CRPL (at least on my computer). Figuring out how costly each script is and optimizing is on my TODO list...
Great info. Thanks to you both.
How about changing the default number of units to check each frame to something like 4? On small maps you don't need each unit to be checked multiple times every second and on big maps 10 might slow it down too much (as any optimisation is helpful).
OK, here is the version with multiple unit selection. I took a closer look at how vanilla units behave and tried for more consistency (especially between berthas and spore towers). I think these are all the changes I made:
* Shift+click to add/remove unit to/from selection.
* Double click to select nearby units of same type.
* Drag box to select units in rectangle (hold shift if units are already selected).
* 'O' to expand selection to all units of the same type.
* Setting emitter support or spore tower target deselects unit.
* Rather than cycling, 'E' sets emitter/tower to normal/autotarget, 'R' sets to burst/wait (does not deselect unit).
* 'T' and 'Y' controls removed as they are obviated by 'O'.
* Spore target icon and line mimic berthas with two exceptions:
- if multiple towers target 1 cell, selecting by target will select all of them instead of just 1 (I think this makes more sense)
- line to target doesn't show on mouseover (too much trouble)
* Per J's suggestion, activating PAC mode zooms in on the bottom of the map.
I tried to eek out all the corner cases, but please let me know if I missed any and some bug pops up.
Would it work to just copy all the .crpl scripts from this new map over into the scripts directory of the one I was working on? (Tested and the answer seems to be yes.)
I love the new controls. The in-game help needs to be re-written to explain the new controls. This will represent a learning curve to the hundreds of fans of the PAC games. They are used to the old controls. I have a map I want to finish and publish to CS in the next day or so. If you are planning further large changes, though, I'll wait until we have a fairly finished rewrite before I proceed.
How do you change the help screen? I can't find it anywhere in the scripts.
The ingame help is in Builder.crpl.
It's also in DigitalisBuilder and FieldBuilder for those 2 buttons.
Here's my thoughts on controls:
Would it hurt to leave T and Y in? These are super useful and although they would now be redundant I think they would still be faster than the new controls. Plus players are very used to them so it would keep some consistency between old and new PAC maps.
Does it allow selection of emitters and towers at the same time? Sry haven't been able to test the file yet. If so how do controls work then?
Can you still put spore towers in delay mode with the changes to E and R?
For selection of towers by the target, will it only select the towers that show a red target or any targeting the same cell?
How about making the number of units checked by a abraxis dynamic so that large maps with many units check less units and smaller maps check more? That way map makers don't have to worry about optimization issues.
I like the changes so far! I'm going to hold off on my PAC series until this is done so all the maps can be consistent.
Good point about the help text. I'm updating that now.
Quote from: Hubs on December 21, 2014, 01:59:01 PM
Would it hurt to leave T and Y in? These are super useful and although they would now be redundant I think they would still be faster than the new controls. Plus players are very used to them so it would keep some consistency between old and new PAC maps.
Secretly I had in mind to free those keys up for some other use :P. Those are good points though... I'll have a go at adding them back.
Edit: What should 'T' do if multiple emitters are selected?
Quote from: Hubs on December 21, 2014, 01:59:01 PM
Does it allow selection of emitters and towers at the same time? Sry haven't been able to test the file yet. If so how do controls work then?
Yes. Then 'O' selects all units (same as vanilla). 'E' and 'R' set each tower to its respective mode. Clicking on an emitter will target selected spore towers there and set selected emitters to support. It's also set up to allow more unit types (*cough* runner nest *cough*).
Quote from: Hubs on December 21, 2014, 01:59:01 PM
Can you still put spore towers in delay mode with the changes to E and R?
That's what 'R' does.
Speaking of which, there is one thing you could do before which is less convenient now. If you want to synchronize a bunch of spore towers to hit the same spot at the same time, before you could target them all, pause them all, then switch them back to target mode at the right time. Now pausing the tower forgets the target, so you have to select the target again when you want them unpaused. I was thinking about using 'T' for "switch back to target mode, using the last set target".
Another change I was considering (I think someone suggested it a while ago) was to allow spore towers to support each other. Maybe spore health could be proportional to number of supporters, removing the need to synchronize towers. Would that be overpowered?
Quote from: Hubs on December 21, 2014, 01:59:01 PM
For selection of towers by the target, will it only select the towers that show a red target or any targeting the same cell?
This changed a little. A spore tower now always shows its target as long as a target is set (but in autotarget it doesn't set a target until 80% charged). The target is white if the tower is unselected, otherwise red. This is all consistent with how berthas behave.
To answer your question, all towers targeting that cell are selected regardless of their charge amount.
Quote from: Hubs on December 21, 2014, 01:59:01 PM
How about making the number of units checked by a abraxis dynamic so that large maps with many units check less units and smaller maps check more? That way map makers don't have to worry about optimization issues.
I'll probably do something like this, but I want to look more closely at where the time is being spent. I suggest not to hold off on a map waiting for this change.
I updated the in-game help in Builder.crpl. The updated file is attached if you want to use it.
Quote from: stewbasic on December 21, 2014, 06:10:10 PM
What should 'T' do if multiple emitters are selected?
How about splitting support between the selected emitters? So if you have 10 emitters and two selected (meaning 8 are unselected) and you press T, each of the selected emitters would get 4 other emitters supporting them. That would be very helpful for a situations where you're pressing on two fronts. Other alternative would be to just support the last built emitter or have it do nothing.
Quote from: stewbasic on December 21, 2014, 06:10:10 PM
Yes. Then 'O' selects all units (same as vanilla). 'E' and 'R' set each tower to its respective mode. Clicking on an emitter will target selected spore towers there and set selected emitters to support. It's also set up to allow more unit types (*cough* runner nest *cough*).
Would it make more sense that if you have emitters and towers selected, then click on an emitter that it would only support and not set a spore target? I can't think of many cases where you would want a spore tower targeting an emitter.
And runner nest = awesome! This has been discussed before and the range of the runners seems to be a concern as they would only be able to be useful in areas that are already taken. Also, a cap per runner nest should be used so there aren't hundreds of the little guys bogging down the map. For balance purposes, maybe 10 or 20 per nest? How about different modes? E and R could toggle between fast & weak vs. slow & strong?
Quote from: stewbasic on December 21, 2014, 06:10:10 PM
Speaking of which, there is one thing you could do before which is less convenient now. If you want to synchronize a bunch of spore towers to hit the same spot at the same time, before you could target them all, pause them all, then switch them back to target mode at the right time. Now pausing the tower forgets the target, so you have to select the target again when you want them unpaused. I was thinking about using 'T' for "switch back to target mode, using the last set target".
Does pausing the tower have to forget the target? Did this break because of recent changes?
Quote from: stewbasic on December 21, 2014, 06:10:10 PM
Another change I was considering (I think someone suggested it a while ago) was to allow spore towers to support each other. Maybe spore health could be proportional to number of supporters, removing the need to synchronize towers. Would that be overpowered?
I really like this idea, but it could get overpowered very easily. Spore health is the biggest concern to me, but payload makes sense to stack. Maybe it could have diminishing returns or something for spore health. So a normal spore has 1 health. With 1 tower supporting it could have 1.5 health, then 2.0 health for 2 towers supporting. If you implement this, can you create some variables easily changeable at the top of the script so that map authors can tune it to their map?
Quote from: stewbasic on December 21, 2014, 06:10:10 PM
This changed a little. A spore tower now always shows its target as long as a target is set (but in autotarget it doesn't set a target until 80% charged). The target is white if the tower is unselected, otherwise red. This is all consistent with how berthas behave.
This makes a lot of sense, although the red "about to launch" indicator was super helpful, especially to re-target towers that are about to launch.
Quote from: stewbasic on December 21, 2014, 06:10:10 PM
To answer your question, all towers targeting that cell are selected regardless of their charge amount.
Cool, that makes a lot of sense. Does that work with multiple unit selection? So if I have towers selected already, then shift+click a target, will that add towers to my unit selection?
Quote from: stewbasic on December 21, 2014, 06:10:10 PM
Quote from: Hubs on December 21, 2014, 01:59:01 PM
How about making the number of units checked by a abraxis dynamic so that large maps with many units check less units and smaller maps check more? That way map makers don't have to worry about optimization issues.
I'll probably do something like this, but I want to look more closely at where the time is being spent. I suggest not to hold off on a map waiting for this change.
The victory check runs every frame. It starts by running through each unit on the map, but stops if it finds an abraxas small unit so it doesn't waste time looking at the rest of the units. You could shave off time by looking at this less – maybe every 10 or 30 frames.
I also forgot to put in breaks in Abraxis when checking if the unit is alive and for nullifier build conditions. That could shave a little time off. That reminds me, it would be awesome to add in build conditions to work on nullifiers on PZs.
Another thought I had, if you really want to mimic the normal game with interface and controls, would be to add a unit selected build tab with the E and R modes as options. Like when you select a cannon in the normal game you have the different target priority options.
in this map
http://knucklecracker.com/forums/index.php?topic=17675.0
i can no longer use e OR r to switch emitter mode. :o
i'm used to using just r for it and it's REALLY irritating to have to use two separate keys.
can we have that utility put back in please? really really please?
Hm, i don't think anyone has done this before, but why not have PZ nulifiers?
stewbasic, assuming you haven't changed Abraxis a ton, this should make it so nullifiers correctly build in PZs. (PZ'd nullifier has a range of 20 right?)
Old Code in Abraxis.crpl:
# Make sure an emitter or spore tower is in range if type is a nullifier
if(<-Type "NULLIFIER" eq)
0 ->EnemyCount
GetEnemyUnitsInRange(<-X <-Y 9.99) 0 do
if(GetUnitAttribute(CONST_NULLIFIERDAMAGES)) # If a unit is found that can be damaged by a nullifier, increment the enemy count
<-EnemyCount 1 add ->EnemyCount
endif
loop
if(<-EnemyCount eq0) # If no nullifiable units found, don't rebuild the nullifier
"no" ->Rebuild
endif
endif
Updated code:
# Make sure an emitter or spore tower is in range if type is a nullifier
if(<-Type "NULLIFIER" eq)
0 ->EnemyCount
9.99 ->Range
# Determine if nullifier is on PZ
GetUnitsInRange(<-X <-Y 0) 0 do
if(GetUnitType "POWERZONE" eq)
19.99 ->Range
endif
loop
GetEnemyUnitsInRange(<-X <-Y <-Range) 0 do
if(GetUnitAttribute(CONST_NULLIFIERDAMAGES)) # If a unit is found that can be damaged by a nullifier, increment the enemy count
<-EnemyCount 1 add ->EnemyCount
endif
loop
if(<-EnemyCount eq0) # If no nullifiable units found, don't rebuild the nullifier
"no" ->Rebuild
endif
endif
hey PAC coders, there's been some talk, from me included, about the new keys for commands.
can i ask why "o"?
since we were all using "t" anyway, and "t" is near the other function keys most use, while "o" is on the otherside of the key board.
also can i ask why the extra clicking for support all emitters?
as far as i can tell i need to select an emitter then press "o" then select the emitter i want to be supported?
this is unnecessary, can't we just have press "o" on the desired emitter?
better yet put it back to "t" and then we can stop changing things for the players.
unless i missed something and "t" is reassigned, is it? ???
Tek, stewbasic is working on adding them back in. I'm holding off on new maps until this is back.
Quote from: stewbasic on December 21, 2014, 06:10:10 PM
Quote from: Hubs on December 21, 2014, 01:59:01 PM
Would it hurt to leave T and Y in? These are super useful and although they would now be redundant I think they would still be faster than the new controls. Plus players are very used to them so it would keep some consistency between old and new PAC maps.
Secretly I had in mind to free those keys up for some other use :P. Those are good points though... I'll have a go at adding them back.
Quote from: Hubs on December 22, 2014, 03:22:16 PM
Tek, stewbasic is working on adding them back in. I'm holding off on new maps until this is back.
Quote from: stewbasic on December 21, 2014, 06:10:10 PM
Quote from: Hubs on December 21, 2014, 01:59:01 PM
Would it hurt to leave T and Y in? These are super useful and although they would now be redundant I think they would still be faster than the new controls. Plus players are very used to them so it would keep some consistency between old and new PAC maps.
Secretly I had in mind to free those keys up for some other use :P. Those are good points though... I'll have a go at adding them back.
groovy, i'm holding off until you dudes settle on a set of scripts! ::) ;)
My Megadolon map is finally out on CS and that now satisfies my PAC itch for the next week or two.
its a fun one, but the new keys are messing with my game play. :o
Quote from: teknotiss on December 22, 2014, 06:20:17 PM
its a fun one, but the new keys are messing with my game play. :o
Same, and I'm sure the map will be fun when I get the new keys sorted, but at the moment I'm finding it unplayable. :( That makes me very sad. :( It's just me being at the bottom end of the "learning new key combinations" spectrum.
Oh well, I'll keep trying, and I do really thank you and appreciate you for your hard work, but I don't understand why the T key was changed.
OK, new version attached with T and Y added back and help text updated. It turns out I may not have internet access for a couple of weeks, so this may be the last update from me for a while.
Quote from: Hubs on December 22, 2014, 09:47:55 AM
How about splitting support between the selected emitters? So if you have 10 emitters and two selected (meaning 8 are unselected) and you press T, each of the selected emitters would get 4 other emitters supporting them. That would be very helpful for a situations where you're pressing on two fronts. Other alternative would be to just support the last built emitter or have it do nothing.
At the moment it just picks one of the selected emitters arbitrarily, but splitting sounds better.
Re PZ nullifiers: I haven't changed Abraxis much, so I just copied Hubs's snippet over and tested it quickly.
Re E and R: If you select multiple towers in different modes, I would expect to press a key to put them all in the same mode, rather than toggling them all. This is why I changed the keys to set instead of cycle (and why there's no key to put spore towers in target mode). Maybe one solution would be to mimic vanilla again: if you select a bunch of blasters and press 'V', it toggles them between armed and disarmed... but if they are in different states to start with, it sets them all to armed. So I could make E/R cycle but put all selected units in the same state.
I guess the other thing I didn't like about E/R cycling was that usually there are only 2 modes so E and R do the same thing. And when there are 3 modes I can never remember which of E/R gets me to the right state anyway. Do most people only use one of the keys?
Re why 'O': because that's the default key to select all in vanilla.
Quote from: Hubs on December 22, 2014, 09:47:55 AM
I can't think of many cases where you would want a spore tower targeting an emitter.
There also aren't many cases where you would select both spore towers and emitters except to destroy. I think the current behaviour is easiest to understand (if you have a spore tower selected, clicking targets it regardless of what else is selected. If you have an emitter selected, clicking an emitter supports regardless of what else is selected).
Stew, I'm sorry - the "save.cw3" file I downloaded was a very basic map with three orbitals and one emitter, with text saying I was in edit mode? I've downloaded and played other maps before so I don't think it was me. Did you attach a different map?
Quote from: Linden on December 22, 2014, 07:31:47 PM
Stew, I'm sorry - the "save.cw3" file I downloaded was a very basic map with three orbitals and one emitter, with text saying I was in edit mode? I've downloaded and played other maps before so I don't think it was me. Did you attach a different map?
That's all that is in the template to start with. Resize the map and start changing terrain and adding units. When you play it will ask if you want to convert it to a PAC map.
Hi guys. Loving the PAC maps, so keep up the good work! I've got a suggestion and a question for you all:
Suggestion - During PAC maps you soon get to a point were you're in conflict with the human units. As soon as this happens, you get a constant stream of notifications on the left side of the screen as units are re-built/destroyed/re-built/destroyed etc. These notifications appear so fast that it's just not possible to keep up with dismissing them all, so you're left with a permanent list down the left side of the screen which can often obscure play (particularly when zoomed in). Is it possible for these notifications to be disabled for PAC maps? I don't find them particularly relevant to gameplay - I doubt anyone would miss them.
Question - Is there anyway to see a list of all current PAC style maps? I tend to search Colonial Space and order by rating, and usually I find the maps somewhere near the top. I've tried searching for text including "PAC" but this just returns anything with "space" in the name/description which is quite a common word. I've also tried "#PAC", "#PlayAsCreeper" and "PlayAsCreeper" but I'm not getting all results. It's possible I've played all PAC maps, but I don't know for sure and don't want to miss out on any!
Thanks!
Thisisnotasmile, when you're in colonial space, enter PlayAsCreeper in the "Text: " field and then click on "Apply Filters". That will return 16 of the 17 maps that have been published. The 17th is the one called "CreeperComeBack" and it doesn't include that tag.
As for those notifications, I disabled that long ago. from the main menu click on Settings and then under Misc check off the bottom option "Do not show game event notification tags"
Quote from: stdout on January 04, 2015, 09:25:06 AM
Thisisnotasmile, when you're in colonial space, enter PlayAsCreeper in the "Text: " field and then click on "Apply Filters". That will return 16 of the 17 maps that have been published. The 17th is the one called "CreeperComeBack" and it doesn't include that tag.
As for those notifications, I disabled that long ago. from the main menu click on Settings and then under Misc check off the bottom option "Do not show game event notification tags"
search #PAC for mine dude! 8)
I have used a runner in my new map (THE DEVIOUS ARACHNID) as a logic gate - it isn't modified in anyway - it is how you play it normally in a conventional map and it i can see it being quite useful in a few ways if used as I have here.
The only trouble is that I cant get the map to declare victory at the moment with it in. :( I found this thread looking for a solution so thought I would mention it :)
Hello!
So I've been playing lots of PAC maps and enjoying the hell out of them, enough to start actually looking at the crpl scripts for the first time. So, to keep in mind where I'm coming from: my full time job is programming, so I know how programming works, but this is my first look at CRPL. So please, be nice if my ideas are stupid. I'm not even savvy enough yet to test and debug them myself.
Without further ado... my code ideas.
In Abraxis.crpl, if IsCreeperInRange works like I suspect, and if it doesn't cause significant lag, line 92 should use IsCreeperInRange(<-X <-Y 3) instead of GetCreeper(<-X <-Y). (Maybe that should be 1 and not 3?) Because units occupy a 3x3 space, not 1x1, checking only at the point causes severely obnoxious rebuild-flicker on incompletely-covered unit locations. Sadly there's no IsDigitalisInRange, and I think faking it with an x/y loop may be a bad idea.
You can safely add a "break" after line 108, as long as it only breaks you out of one level of do-loop. It doesn't matter how many enemies you find, whether you find one or 20, you're going to rebuild the nullifier.
Assuming "loop" works the same as "continue" in C and python: You can get rid of the "Rebuild" variable. Change line 112 to "loop", and remove the if check around lines 118-120.
Finally, what happens if you change the victory check to only happen every 10 frames? I can imagine that GetUnitsInRange(0 0 9999) is a seriously expensive operation since it pushes every remaining unit onto the stack, and doing it every frame just HAS to hurt, and hurt bad.
New template attached. I ended up rewriting a lot of the tower controls stuff, and added some requested features.
* E/R now cycle again. If multiple units are selected, they are all put into the same state.
* T splits support between selected emitters.
* "Vanilla" creeper units can be added without interfering with victory. They even get replaced by dummy images when the player wins so they doesn't notice their destruction (unless there's an inhibitor).
* Emitter and SporeTower unit limits can be set in Builder.crpl.
Quote from: Stave on January 24, 2015, 04:00:49 AM
In Abraxis.crpl, if IsCreeperInRange works like I suspect, and if it doesn't cause significant lag, line 92 should use IsCreeperInRange(<-X <-Y 3) instead of GetCreeper(<-X <-Y). (Maybe that should be 1 and not 3?) Because units occupy a 3x3 space, not 1x1, checking only at the point causes severely obnoxious rebuild-flicker on incompletely-covered unit locations. Sadly there's no IsDigitalisInRange, and I think faking it with an x/y loop may be a bad idea.
You can safely add a "break" after line 108, as long as it only breaks you out of one level of do-loop. It doesn't matter how many enemies you find, whether you find one or 20, you're going to rebuild the nullifier.
Assuming "loop" works the same as "continue" in C and python: You can get rid of the "Rebuild" variable. Change line 112 to "loop", and remove the if check around lines 118-120.
Finally, what happens if you change the victory check to only happen every 10 frames? I can imagine that GetUnitsInRange(0 0 9999) is a seriously expensive operation since it pushes every remaining unit onto the stack, and doing it every frame just HAS to hurt, and hurt bad.
Profiling Abraxis.crpl is next on my TODO list (the original version checked creeper on a 3x3 area and avoided the GetUnitsInRange(0 0 9999) as you say). Thanks for pointing out IsCreeperInRange; I wasn't aware of that. Unfortunately a lot of the "do loops" can't be broken out of without leaving extra stuff on the stack (although I think the stack might be emptied each frame, so maybe it's OK).
stewbasic, if you have time you may want to look into the Terp bug (I consider it a bug, although some authors are using it as a map strategy). Basically if there is a terp on the map the terrain options become available and the PAC player can set terrain levels for the terp to then change. Even with normal controls diabled, it is still an option only if there is a terp on the map. I thought maybe GetCurrentBuildTab, but that doesn't look like it consides the terraform tab a build tab. More complex method would be to only have CRPL terps. Any thoughts?
I have a thought on this. It is within the canon of Creeper World that the Loki can and often do take control of human technology and corrupt it for their own use.
I feel that the creeper's use of human terps is perfectly in keeping with the lore of the creeper and I do not consider it a bug. It adds depth and gives another tool for map makers to use in their games.
Quote from: stdout on January 27, 2015, 05:59:18 PM
I have a thought on this. It is within the canon of Creeper World that the Loki can and often do take control of human technology and corrupt it for their own use.
I feel that the creeper's use of human terps is perfectly in keeping with the lore of the creeper and I do not consider it a bug. It adds depth and gives another tool for map makers to use in their games.
On the other hand a mapmaker may want a human terp without PAC interference. @Hubs I can't think of any other solution. A CRPL terp would be a pain to make... it doesn't look like any terp stuff (eg target terrain height) is exposed in CRPL.
Quote from: stdout on January 27, 2015, 05:59:18 PM
I have a thought on this. It is within the canon of Creeper World that the Loki can and often do take control of human technology and corrupt it for their own use.
I feel that the creeper's use of human terps is perfectly in keeping with the lore of the creeper and I do not consider it a bug. It adds depth and gives another tool for map makers to use in their games.
Yeah, I guess you're right. Doesn't look like there is a way to prevent it anyway.
Quote from: stewbasic on January 25, 2015, 08:05:03 PM
New template attached. I ended up rewriting a lot of the tower controls stuff, and added some requested features.
* E/R now cycle again. If multiple units are selected, they are all put into the same state.
* T splits support between selected emitters.
* "Vanilla" creeper units can be added without interfering with victory. They even get replaced by dummy images when the player wins so they doesn't notice their destruction (unless there's an inhibitor).
* Emitter and SporeTower unit limits can be set in Builder.crpl.
Quote from: Stave on January 24, 2015, 04:00:49 AM
In Abraxis.crpl, if IsCreeperInRange works like I suspect, and if it doesn't cause significant lag, line 92 should use IsCreeperInRange(<-X <-Y 3) instead of GetCreeper(<-X <-Y). (Maybe that should be 1 and not 3?) Because units occupy a 3x3 space, not 1x1, checking only at the point causes severely obnoxious rebuild-flicker on incompletely-covered unit locations. Sadly there's no IsDigitalisInRange, and I think faking it with an x/y loop may be a bad idea.
You can safely add a "break" after line 108, as long as it only breaks you out of one level of do-loop. It doesn't matter how many enemies you find, whether you find one or 20, you're going to rebuild the nullifier.
Assuming "loop" works the same as "continue" in C and python: You can get rid of the "Rebuild" variable. Change line 112 to "loop", and remove the if check around lines 118-120.
Finally, what happens if you change the victory check to only happen every 10 frames? I can imagine that GetUnitsInRange(0 0 9999) is a seriously expensive operation since it pushes every remaining unit onto the stack, and doing it every frame just HAS to hurt, and hurt bad.
Profiling Abraxis.crpl is next on my TODO list (the original version checked creeper on a 3x3 area and avoided the GetUnitsInRange(0 0 9999) as you say). Thanks for pointing out IsCreeperInRange; I wasn't aware of that. Unfortunately a lot of the "do loops" can't be broken out of without leaving extra stuff on the stack (although I think the stack might be emptied each frame, so maybe it's OK).
Thanks for adding a feature I requested before (limiting spores). much appreciated as always :) but I have only just found this (could we have a dedicated thread with only updates with the first post in that thread having the latest template which someone can manage? ,maybe even use this thread and use the first post as the place to go for the latest patch/update?) - Just one thing though, I have noticed that when I enter PAC mode, there is no text above the items in the PAC menu ( emitter spore etc) . but if I stop the map, edit it and just re-compile, then start it again, the text appears. Not sure why this happens ?
ha! Over on the Steam forums a player asked (in German,
nogal!) how to play PAC maps. I came here hoping to find some help, but this is mostly about how to make PAC maps.
If anyone can help the poor guy (level 0 on Steam, so not an experienced gamer) with some info, even just a link, it'd be nice. Post here if you don't want to post on Steam. English is OK, Google translate should suffice.
Here's the referenced question in both languages.
German (original)
Wie schon im Titel, ich habe keine Ahnung wie ich die Karten spielen kann, die man als Creep spielt. Ich kann nichts bauen und und auch nichts Aktivieren. Muß ja irgend eine Möglichkeit geben, oder sind das nur Karten zum anschauen?
Muß ich auf irgendetwas achten, oder beim Bau noch irgend welche Knöpfe drücken?
English via Google Translate
As in the title , I have no idea how to play the cards that you play as a creep . I can build anything and nothing and Activate. Must indeed any be a possibility or is it just to look at cards ?
Do I have to pay anything , or the construction nor press any buttons which ?
Quote from: Karsten75 on May 26, 2015, 10:24:24 AM
ha! Over on the Steam forums a player asked (in German, nogal!) how to play PAC maps. I came here hoping to find some help, but this is mostly about how to make PAC maps.
If anyone can help the poor guy (level 0 on Steam, so not an experienced gamer) with some info, even just a link, it'd be nice. Post here if you don't want to post on Steam. English is OK, Google translate should suffice.
Here's the referenced question in both languages.
German (original)
Wie schon im Titel, ich habe keine Ahnung wie ich die Karten spielen kann, die man als Creep spielt. Ich kann nichts bauen und und auch nichts Aktivieren. Muß ja irgend eine Möglichkeit geben, oder sind das nur Karten zum anschauen?
Muß ich auf irgendetwas achten, oder beim Bau noch irgend welche Knöpfe drücken?
English via Google Translate
As in the title , I have no idea how to play the cards that you play as a creep . I can build anything and nothing and Activate. Must indeed any be a possibility or is it just to look at cards ?
Do I have to pay anything , or the construction nor press any buttons which ?
Easiest way to learn may be to start by playing map #1492.
It has a basic tutorial
I put together a basic explanation in English at http://knucklecracker.com/forums/index.php?topic=17572.msg124817#msg124817 that might help. It's a bit outdated but should give enough information to get started. I don't know German at all so not sure if it'd be any good for him.
So I started feeling ambitious and put the guide I wrote on Steam. At some point I might even feel energetic and add the new key mappings made since Hubs template. I wouldn't mind another eye looking over it to make sure I didn't put something incorrect up. Thanks.
bump... this should maybe be stickied!