Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

FPSC Classic Scripts / Workaround with Lights and Stealth

Author
Message
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 20th Aug 2011 07:43 Edited at: 20th Aug 2011 10:58
I've been looking around the FPSC forums, curious about how people have tried to implement stealth into their games. It seems like most people opt to use zones, but I was curious abut how effective it would be to have stealth based on light.



This is pretty much the basis of the stealth system I've come up with so far. Put this in a light and make it dynamic.

Basically, there are three levels of light: bright, dim, and totally hidden. The advantage of this script is that it matches with the actual area covered in light. The disadvantage is that the "brightness" is transferred through walls and doesn't play well with multiple instances of this script in close proximity.



Put this in a trigger zone or other such marker. This sets up a hud that will indicate how hidden the player is. Really just cosmetic, and for the player's benefit.



This is the most important part. In the AI's script where ever plrcanbeseen can be found, three variations for each of the brightness levels are made so that they actually have an effect.

Now I ask you, do you think it is much of an improvement over the zone method? And how would you deal with the problem of "brightness" passing through walls, making you "visible" even though you may be in total darkness? At this moment, the best solution I can think of is to make sure any light with this script isn't anywhere near a wall.
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 23rd Aug 2011 09:11
Okay, I've been fiddling around with the scripts and what not, and it seems like the best way to have the stealth lights work is by having a static light with another dynamic light on top of it. The static light provides the illumination, while the dynamic light's range is set to zero and given a script like:



This seems to give the best results. I didn't figure out a way to reasonably prevent "brightness" from passing through walls, so basically I have to either rely on zones or designing the level around those lights.

I did also manage to make it work with the Dark AI that comes with FPSC, which combined with the ability to investigate noises allows for a reasonable facsimile of a stealth game.



Still I would appreciate some feedback from someone more knowledgeable about whether or not this script is efficient. I've only tested same levels so far, so I'm not sure if performance might dramatically drop in larger levels - or if the whole light-based stealth is just over-engineered and zones would be the better choice.
maho76
13
Years of Service
User Offline
Joined: 31st May 2011
Location: universe-hub, playing the flute
Posted: 23rd Aug 2011 18:48 Edited at: 23rd Aug 2011 18:49
nice done, but have you thought of combining zones and entities?

pure zonework is not that good because you only can define 1 zone with this script shown in the other thread. when you use 2 zones, one sets the var to 1 and the other where you are not in sets var=0 > enemy will see you.

setup a zone that activates a var, then write a mainscript for furniture relying to this specific zone/var wich checks the var and the plrdistwithin to the object, as you have done above, but on an entity. in this way you can set up multiple very detailed stealthzones with different vars, but place the lights as you wish.

more complicated, but with more options.

finally dont forget to revise the mainscript of the enemies with a plrdistwithin condition so a patroling npc that comes near you sees you if you are too close.

that would be the most detailed optimum for stealthtriggers, i think.
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 23rd Aug 2011 22:03
Thanks maho76! I did actually think of combining zones and entities, but I didn't think of using regular entities instead of light markers. That's a much more flexible system than what I was originally going with.

I've modified most of my current scripts for the plrdistwithin condition, with the exception of the Dark-AI patrolling script. For some reason, once I include the plrdistwithin check they stop animating their movement.

Anyways, I appreciate the advice!
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 24th Aug 2011 08:53 Edited at: 24th Aug 2011 09:55
In case anyone is wondering, here are the scripts I use for stealth zones:







They're pretty simple, and are based on meteorite's script.
The Storyteller 01
15
Years of Service
User Offline
Joined: 11th May 2009
Location: On a silent hill in dead space
Posted: 24th Aug 2011 13:32 Edited at: 24th Aug 2011 13:34
I found the only 100% reliable method still is to work with zones. My setup is a follows:

- enemy1 is spawned at start with a script that ignores the player as long as the enemy isn't getting wounded at.
- the triggerzones have a script that doesn't change anything as long as the scankcodekeypressed=<whichever key does CROUCH> true.
- if scankcodekeypressed=untrue the script destroys enemy1 and activates enemy2 (a copy) that has a script that makes him immideately attack the player.

This has the added advantage, that the guards (enemy1) can be given additional script lines that make them p.e sit or having a conversation, without the risk of the script misfiring.

But my method was created for a Fantasy game where there are no gun sounds so it has an obvious flaw in a modern setting:
- as long as the player is crouching he can shoot without spawning the agressive enemy.
- besides that, it doubles the amount of dynamic entities used and could raise the polycount quite high.

In case you find my grammar and spelling weird ---> native German speaker ^^
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 24th Aug 2011 17:24
I was considering including crouching as something that improved your ability to hid by reducing the global variable, but since my current system has very discrete values, it doesn't work so well.

I like your idea of having a separate script for detecting the player though! Since I'm using the WASP Mod, I can use "setmainscript = X" to change to a regular attack script without needing to create multiple entities, provided the command works like I think it does.

Currently I also have it set up so that when the ai hears a sound, it'll go check it out:



but since I'm not entirely sure what counts as a sound to the ai (sometimes I can shot the ground behind it, and it won't respond, other times I could be two rooms away and it'll come checkout what I'm doing) I have no idea if it works well or not.

So thanks for telling me what you usually do The Storyteller 01, since the whole separate script for detecting the player may in fact work better than just modifying the main script directly like I am right now.
The Storyteller 01
15
Years of Service
User Offline
Joined: 11th May 2009
Location: On a silent hill in dead space
Posted: 25th Aug 2011 02:13 Edited at: 25th Aug 2011 08:19
I have to admit I never had nor have a lot of trust in the AI/dark AI.

For me the reliable path (in any game engine) has always been, to directly feed the engine with conditions and have it tell the NPC exactly what actions to take. Of course that doesn't allow complex NPC behaviour

In case you find my grammar and spelling weird ---> native German speaker ^^
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 25th Aug 2011 03:02 Edited at: 25th Aug 2011 19:34
True enough. Relying on rules to procedurally create generate AI only really works if you've got a great understanding of both math and coding, and are willing to spend a huge amount of time coming up with that code. It's much more reliable to just code it in than to try and be clever unless you really have a grasp on what you're doing (which I don't :p).

Anyways, I actually ended up adding directly to the scripts the commands, instead of using the "setmainscript = X" since I spent about an hour trying to figure it out and couldn't. Also, I cleaned up some of my stealth code.



With my stealth indicator, I changed the stealth variable from "globalvar=100" to "dimvar=stealth" and correspondingly changed all the stealth code to match. This way I can use more than one global variable. Also, your idea about crouching inspired me to add crouching as a feature. I'm still experimenting with it, but basically the idea is that crouching will reduce the amount of noise you make, thus making it easier to sneak.



Here are the major changes I made to the "TF341_Main_Default.fpi" script. Essentially standing up and running attracts more attention (farther hearing distance) than crouching, and being in bright light allows enemies to see you from half-way across the room. In no light, they practically have to enter melee range to see you.

The major issue I've currently got with crouching is that it isn't togglable. As it is at the moment, someone can crouch and then start moving, and as long as they keep moving they still count as crouched even if they let go of the button.

Also, here are the scripts I attach to entities I use as a source of light:



Basically, I just cut out the "light on/off" & "activated=" bits, so that they take up marginally less time to calculate. There are occasional glitches where if the player is moving too fast, they might leave the area before the script resets them to "setvar=stealth 0", which results in them being stuck in dim light (even though they may be in total darkness) until they walk through another stealth light zone. Fixes for this include increasing the range of the area, & slowing the player down.
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 25th Aug 2011 03:17
Actually, right after I posted this I figured out how to make crouch-stealth work without toggling it.

By replacing

:varequal=crouch 1:setvar=crouch 0

with

:scancodekeypressed=!46:setvar=crouch 0

I made it check to see if the button wasn't pressed. I didn't know that "=!" was actually something that worked in FPSC. You learn something new every day!
The Storyteller 01
15
Years of Service
User Offline
Joined: 11th May 2009
Location: On a silent hill in dead space
Posted: 25th Aug 2011 08:22 Edited at: 25th Aug 2011 08:25
Quote: "I didn't know that "=!" was actually something that worked in FPSC. You learn something new every day"


Although I tried to follow any script syntax changes/additions for 1.17 to 1.18 I never spotted that

I am not into any stealthy projects right now but your scripts look very simple, yet advanced - I would like to try them out myself

In case you find my grammar and spelling weird ---> native German speaker ^^
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 25th Aug 2011 10:00 Edited at: 25th Aug 2011 10:10
I'd be honored if you tried them out! It's partially why I'm sharing them too. There aren't a whole lot of first-person stealth games in general (the only good ones that come to mind are the Thief series). I can help but feel like there's some, more elegant/less computationally intensive way to do stealth, but I'm glad you think that they're advanced.

Since I've put up the scripts, I might as well add the pictures I'm using for the "eye" hud. They were originally taken from freedigitalphotos.net. The idea is to have a little symbol representing how hidden you are, ala the light gem from Thief.

Attachments

Login to view attachments
maho76
13
Years of Service
User Offline
Joined: 31st May 2011
Location: universe-hub, playing the flute
Posted: 25th Aug 2011 18:27
Quote: "(the only good ones that come to mind are the Thief series). "


dont forget the ultimate: metal gear solid 1+2

also all parts of deus ex can be played as stealth-action most of the time. (YEEEAAHH, tomorrow is the day of the decade... i hope: deus ex 3 release!! http://www.youtube.com/watch?v=Ncym_kOuqv4 )

Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 25th Aug 2011 19:32 Edited at: 25th Aug 2011 19:33
Man, how could I forget those? Although to be fair, the Metal Gear series are primarily third-person with an option for limited first-person. But otherwise, you're totally right. I've heard from a friend who has already bought it that Deus Ex 3 is a pretty good sequel, barring the mandatory boss fights that are pretty much bullet sponges.

That does bring to mind a question: how would you do bosses in a stealth game? It seems like most designers go for the route of making them a powerful enemy you have to kill, yet that ignores pretty much everything you've been doing up to that point.

Anyways, on the topic of the stealth scripts, I figured out a better way to use entities as a source of the light scripts. Just set in their properties "Always Active?" to "Yes". This solves all the glitches I mentioned above, but has the downside of having them always calculating those scripts. It's not so bad if you make the objects immobile and turn off their physics, but for someone whose trying to optimize their level's memory usage, it might be annoying.
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 25th Aug 2011 19:52
Other things to note: the "aiheardsound = X" seems to vary in effectiveness based on level design. I've done most of my testing with the stock ww2 segments, and they work pretty much like I want them to (when the ai hears a sound, it'll walk close enough to spot you in dim light, but not in no light - unless you continue to make noise). But with the dungeon pack, there seems to be a little lag between when you make a noise and when the ai hears you (but then the ai is more aggressive when it pursues you).

I'm not sure if it's the way I've got the levels set up, or if it has something to do with the properties of the segments, but it's something I've noticed.

Also another tip for using the stealth-lights is that they work best in conjunction with zones. The stealth-lights work best in either small rooms, or rooms that don't block a lot of light. If you've got columns or platforms blocking large chunks of the light, using zones to modify the areas of shadow (so that they count as dim/no light instead of high light) helps with the realism. Zones also work better for narrow corridors (where the light is more directional than spread) and for rooms that are side-by-side and have multiple lights in them.
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 26th Aug 2011 08:35
After further testing the issues with the segments, it turned out all I needed to do was run FPSCreatorDumpMem and Cleaner to clear up those segment issues.
maho76
13
Years of Service
User Offline
Joined: 31st May 2011
Location: universe-hub, playing the flute
Posted: 26th Aug 2011 10:25 Edited at: 26th Aug 2011 10:28
Quote: "I figured out a better way to use entities as a source of the light scripts. Just set in their properties "Always Active?" to "Yes". This solves all the glitches I mentioned above, but has the downside of having them always calculating those scripts. It's not so bad if you make the objects immobile and turn off their physics, but for someone whose trying to optimize their level's memory usage, it might be annoying. "


when you got performance probs with the entities you can use THIS method to appear/reappear them to cancel calculating when you are out of sight:

http://forum.thegamecreators.com/?m=forum_view&t=187181&b=23

it will start to get real complex, but thats how good games are done

EDIT: dont forget keypressed?-routine for player running (shift)

gz
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 26th Aug 2011 14:25
Thanks for reminding me to modify the run routine so that it makes more sound than normal walking. I'm thinking of modifying the indicator script to:



and the enemy's script to:



which allows the enemy to detect the player from further away when they are running than walking or crouching.

Also, thanks for the link to your scripts, hope you don't mind if I cannibalize them for ideas.
maho76
13
Years of Service
User Offline
Joined: 31st May 2011
Location: universe-hub, playing the flute
Posted: 26th Aug 2011 16:17 Edited at: 26th Aug 2011 16:18
Quote: "Also, thanks for the link to your scripts, hope you don't mind if I cannibalize them for ideas."


feel free to do, it was for the community.

my actual project on fpsc is not a stealth thing, but i also have an alternative idea to use your system, so thx for this interesting conversation.
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 26th Aug 2011 17:53 Edited at: 26th Aug 2011 21:22
Thanks to you too. I'm pretty much posting this up for the community as well. One final note is a slight change to one of the scripts.

Instead of

:scancodekeypressed=!46:setvar=crouch 0

it should be

:scancodekeypressed!=46:setvar=crouch 0

I tried out the "!=" symbol with a few other variables, including "plrblocking=". For example:



the "plrblocking!=0" is effectively the same as "plrblocking=1", but if you're not using something including plysmod it fixes up an error where after the block animation ends the plrblocking equal neither 1 or 0 - which in this case results in no damage and no camshake. The one down side of "!=" is that FPI EditPad treats it as a new command, and will keep telling you to fix it.

EDIT: Actually it seems that both "!=" and "=!" work, but with minor variations. But at that point, it's really now a topic for another thread.
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 26th Aug 2011 21:57
I'm curious if there is a way to detect if a key has been pressed, regardless of whether or not any other keys have been pressed. Right now I've got



Which basically is supposed to detect if you're running or crouching. If you're pressing the corresponding button, the crouch variable changes. If you're pressing neither, it returns to the default state. It works just fine if I press shift (scancode=42) before I start moving, but the problem is that if I press shift after I start moving, it won't change the variable. Same problem with the crouch button.

So, again, is there a way to detect if a key has been pressed, regardless of whether or not any other keys have been pressed?
The Storyteller 01
15
Years of Service
User Offline
Joined: 11th May 2009
Location: On a silent hill in dead space
Posted: 26th Aug 2011 22:26 Edited at: 26th Aug 2011 22:26
How about a simple workaround with an additional line at the end, that will turn run+crouch into run regarding the stealth variable (just an idea):



In case you find my grammar and spelling weird ---> native German speaker ^^
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 26th Aug 2011 23:08 Edited at: 26th Aug 2011 23:19
Your additions to the script do make it so that crouching & running at the same time counts as running for the purposes of noise (which is really what the crouch variable is for),yet the issue with being able to move, and then run/crouch without it counting as running/crouching. Essentially if you start out walking, and then run or crouch, it doesn't detect that you're now running or crouching and you count as walking for the purposes of noise.

I did a little research on scancodes, and then wrote a quick program to confirm it, but it seems like the issue is that the WASD controls are read before the Shift/C keys - which then prevents them from being read unless you release those keys.

The script actually works almost perfectly if you use the arrow keys to move, since the shift/C keys are read before the arrow keys (although, there's still a problem of the run/crouch status not ending when you release they keys unless you also release arrow keys).

But thanks for point out the crouch/run thing, since it's yet another problem that could've arisen. Ugh, so many things to code contingencies for! :p

Anyways, one non-solution is to set the crouch/run keys to something before the WASD keys in terms of the scancode, or setting the WASD keys to something after the crouch/run keys (this is a non-solution, because doing so would make the controls very awkward).

Is there a way to detect if the player is crouched or running, without having to rely on scancodes? I tried having it based on the player's speed (eg ":speed=100:setvar=crouch 0") but that didn't seem to work at all.
The Storyteller 01
15
Years of Service
User Offline
Joined: 11th May 2009
Location: On a silent hill in dead space
Posted: 26th Aug 2011 23:17
You are scripting on a level that's far beyond mine (I never got as far as usings variables ) but I have one last thought before I have to give up:

Could using ALWAYS for establishing the conditions for crouch/stealth solve the problem?

In case you find my grammar and spelling weird ---> native German speaker ^^
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 27th Aug 2011 01:12 Edited at: 27th Aug 2011 01:16
Thanks for the complement, but I can't help but feel like not all that good at scripting. I pretty much have no idea what I'm doing, and just kinda trying out random commands until I get something that resembles working. XD

Well, I tried the "always" condition, but in the end I ended up pretty much completely changing around the script:



I took another look through my WASP mod manual, and found the "isrunning=" command, which does exactly what I wanted that scancode mess to do for the shift key, but with none of the errors. Pretty face palm-worthy of me. Unfortunately this has two downsides: "isrunning=" is (as far as I know) exclusive to WASP mod, and I always hate having code specific to a single mod/platform. If I ever use something other than WASP, I'd be back at square one - but at least for now it solves the problem.

The other issue is that there is no "iscrouching=" counterpart to it, leaving me with the same set of problems for crouching. At the moment, crouching only really applies if you don't move; other wise you count as walking for the purposes of noise making.
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 27th Aug 2011 11:09 Edited at: 27th Aug 2011 11:11
I've decided to make the stealth system a little more smooth.





It's definitely a work in progress, but basically I'm trying to make the stealth system less discrete. Now the area the enemy can listen/see is less hard-coded - or rather they are more directly influenced by the variables. Eventually, I'm hoping that the system will be flexible enough to allow multiple intersecting modifiers on the noise you make and how visible you are. But in the mean time, this is what I've got.
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 27th Aug 2011 11:25 Edited at: 27th Aug 2011 11:37
Additional scripts:



Here's an example of how the lights have changed. With this change, multiple stealth-lights can be placed near each other. If you stand in-between multiple close lights, it results in you becoming more visible than if you were just standing in a single light.
The Storyteller 01
15
Years of Service
User Offline
Joined: 11th May 2009
Location: On a silent hill in dead space
Posted: 27th Aug 2011 17:17 Edited at: 27th Aug 2011 17:18
I don't want to spoil your fun, but doesn't it get a bit complicated?

And another thing - if you want it super realistic then the general ambience level as well as the difference between that and every lightsource has to be taken into account too

In case you find my grammar and spelling weird ---> native German speaker ^^
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 27th Aug 2011 18:00 Edited at: 27th Aug 2011 18:05
True enough, but now I'm coming up with stuff under the assumption that stealth would play a large role in the game. If it's going to a feature, then I might as well go all out right?

For super realism, I guess we could always have an "ambience variable" (let's call it ambi) and having something like "ambience=%ambi", and a variable for the light's intensity(eg "dimlocalvar=intensity" This isn't actual intensity mind you, but an arbitrary value we've assigned to it to represent how bright the light is).



The idea here is that the greater the contrast between the light source and the surrounding area, the more that light source and everything in it stands out - thus increasing the likelihood of an enemy noticing the player there (represented by an increasing the range an enemy can spot the player).

Conversely, if intensity is less than the general ambience level, then we are assuming the light is dim, weak, or otherwise not particularly noticeable. In those cases, the enemy is less likely to notice the player since that area blends into the background, so to speak.

ALTERNATELY:



where we're just saying that the greater the contrast, the more likely the player is going to be seen.

Of course, the downside here is that now each light will need it's own intensity level assigned to it. :p Also, there won't be too much added to or from the stealth variable, since both ambience and light intensity are measured from 1 to 100, thus the most added/subtracted would be a segment.

And don't worry about spoiling my fun, I'm one of those rare people who love to make over-complicated systems. XD
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 27th Aug 2011 21:46
Also as a side note, KEYPRESSED=X Y works more predicatably than KEYPRESSED!=X.



Found it in the unofficial FPSC complete script syntax. Just sharing it, since I did bring up these kinds of commands earlier in the thread.
The Storyteller 01
15
Years of Service
User Offline
Joined: 11th May 2009
Location: On a silent hill in dead space
Posted: 27th Aug 2011 21:50
I have allready added this thread's link to my favourites. I have the feeling, one day I'll be glad I did

In case you find my grammar and spelling weird ---> native German speaker ^^
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 28th Aug 2011 00:06
I'm glad you think this thread is worth favoriting!

I made a few more changes to the stealth indicator:



Basically the indicator while change a bit more smoothly and show more degrees of stealth than just "highly visible" "somewhat visible" and "not visible". The huds are made from PNG files instead of DDS files so that it is easier to modify the appearance of the indicator. Correspondingly, I've altered the stealth-lights to produce a more variable amount of light:



The coding's a little bit more brute force than I would've liked, but it gets the job done. Attached are copies of some of the stealth scripts and the huds, in case anyone wants to try them out. I didn't include any enemy scripts, since I've been mostly modifying the TF341 scripts, but it isn't too hard to make the enemy use the stealth stuff.

To make it so that the enemy has to spot you before attacking, include this line before any "shootplr" commands:



or at least something along those lines.

To make it so that the enemy can hear you, include this piece:



These are pretty basic, and really are just to demonstrate that they can be used.

Attachments

Login to view attachments
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 28th Aug 2011 03:03
Yet another script change (big surprise there):



Functionally, it is the same as the last one, but this makes it easy to change the the range of the stealth-light. Has limited use, but I'm always a fan of doing something now to reduce the amount of work later.

Although, I do wonder: anyone else write scripts so that they are easy to modify?
The Storyteller 01
15
Years of Service
User Offline
Joined: 11th May 2009
Location: On a silent hill in dead space
Posted: 28th Aug 2011 10:19 Edited at: 28th Aug 2011 10:24
Quote: "Although, I do wonder: anyone else write scripts so that they are easy to modify?"


You can bet on it

For EVERY script I write, I include a "how to use" into the header, just in case I forget over the years what I made it for

But more important (and heavily recommended!), is that I NEVER use consecutive numbers for state=. When jumping to the next state I always skip several numbers so I can insert additional states later without having to renumber the whole script.

Currently I am working on a conversation script that is pretty simple right now, but prepared to easily include alternate lines and animations once I start to use variables:



That might sound a little OCD but I even used a system for numbering the states so the different steps are more easily identifiable

In case you find my grammar and spelling weird ---> native German speaker ^^
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 28th Aug 2011 19:47
You've certainly got better documentation for your scripts than I do. XD

And generally I don't use consecutive numbers for states. In the previous script, however, I actually ended up filling in all the space I had left open.

Sadly, it doesn't seem like variables can store text strings, although I'm guessing you're using the fpgcrawtext since it's easier to modify than a hud?
The Storyteller 01
15
Years of Service
User Offline
Joined: 11th May 2009
Location: On a silent hill in dead space
Posted: 28th Aug 2011 20:16 Edited at: 29th Aug 2011 02:07
I admit, I LOVE fpgrawtext. It's one of the reasons I haven't ditched FPSC yet

And there is no problem with variables - any state can display text and add/call a variable at the same time (afaik).

In case you find my grammar and spelling weird ---> native German speaker ^^
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 28th Aug 2011 21:08 Edited at: 29th Aug 2011 02:33
Well when I say variables can't store text strings, I mean doing something like:



But I've yet to do much with text. I was also thinking of including some rpg elements, so that you can get better at sneaking, run faster, jump higher, punch harder, etc:



however my ineptitude with code prevents me from quite figuring out what my mistakes here are (probably doesn't help that it's pretty roughly put together at the moment).

But basically, it works like this:



EDIT: Accidentally put an older version of some of the scripts up.
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 28th Aug 2011 21:20
Actually I figured out the problem: the "incvar" command. It doesn't work with custom variables it seems.
Scimitar
13
Years of Service
User Offline
Joined: 24th Apr 2011
Location:
Posted: 29th Aug 2011 02:39 Edited at: 29th Aug 2011 02:40
So, I've been trying to fix that leveling script:



but the cursor won't show up. :/

Anyways, I've also updated the zone scripts to match with the changes made to the stealth variables.







Unfortunately they aren't as smooth at transitions as I'd like, but they do serve their purpose. Hmmm, after all this, I should probably make a level to see if they can actually be combined into something fun and playable. So far I've mostly just been testing these scripts to see if they work, not if they work well as gameplay.
ajkcool
14
Years of Service
User Offline
Joined: 31st Dec 2009
Location: Home
Posted: 25th Sep 2011 09:08
so, which ones actually work, and what do i set them to?

"Hey everyone, I love you." jk

Login to post a reply

Server time is: 2024-11-24 05:09:02
Your offset time is: 2024-11-24 05:09:02