Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: IPAndrews on February 19, 2006, 06:34:40 am
-
I have some code that looks like this:
every of
"capship 1"
"capship 2"
"capship 3"
true
modify-variable @Temp ( rand 0 1 )
when ( = @Temp 0 ) ( change-ship-class <argument> "NR Bin'tak" )
when ( = @Temp 1 ) ( change-ship-class <argument> "CR Primus" )
The idea is that each of the 3 capships is randomly changed to either a Bintak or a Primus (a silly thing to do but it's just test code, if it works I'll do something more useful with it). What happens in reality though is all the ships get assigned the same class! Anyone know how to get it to work?
Regards,
Ian
-
The problem is not with Every-Of. The problem is that the modify-variable only gets executed once. Only SEXPs which actually include < Argument > execute more than once. Everything else executes once.
I don't think this is a bug. I think the idea is so that you can do
every of
"capship 1"
"capship 2"
"capship 3"
true
do-something (argument)
Send-message
If you didn't do things this way the message would be sent 3 times as well. What is needed is a new SEXP that you can plug other SEXPs into that makes them execute as often as the argument is valid. Then you could do this.
every of
"capship 1"
"capship 2"
"capship 3"
true
Do-argument-Times (Something else) <----------------------- Executes 3 times
do-something (argument) <--------------------------------------- Executes 3 Times
Send-message <----------------------------------------------------- Exeecutes once.
Furthermore I've always had real problems trying to use < argument > within a when like you are using it. I'll need to rerun the mission to see what happened but I've noted down that I got erratic behaviour when I tried it.
This is actually one of the next things on my list of SEXPs to look at, along with a proper working version of random-of and the new random-multiple-of.
-
That's what I figured. Nice to have a 2nd opinion though just so as you don't know you're going insane. Back to using temporary string variables and numeric counter variables then :(. Messy, messy, messy.
-
I know. I had something I wanted to do in SoR scuppered by this and it simply wasn't worth the hassle of fixing it cause it was just a minor element of the mission.
Like I said it is on the list but there are a couple of other things I want to investigate first. The fact that someone else wants it bumps it up a couple of places though :)
-
Do-argument-Times (Something else) <----------------------- Executes 3 times
do-something (argument) <--------------------------------------- Executes 3 Times
Send-message <----------------------------------------------------- Exeecutes once.
Wow. That is so pointless :).
-
I ran into this same problem with every-time a few days ago. I guess you can get around this by simply not using every-time and just sticking with a bunch of separate events, although I have 66 arguments in one of these so it would be a little clumsy to split it up into that many. :p
-
I ran into this same problem with every-time a few days ago. I guess you can get around this by simply not using every-time and just sticking with a bunch of separate events, although I have 66 arguments in one of these so it would be a little clumsy to split it up into that many. :p
Spare a thought for me. What I have presently is (in pseudo code) is:
when start of mission then capshipname = "None"
when capship 1 arrives and capshipcount = 0 ) then capshipname = "capship 1"
when capship 2 arrives and capshipcount = 1) then capshipname = "capship 2"
when capshipname != "None" then...
1. do a huge list of stuff for the capship
2. capshipname = "None"
3. capshipcount = capshipcount + 1
Now imagine this for 10 capships :rolleyes:. I think the problem is that when-argument/every-time-argument, and every-of don't really know what they're trying to do. Either than or the default behaviour is less than useful as it is. As I simply cannot imagine and circumstance where the default behaviour would actually be useful.
Don't get me wrong, the <argument> idea is a great one. I could use it in conjunction with a condition to say... check a huge list of ships to see which have low hitpoints and then have them send a distress signal message. Saves having to do the check for every, single ship in a seperate event. Or you can just give "true" for the condition and run some set code with a different argument each time. both of which are really useful things to be able to do but you can't do either with the sexps as they stand. So what's the point?
Kara might chew me out for labouring the point here but in all honest I'm just baffled that's all. I'd love to know who came up with these things and what they were thinking :D.
-
Goober is responsible and to be honest I think he made the right call. The argument SEXPs can do both of the things you describe.
Let me give you an example
Every-time-argument
-any-of
--Ship A
--Ship B
--Ship C
--Ship D
-is-disabled-delay
--< argument >
-do-something
--< argument >
-do-something-else
--< argument >
-send-message
Quite frankly there is no easy way to send the message if the SEXP would have all nodes execute 4 times. You can't use event-true because I'm using every-time. You can't chain. The only way is to go back to modifying a variable to do a psuedo-function call.
The argument SEXPs are frequently going to be used as triggers for events too where they don't actually use the argument at all with regards to changing anything. Like this
When-argument
-any-of
--Ship A
--Ship B
--Ship C
--Ship D
-is-disabled-delay
--< argument >
-send-message
-change-iff
--Ship E
-Protect
--Ship F
etc.
In this case we haven't used the argument to change anything at all. We were just using when-argument to save having to use a giant or function to figure out when the time had come to do something. This is especially true with the number-of conditional as it is a pain in the arse to set up something like that where you want something to hapen when say 7 out of 10 ships have done something more complicated than simply being disabled.
Like I said the best way to solve this is to have another SEXP that simply triggers any nodes below it < argument > times.
-
In the example you cite above wouldn't the solution be two events:
1) An event that goes true if any-of the <argument> ships become disabled... or whatever it is you're trying to achieve there.
2) A "when" event that fires off if event 1) goes true and sends the messge.
Provided event 1) goes true if any-of the <argument> related conditions go true you'll get your one message. Once again I'm baffled. I must be missing the point or something.
-
In the first example? Nope. I'm using every-time-argument. Events using every-time or every-time-argument will never ever be true. They will always evaluate as incomplete. The only thing I can do to have a second event which is dependant on the first one setting a variable to tell it whether to trigger or not.
-
Then use when-argument.
-
Can't always do that. If you're using key-reset for instance you're buggered unless you stick it in every-time.
-
Can't always do that. If you're using key-reset for instance you're buggered unless you stick it in every-time.
:wtf: Well okay put key-reset inside every-time then! Not that I have any idea what you're talking about. Look honestly. Never mind. Forget it. I'll just waste the rest of my life pissing around with stupid flag variables and numeric counters because when-argument and every-argument are stupid. I don't care. It's fun. I've been doing it for the last two hours because the latest game engine build is too smart for it's own good an d is throwing out my last class change system. So I'm having to rework it again. It's FUN,FUN,FUN! :D :) :nod: :sigh: :(
-
Can't always do that. If you're using key-reset for instance you're buggered unless you stick it in every-time.
That point will be moot when you add key-reset-multiple. :D
-
Do you chaps find yer selves rebuilding missions when the lastest sxeps are released ? ;)
-
I've never rebuilt a mission but I've occassionally built missions that I couldn't build before :)
-
I rebuild the BHX missions every time I figure out a way to shave off a few SEXP tree nodes. It's a bit frustrating sometimes, which is why I bit Kara's head off earlier. Sorry bout that dude.
-
I have some FS2 retail-era missions with quite a bit of legacy stuff that could be made cleaner with the new sexps, but they work just fine so I don't bother.
-
Why create needless work? On that score never start making a campaign. You'd think I'd have learned from last time :D
-
I rebuild the BHX missions every time I figure out a way to shave off a few SEXP tree nodes. It's a bit frustrating sometimes, which is why I bit Kara's head off earlier. Sorry bout that dude.
That's okay. I've had days like that when programming so I recognised all the symptoms :D
-
I rebuild the BHX missions every time I figure out a way to shave off a few SEXP tree nodes.
I can imagine people like yourself, Karajorma, Goob etc redoing even campaigns rather than have messy, older style SEXPs when you've got these lovely new, better ways of doing things. :p
On that point, I fancy doing some FREDing. Get's tiresome spending most of my computer time in Studio Max.
-
I can imagine people like yourself, Karajorma, Goob etc redoing even campaigns rather than have messy, older style SEXPs when you've got these lovely new, better ways of doing things. :p
That's not the issue. More often I redo missions (multiple times) rather than have messy, older plot or execution if I think of a new, better way of doing things. :p
-
Yep. I'll only change a mission if it will result in better gameplay. If the internals are messy cause I'm using older SEXPs then so be it.
-
I can imagine people like yourself, Karajorma, Goob etc redoing even campaigns rather than have messy, older style SEXPs when you've got these lovely new, better ways of doing things. :p
Kara is right. It's no fun messing with missions with no visible improvement at the end of it. I only do it with BHX becayse I have to. The more elegent the code is the less SEXP nodes and variables it uses, an invisible improvement yes, but one which makes it more likely I can add the final finishing touches to the missions without breaking the given limits.
-
Okay, can I use when-argument/every-argument/every-of/any-of/random-of/whatever to check a list of ships and send a message every time the hits of that ships drops below a certain amount? I tried this:
$Formula: ( when-argument
( any-of
"Cap 1"
"Cap 2"
"Cap 3"
"Cap 4"
"Cap 5"
)
( < ( hits-left "<argument>" ) 50 )
( send-random-message
"<argument>"
"Normal"
"bhx damage a"
"bhx damage b"
)
)
+Name: damage
+Repeat Count: 1
+Interval: 1
+Team: 0
But it didn't work. Only worked for the first ship to drop below 50% hull. The rest didn't send the message, and the message has <argument> in it too.
-
You're using when-argument so it's only going to occur once unless you set a repeat count. (You don't mention if you have or not) However if you do it will trigger continuously because the condition will be true every time the SEXP is evaluated unless you repair the ship that is triggering it.
What you need to do is change it slighty to this
$Formula: ( when-argument
( any-of
"Cap 1"
"Cap 2"
"Cap 3"
"Cap 4"
"Cap 5"
)
( < ( hits-left "<argument>" ) 50 )
( send-random-message
"<argument>"
"Normal"
"bhx damage a"
"bhx damage b"
)
(invalidate-argument
"<argument>"
)
)
+Name: damage
+Repeat Count: 1
+Interval: 1
+Team: 0
And add a repeat count. Once you've done that it should work the way you want.
If you check the FRED Cookbook (http://homepage.ntlworld.com/karajorma/FAQ/fredcookbook.html) I actually have a very similar example listed. Unfortunately solution 3 won't work properly due to a bug in the random-of SEXP. I intend to fix that soon though :) Won't be of much use to you until you have more variables to play with though.
EDIT : I've just realised that I've never used when-argument within another Every-Time-Argument. If it works you could probably do the third solution on that page and not only have a message played for every ship but have a different message played for every ship. Certainly something worth trying to see if it works, no?
-
I'll get back to you on this, and whether send-random-message works with the seed. Haven't forgotten. Thanks for the help above. If I can get the above code to work it will be very useful in certain circumstances. Maybe I can add a random element to what ships do if they go to low hit points? Get some of them to go kamikazi and things? :D
-
Does that work for the original problem with modify-variable?
I was going to try tricking it into thinking the argument is part of the sexp, replacing this:
modify-variable
----turrettotal
----+
--------turrettotal
--------1
with this:
modify-variable
----turrettotal
----+
--------turrettotal
--------1
--------string-to-int
------------<argument>
Although I don't yet know if this actually works.
-
modify-variable
----turrettotal
----+
--------turrettotal
--------1
--------string-to-int
------------<argument>
:lol:
That you should even be considering doing that (and that I am now considering it too) I believe is conclusive proof there's something wrong with how this stuff is working. Still I'm going to experiment with this too. I don't care how horrible the hack is if it means I can replace a huge list of events with just one.
-
Although I don't yet know if this actually works.
Tried it last night. Don't think it works.
-
$Formula: ( when-argument
( any-of
"Cap 1"
"Cap 2"
"Cap 3"
"Cap 4"
"Cap 5"
)
( < ( hits-left "<argument>" ) 50 )
( send-random-message
"<argument>"
"Normal"
"bhx damage a"
"bhx damage b"
)
(invalidate-argument
"<argument>"
)
)
+Name: damage
+Repeat Count: 1
+Interval: 1
+Team: 0
And add a repeat count. Once you've done that it should work the way you want.
Hey this code works, and is incredibly useful! One for your cookbook I think. I can replace so many similar events with one event that covers multiple ships this way. With certain limitations of course. The "I'll only run if I involve <argument>" thing. Oh, try adding a nested conditional in there (any conditional you care to mention) and the event will stop working. But hey, let's get positive again. It's better than nothing! :cool: