Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: IPAndrews on February 13, 2006, 06:07:33 am
-
First the obligatory (and actually thoroughly deserved) thank you to all the talented coders who have worked on SCP enhanced FS_Open and FRED2_Open. Now. I've got a whole truckload of feature requests now. Some old, some new. So rather than create a bazillion different request threads, which would probably be quite annoying if not rude, I thought I'd bundle them all into one thread. These are not demands but requests and as such I'm thorougly prepared for them to be ingored by coders in favour of something more interesting ;). If any of my requests actually get implemented that's a bonus. So without further ado.
1. String -> number conversion sexp. (Killed by a Karajorma on level 1)
2. Number -> string conversion sexp.
3. String concatenation sexp.
4. Ability to assign value of string var to another string var using modify-variable (FRED complains currently).
5. Debris that doesn't fly a million miles away from a big model when it explodes.
6. Cockpit models that allow HUD guages to appear as textures on the geometry.
7. Power output settings in ships.tbl that actually do something.
8. Option to have mission go to debriefing when player dies.
9. change-ship=class allows classes of ships that are warping in, or are not in-mission yet to be changed (also affecting wing waves)
10. BHX doesn't crash after 5 seconds of gameplay ;)
11. Some mechanism for getting capital ships to attack the nearest other capital ship. Like the Attack any for fighters. I'm open to suggestions on how to achieve this. Yes yes scripting capship battles to the milimeter looks nicer but it's not practical when you have a ton of capships ingame.
-
4. Ability to assign value of string var to another string var using modify-variable (FRED complains currently).
That one is a bug caused by the way FRED2_Open saves missions. I've already entered it into mantis. You can of course work around the problem using notepad but I can understand why that's annoying especially for BHX.
-
12. A new conditional called when-called, where attatched code only runs if the event is called as a subroutine from another event.
13. A call sexp for calling events with a when-called conditional.
14. A modest increase in the SEXP node limit, or a dynamic limit so that nutters like me can go sexp crazy without forcing a memory/performance hit on others (assuming of course that a modest increase in the sexp node limit actually results in any kind of significant memory/performance hit ;) )
15. >100 variable support.
-
16. An 'end mission and quit to main hall' sexp - To allow mission designers to force a 'save' of a campaign in a certain state when exiting. I think this would be required if anyone is ever to do anything meaningful in line with goober's Freespacelancer tech demo. With this, you can allow the player to save the campaign through clever use of 'key-pressed' sexps and campaign persistant variables and then dump the player to the main hall.
If one is real clever, one could even allow for multiple saves without anything further being needed. not that I'm planning anything, but seeing that demo did get me thinking about what else might be needed to actually build something like that.
-
Here are a couple of minor things I could use:
17: working text color tags in debriefings
18: working music in red alert briefings
19: a weapon flag for turning off the particle smoke/fire hit effect (for special weapons that don't do any normal damage)
20: ability to set special hitpoints variables dynamically (based on the difficulty level)
21: fixed environmental mapping (I know, this isn't going to happen any time soon, but I can dream :D)
I'm overall pretty satisfied with the current feature set though.
-
12. A new conditional called when-called, where attatched code only runs if the event is called as a subroutine from another event.
13. A call sexp for calling events with a when-called conditional.
I've been doing that with variables for a while. What I did was set up an event like this
every-time
-String-Equals
--callRoutine{no}
--yes
-do-stuf
-modify-variable
--callRoutine{no}
--no
Then all you have to do is alter the variable whenever you want to call it. Yeah I know it uses up more of your precious supply of variables but implementing 15 would stop that being a problem.
You just set a variable when you want the routine called and modify it back to zero in the routine.
-
Yes you can create a piece of code that runs repeatedly using every-time, like so:
every-time
counter<repeatition_times
do stuff
This is not the same as what I'm suggesting though. It has a downside. You can only call the code in this way once every frame. I use this method in BHX to change ship classes now. I might have 8 different capital ships. Each frame I put a ship name in a temporary variable and let the class change code call. It changes the class of the ship with it's name stored in the temp variable. For 8 capships of course this takes 8 frames. I use exactly the same method for random background generation as you know. What I suggest is something different. The key is the "call" sexp, which enables you to run the code belonging to an event from anywhere, in that way you could call code more than once per frame. Extremely useful I think. Would make a huge difference to BHX. No more fiddling with silly counter variables as above.
-
I think scripting might be a good idea for that...
-
Would it be acceptable to make new conditional that it works properly within a when-argument or every-time-argument conditional?
If you do this
when-argument
-every-of
--ship1
...
--ship4
-true
-do-something <--------------------------Triggers 4 times, once for each ship
--argument
-when <--------------------------Triggers once
--true
-do-something-else
-when <---------------------------Doesn't trigger at all. Probably cause it doesn't have the faintest clue what argument is.
--true
-doathirdsomething
--argument
Would it be acceptable to have new conditional, similar to when which
a) Triggered as often as the number of arguments that matched
b) Accepted argument
I don't know which would be easier to implement, the call subroutine function you want or what I've suggested but I think both might solve your problem.
-
I'm going to continue from 16 since "My request thread" was hijacked :D
16. The ability to chance selected target and view in the ALT-PAUSE screenshot taking mode, if not just fly around the environment without being tied to a particular ship. You might already be able to do this of course and I just don't know how. :nervous:
17. Mission flags to disable retry previous, and disable skip mission.
-
17. Mission flags to disable retry previous, and disable skip mission.
Both bad ideas IMO.
-
Problem is that IPA's BHX campaign uses a lot of persistent variables. Do they reset correctly if you go back to a previous mission?
Cause if not it could result in a situation where a player retrying the first half of a red-alert actually made it impossible to progress.
-
Yet another example of people requesting something different from what they actually want. :rolleyes:
I don't think they'll reset in that case. Best solution is to not use red-alert missions.
-
How hard would it be to make the new modified version of when above that can be triggered as many times as the argument is valid?
-
Actually Kara, it's more to do with the "select mission" mission that's picks the next mission at random. If return to previous is enabled the player and the player gets lumbered with a misson they don't like the look of they can just return the previous "select mission" mission and it'll select a different mission for them. Not the end of the world - but a bit of a cheat nevertheless. Similarly I also think skip mission is a bit of a cheat and not in the spirit of the campaign. I'm a bit confused as to why Goober thinks they're bad ideas. I can imagine people who have no use for them being indifferent, but to actively think they're a bad idea? :(
-
Yes, because if a mission's too hard I will probably give up and go do something more productive with my time than replay the same mission over and over.
They're safeguards against bad FREDding and chance. What if you do one of those missions, and the hull integrity of a crucial escort ship is at 1%? There's no way you can beat the mission without actually using cheat codes, yet to progress you'd have to replay the entire campaign.
-
Also the odd near impossible mission is an inevitability in a campaign that allows you to choose to play as the Raiders and fight the Shadows. So I built my own skipping mechanism into the framework of the campaign. It's called "running away". But... never mind. Clearly there's absolutely zero enthusiasm for that particular suggestion. **** happens, I'll deal with it :).
-
18. Some way of defining what particles are spewed by fire damage (so we can have Shadow ships bleed/spew black goop).
-
I'm going to continue from 16 since "My request thread" was hijacked :D
Well, if I had created my own thread, I know someone would come along and say "keep it to one thread." :p
18. Some way of defining what particles are spewed by fire damage (so we can have Shadow ships bleed/spew black goop).
This would work for me in place of my 19. (I could just use a blank image)
-
19. SEXPs for creating an asteroid field which allows you to specify the outer and inner boxes just as in FRED.
-
20. Random number SEXPs that make use of a random number seed that the user can set. Such that if a mission is called twice, and each time the same random number seed is used, any calls to random number SEXPS (or send random message) give the same result. This would be enormously useful for pseudo randomly generating missions.
-
20. Random number SEXPs that make use of a random number seed that the user can set. Such that if a mission is called twice, and each time the same random number seed is used, any calls to random number SEXPS (or send random message) give the same result. This would be enormously useful for pseudo randomly generating missions.
What about setting a variable equal to the rand sexp when the mission starts, and using that variable for each "random" number requirement?
-
Use a load of random number variables to store "rand" values? Well okay:
1. The random number seed solution is more elegant and uses less variables and sexp tree nodes (both a limited resource).
2. rand generates different numbers each reload of the mission. Not the functionality I'm requesting.
3. Generate the numbers in the previous mission and pass them? I figured you'd think of this like I did. Works too well since the rands in the previous mission seem to generate the same numbers each time. Replay previous mission also scuppers this idea.
Bottom line, the seeded random number functionality is there in most languages and it's incredibly useful. You can build whole galaxies with the principle. Check out Frontier (Elite 2) or Damacles. At this point it would also be the single biggest improvement that could be made to help my BHX campaign. Okay maybe after the modest sexp tree node limit increase (or dynamic memory allocation for sexp tree nodes).
I realise I'm a pain in the ass but try to humour me. My crazy ass campaign is coming on leaps and bounds and with a little co-operation from the SCP team will soon be done. Once it is, it'll pave the way for others to rip out my "code" and build there own pseudo randomly generated stuff. It's cool. Trust me :).
Edit: Doesn't FS already use seeded random numbers? I'm guessing the seed is set based on run-time or something. That's usually how it works. So surely this request just involves the implementation of one set-random-seed SEXP?
-
Edit: Doesn't FS already use seeded random numbers? I'm guessing the seed is set based on run-time or something. That's usually how it works. So surely this request just involves the implementation of one set-random-seed SEXP?
Actually, I'm pretty sure it's not a random number at all, but rather something calculated from mission time. Try displaying the results of rand in conjunction with has-time-elapsed and see what you get.
-
1. String -> number conversion sexp.
Got bored. Added this. It was only about 2 lines of code :)
Little less certain how easy it's opposite will be to add without actually having a proper string return type. Will investigate when it's not 1:30am :)
-
Proper string return types would be handy for script-eval-string.
-
Got bored. Added this. It was only about 2 lines of code :)
What? Really? One of my suggestions made it in? This is a cruel joke right? :nervous:
-
Actually, I'm pretty sure it's not a random number at all, but rather something calculated from mission time. Try displaying the results of rand in conjunction with has-time-elapsed and see what you get.
Well no random numbers are really random numbers. We all know that :D. This is just another variation on a theme. A fairly odd one though. Is there some reason it works like this? Some random event somewhere in the standard campaign that is always run at exactly the same time and requires the same random number to be generated? If so why the heck is a random number being used? The more I find out from you guys about the workings of this code the more baffled I get.
Well to be on the safe side - I guess - new rand-seeded and rand-multiple-seeded sexps would be required. If it was me, I'd just modify the default behaviour of the existing sexps because I would bet good money (albeit someone elses money) that behaviour is just wierd programming rather than serving any purpose. A random number seed set on the milliseconds of current time at mission start would be sufficient, and allow it to be modified in order to do cool stuff. :nod:
See what I did there? I nodded to subliminally influence you to agree with me. :nod:
-
What? Really? One of my suggestions made it in? This is a cruel joke right? :nervous:
Nope. It's in CVS already. All it basically does is call the standard library's function for doing the same thing.
Incidentally Goober seems to have snuck in a Key-reset-multiple SEXP when I wasn't looking :)
-
Incidentally Goober seems to have snuck in a Key-reset-multiple SEXP when I wasn't looking :)
So the original key-reset only worked the once? I can't say I ever noticed but it would explain a few things.
-
The original key-reset displayed all kinds of odd behaviour. I had a thread on it here (http://www.hard-light.net/forums/index.php/topic,30921) :)
EDIT : Added the pics again :)
-
I like the subject title. Looks like I'm not the only one who gets stressed with this stuff.
-
Told you I recognised the symptoms :)
-
Well no random numbers are really random numbers. We all know that :D. This is just another variation on a theme. A fairly odd one though. Is there some reason it works like this? Some random event somewhere in the standard campaign that is always run at exactly the same time and requires the same random number to be generated? If so why the heck is a random number being used? The more I find out from you guys about the workings of this code the more baffled I get.
Truth be told though, there's no such thing as a truely random number generated by a computer. You can do things like seed the generator based on the system clock or something like that, but ultimately it's still not random. In this particular case, it's probably just setting the seed improperly rather than doing anything wrong.
That said, since Rand has been non-random for as long as it has, it becomes a question as to whether it's better to fix the SEXP that's there and risk breaking a campaign that's built with it or to create a new actual-rand sexp that behaves more like you want and doesn't affect backwards-compatability.
-
That said, since Rand has been non-random for as long as it has, it becomes a question as to whether it's better to fix the SEXP that's there and risk breaking a campaign that's built with it or to create a new actual-rand sexp that behaves more like you want and doesn't affect backwards-compatability.
It is possible to have the best of both worlds here. I cannot think of any way that changing the original sexps to use a seed generated from current time at the start of the mission would affect backward compatability. After all, you're not changing what the sexp is providing, just it's internal workings. Once changed all that's needed is a set-random-seed sexp to override the one generated at start of mission and suddenly you have random numbers which are more random :yes: and less predictable in general but can generate numbers is a predictable order by overriding the seed :yes:.
-
Actually, I'm pretty sure it's not a random number at all, but rather something calculated from mission time. Try displaying the results of rand in conjunction with has-time-elapsed and see what you get.
Nope. It does generate a random number. It calls the rand_internal function which simply uses the standard C library's rand() function.
20. Random number SEXPs that make use of a random number seed that the user can set. Such that if a mission is called twice, and each time the same random number seed is used, any calls to random number SEXPS (or send random message) give the same result. This would be enormously useful for pseudo randomly generating missions.
Done and in CVS.
I haven't looked at random-of yet but Rand and Rand-Multiple now take an optional 3rd argument which allows you to seed the functions. I don't think I've changed anything if the seed isn't present (it should do exactly what it did before if no seed is present).
-
That's fantastic news. You have no idea how useful that will be! Well to be fair, you probably do actually. No more reloading a mission to generate an easier one. This is truly great news. Must go tell Madaboutgames now :).