Reduce Gametime when Pickup aquired.

Started by Courtesy, October 01, 2014, 03:04:50 AM

Previous topic - Next topic

Courtesy

I'm trying to set it so that when you pick up a message artifact, the game timer is reduced by 5 minutes. Unfortunately, being the blessed ball of silly I am, I have no idea where to start.

knucracker

You can use these commands:
GetGameTimeFrames and SetGameTimeFrames

So something like the following.


GetGameTimeFrames ->currentTime

# 5 minutes is:  5 minutes * 60 seconds * 30 Frames-per-second = 9000
<-currentTime sub(9000) ->newTime

# Make sure it doesn't go less than 0... I dunno what happens if you set game time less than zero.  Probably won't be very good.. or might not be required at all
if (<-newTime lt(0))
   0 ->newTime
endif

SetGameTimeFrames(<-newTime)

Courtesy

Oh, I didn't know you broke down time by the frame, instead of some other measurement! d:
So which command am I looking for to look for a particular kind of entity? Like, for example, if I for some strange reason wanted to reduce game time by 2 minutes whenever someone built a blaster, how would your language locate a new blaster having been placed, to subtract that time?

Are shield keys/message artifacts in any way special/unique per, so that different ones can be set to due different things by an ID?
I thank you for being patient with me, I know I ask a lot of simple questions I could -probably- figure out on my own with diligence :\

Grayzzur

http://knucklecracker.com/wiki/doku.php?id=crpl:crplreference

You'd have to use a series of commands to get at that. Mostly in the Unit Commands section on the wiki.

GetUnitsInRange/GetAllUnitsInRange to pull the list of Unit IDs for everything (in an area or the whole map). Loop through them and check each one with GetUnitType to find out what it is. Various units can provide extra info about themselves via GetUnitAttribute. To track when NEW unit of a particular type is built -- that would be up to you to track, by counting them or tracking all the unit id's of that type or whatever other method you come up with.

That should point you in the right direction. Give it a shot.

I find it very useful to use ShowTraceLog/ClearTraceLog and all the Trace* commands to see what's going on when I'm testing out new bits of code logic. Play with those too, if you have not.
"Fate. It protects fools, little children, and ships named 'Enterprise.'" -William T. Riker

knucracker

Another thing might be to trigger off of picking up a shield key.  Each shield key has a GUID assigned to it when you add it in the map editor.  You can check to see if this GUID has been picked up and reduce time if it has.

Something like this (not tested... I just typed it in here).  Note setting a "collected" variable so your action doesn't happen over and over.  The ArtifactCollected call will return true once you pick up a shield key... forever.  So it is good for cross mission goals as well.


if (not(<-collected) and (ArtifactCollected("ENTER_THE_GUID_FROM_THE_MAP_EDITOR_FOR_A_SHIELD_KEY")))
 true ->collected
  # Do something
endif


You can of course look for other things to trigger your action like Grayzzur mentioned.  GetUnitsInRange, GetUnitAt, etc can be used to look for units.  You could also create a core on the map that requires you to hook-up to it and charge it with 500 packets... then it would reduce game time.  These examples get more and more intricate, though.  If you are just getting started with CRPL pick something easy to start with....  

Karsten75

Quote from: virgilw on October 01, 2014, 11:11:30 AM


Something like this (not tested... I just typed it in here).  Note setting a "collected" variable so your action doesn't happen over and over.  The ArtifactCollected call will return true once you pick up a shield key... forever.  So it is good for cross mission goals as well.


What happens if one chose to replay the mission in which the shield key is to be picked up?

Grayzzur

That's the catch. You've already picked it up before you start the map the second time.

As far as I can tell, there's no good way for a map maker or a player to manage their shield keys either -- see what they have and where it came from and what it's needed for, maybe even remove it if desired.

Makes it hard for the map maker to test, too, because once you pick it up, you can't test picking it up anymore.

I've seen the case where Map Maker A makes Map 1 with a shield key, Map 2 that requires the shield key (so that you play Map 1 first). Then Map Maker B comes along, plays both maps, likes something he sees in Map 2, copies the CRPL scripts to his new Map 10, and publishes it. What he doesn't realize is that Map 10 requires the shield key from Map 1, and is puzzled when other players who have not played Map 1 report his map giving them an immediate mission failure on start.

So, for a new map maker learning CRPL, I would steer clear of shield keys until you get comfortable with the scripting.
"Fate. It protects fools, little children, and ships named 'Enterprise.'" -William T. Riker

Karsten75

All flaws and issues to be avoided in TNG.

warren

If the game timer is unsafe below 0, then for game balance, people editing the timer should have a dummy game timer, check every frame
1) if the timers do not match
  1a) if the dummy timer is below 0.

Then set the main timer accordingly.