Hard Light Productions Forums
Modding, Mission Design, and Coding => The FRED Workshop => Topic started by: 0rph3u5 on October 16, 2016, 07:47:19 am
-
So, I have an effect I am pretty proud of (even if it is kinda simple and ridiculous) but it is currently build on events with "every-time" as conditional - which I didn't think through back then and until recently didn't reconsider. However some time ago, I tried to make a recording of the mission it is implimented in and as it is with wrongly used "every-time" the frame rate dropped to no small degree.
The original effect worked like this:
(http://i1020.photobucket.com/albums/af321/0rph3u5/FS%20Open/flicker-effect-v1-a_zpsytcsqf16.png) (http://s1020.photobucket.com/user/0rph3u5/media/FS%20Open/flicker-effect-v1-a_zpsytcsqf16.png.html) (http://i1020.photobucket.com/albums/af321/0rph3u5/FS%20Open/flicker-effect-v1-b_zpsrjriurmw.png) (http://s1020.photobucket.com/user/0rph3u5/media/FS%20Open/flicker-effect-v1-b_zpsrjriurmw.png.html)
So every frame in between the NTCv Congreve's arrival and destruction the engine would randomly set two variables to either 0 or 1. Each variable was used as a trigger for the following events - if the variable was 1 an event would trigger that activated the glow maps/points; if the varibale was 0 an event would trigger that deactived the glow maps/points.
Not exactly how this was intended to be used but it worked.
Now I am building a new version of the effect based on "when" events and hit a little snag: The glow-maps go out as intended but never get back on and subsequently don't flicker.... (as there aren't all ships implimented in the mission yet I can't see if the equivalent stuff for the turrets works or not)
(http://i1020.photobucket.com/albums/af321/0rph3u5/FS%20Open/flicker-effect-v2-a_zps0klb8wqp.png) (http://s1020.photobucket.com/user/0rph3u5/media/FS%20Open/flicker-effect-v2-a_zps0klb8wqp.png.html) (http://i1020.photobucket.com/albums/af321/0rph3u5/FS%20Open/flicker-effect-v2-b_zpscc5corqf.png) (http://s1020.photobucket.com/user/0rph3u5/media/FS%20Open/flicker-effect-v2-b_zpscc5corqf.png.html) (http://i1020.photobucket.com/albums/af321/0rph3u5/FS%20Open/flicker-effect-v2-c_zpsaesbbdfv.png) (http://s1020.photobucket.com/user/0rph3u5/media/FS%20Open/flicker-effect-v2-c_zpsaesbbdfv.png.html) (http://i1020.photobucket.com/albums/af321/0rph3u5/FS%20Open/flicker-effect-v2-d_zpsx8exvlcn.png) (http://s1020.photobucket.com/user/0rph3u5/media/FS%20Open/flicker-effect-v2-d_zpsx8exvlcn.png.html)
Using the varibale as trigger here might be redundant (as you can basically make the check if the Naxos is at <20% hull a condition on its own) but otherwise I can't see a fault in the events.
The only stuff I can come up with at the moment would be that Interval Time needs to be higher but don't have that covered with the "event-ture" stuff?
-
The big problem is that none of Naxos power flicker A, B or C will ever evaluate to false. They'll only ever evaluate to event-true or event-incomplete until the end of the mission.
-
*faceplam* I was not seeing the forest for the trees *faceplam-harder*
Those "event-false-msec-delay"s should be "event-true-msec-delay"
EDIT: changed, still not working as intended...
-
Same problem?
-
Same problem?
Not exactly ... They trigger now and the random time inbetween seems to work (tested by adding a message to each event) but there is no visible activation/deactivation of the glow maps...
-
Sounds like the problem isn't your events then. Make a simple test mission without the repeats and check that the glowmaps and glowpoints can be turned on and off that way.
-
I found the time to do as you asked ...
When I have four events without repeats do it, it works
When I have two repeating events do it, it doesn't
Test mission added - if it works for you I might have to check with another build
[attachment deleted by admin]
-
Related Issue:
This...
(http://i1020.photobucket.com/albums/af321/0rph3u5/FS%20Open/turret-effect_zpsle1q0syh.png) (http://s1020.photobucket.com/user/0rph3u5/media/FS%20Open/turret-effect_zpsle1q0syh.png.html)
(repeat count and intervall time are valid for both)
... seems to be shutting down all turrets on the Naxos (a Deimos, if you don't remember her from the main FS2 campaign) except the missile launchers. Am I just undercutting the Medium-difficutlies AIs reaction time, or is the intervall time all wrong?
-
You're using number-of incorrectly. Since you aren't testing for anything using <argument> in the trigger for the event all the arguments in the list are being passed to the action part of the event.
I'll test the mission when I'm sober.
-
You're using number-of incorrectly. Since you aren't testing for anything using <argument> in the trigger for the event all the arguments in the list are being passed to the action part of the event.
Okay... I will see if I can come up with something that both contains the <argument>-string and comes to true no matter what... Too bad I can't just set it to test if <argument> has the subsystem type "turret"; it would also be a lot easier if it were a list of ships and not subsystems...
-
Instead of using number-of use random-multiple-of and an interval of zero.
Basically test until a random number of turrets are locked and then stop testing. With an interval of 0 it will choose a new turret each frame. As long as you lock and then invalidate the argument, you'll get all the turrets locked in a few seconds even if someone is playing at 4 fps.
-
Any update on the glow-maps-flicker thing?
Also, re-did the turret thing from the buttom up with additional variables.... which came with "****, did I just break it all?"-scare (seriously, FRED should prompt that a variables exceeds the 31 characters limit BEFORE you save and it becomes an Error message)
-
Any updates on the glow-maps issue? - Do I need to provide the test mission again?
-
I've been forced to reinstall Windows so I'm running rather behind on things I need to do. I should have the mission file somewhere. If I haven't checked this out by the end of the weekend, remind me.
-
I've been forced to reinstall Windows so I'm running rather behind on things I need to do. I should have the mission file somewhere. If I haven't checked this out by the end of the weekend, remind me.
Reminder
-
I ASSUME (since it's not visible in the image) you placed the infinity value (I mean the 999999) in the "repeat" box and "trigger" 1. The event will trigger only once and repeat for infinity. If you tie this with turning the glow maps off then it will be off forever. This will slow down the computer because it will execute the event for infinity.
Try this:
Basically the same SEXPs but place the infinity value to the "trigger" box and "repeat" box value of 1.
Disregard this comment if my assumption is wrong.
-
Oh yes, I forgot. If you use "event-true-delay" or "event-true- msec-delay", it will not work. Once the event is true or triggered, any subsequent trigger like setting trigger count more than 1, it will always be true until the end. You may use toggle variables and duration variables in conjunction with the "everytime" condition or "when" triggered multiple times. Anyway, I will make a mission concerning this and post this here. I find this intriguing and I like daunting tasks. I really do.
-
The trigger was not the problem, it actually worked. There are some imperfections in but that's for one is basically works.
I am attaching the test mission again so you can see for yourself.
[attachment stolen by Russian hackers]
-
I'll check it out. Is dependent on a mod? No matter, the events will still be there even if assets will be missing.
Downloading now.
-
I've been forced to reinstall Windows so I'm running rather behind on things I need to do. I should have the mission file somewhere. If I haven't checked this out by the end of the weekend, remind me.
Reminder
Okay, I have time to test today.
-
Ok. I pkayed your test mission just now and read your events.
Just as I have suspected. You used the "event true delay" SEXP. The first cycle up is fine. But the second stage is the problem. You placed a condition that will be true all throughout even with the delay. Once an event is true, it will always be true repeatedly for 1000 times. Essentially, the computer executes these repeats in micro seconds. As if nothing has happen. The delay will not work because it ALREADY returned true the first time. What had happen is that the events "cycle trigger" a to c happened all at once for 1000 repeats. The ON and OFF were actually executed at the speed of electricity so, again as if nothing has happen. If you see command messages displaying alternately, it does not matter. Two messages will display one at a time even if chained with 0 time interval. Actually, the game already executed the 1000 message repeats the moment first message was said and the game displays them one at a time. Like I said, use toggle and duration variables in conjunction with "everytime" or multiple triggers of "when" condition I am making a test mission now and will send it to you.
-
That was quick. I made this mission for your reference. The Orion ship will flicker on and off in 50 microseconds interval for 2 seconds each time you fire your weapons.
I did not use the "everytime" condition instead I use the "when" condition with a "trigger count" of 999999, not "repeat count." I used variables here to serve as logical switches.
This is just a matter of juggling the "toggle" variables to create a seesaw effect between the ON and OFFs. Of course, the duration between the ONs and OFFs must also be set in the "CycleInterval" variables. There are two of them. Each for ON and OFF.The default value for these "CycleInterval" variable is set to 5, that is 50 microseconds depending on the speed of your computer. You can adjust these variables to your preference. There is also the duration of the flickering cycle length set in the "Repeats" variable. The value set here is 15, approximately 2 seconds. You can also adjust this to increase the duration of the flickerings. There are a number of modify-variable SEXPs setting the default value for these adjustable variables and several condition checking for those default values. If you adjust the defaults for the 2 "CycleInterval" variables and the "Repeats" variable, they must all match. Lastly, the "Trigger" for now is tied to weapons firing. You can change this to any event of your choosing.
[attachment stolen by Russian hackers]
-
I didn't see Herkie's reply until I'd already tested it myself but he's definitely correct about the cause. Let me explain how I realised what was going on cause it's a good example of the event.log being useful. First thing I did was go into FRED and tell FRED to log the last two events evaluating to true in the event log. When I ran the mission, I got this.
Mission lightshow test loaded.
Event: cycle trigger b at mission time 19 seconds (19712 milliseconds)
when returned TRUE
send-message returned TRUE
activate-glow-points returned TRUE
activate-glow-maps returned TRUE
and returned TRUE
or returned ALWAYS TRUE
is-event-true-msecs-delay returned ALWAYS TRUE
rand-multiple returned 1185
= returned TRUE
Variables:
trigger[1]
Event: cycle trigger c at mission time 19 seconds (19712 milliseconds)
when returned TRUE
send-message returned TRUE
deactivate-glow-points returned TRUE
deactivate-glow-maps returned TRUE
and returned TRUE
is-event-true-msecs-delay returned TRUE
rand-multiple returned 4934
= returned TRUE
Variables:
trigger[1]
from that you can see that cycle trigger b & cycle trigger c are evaluating to true in the same frame. If you look further down the log you'll see that's always the case. One event turns the lights on, but in the same frame they get turned back off again.
Just out of interest, how did you notice the problem herkie?
-
In the events log. Those event were triggered at the same time. All with the same time stamp in my end. If you have a faster computer, still the difference is infinitesimal. Well, this created a computer dilemma. So nothing happened. I mean something did but we cannot see it.
Actually, I already know the moment I saw the events. "event-true-delay" or the one with "msec" dosen't work with re-triggers.
I made a mission that renders it properly. See my previous post.
-
The events log is really helpful. It is a tracer to debug missions.
-
Oh yeah, why didn't I think about it earlier? You can use two events for ON and OFF with logical operator "time-has-elapse" coupled with "mission time" + (msec) as its value and have them trigger multiple times. And only use one "toggle" variable for ON and OFF. The "mission time" + (msec) for ON event should be longer to make them execute alternately. I have not done this so it might not work. If it will, then this is simpler than the previous test mission i sent you.
-
Ah bugger. I checked. The "has-time-elapse" SEXP does not accept microseconds value. This can work but the ON and OFF flickers will be in "seconds." I don't think that's what you want. So my test mission is still the viable solution.
-
Ok. I pkayed your test mission just now and read your events.
Just as I have suspected. You used the "event true delay" SEXP. The first cycle up is fine. But the second stage is the problem.
I use the "when" condition with a "trigger count" of 999999, not "repeat count." I used variables here to serve as logical switches.
Okay, I got that. I will see if I can work up a new version once I am done with implimentation of the script which deal with mission critical IFF-changes (see here (http://www.hard-light.net/forums/index.php?topic=93425.0))