[AdmiralRalwood]

the point is, an image still gets rendered by gr.drawImage if I call the associated function in the script locally, but not from script-eval in FRED.

With the code I gave you, gr.drawImage() should always be being called with the same timing, regardless of if readfile.showcbanim() is called from script-eval or not. Did you make any other changes aside from "!=" -> "~=" and sprinkling some warnings?

[Parias]

the point is, an image still gets rendered by gr.drawImage if I call the associated function in the script locally, but not from script-eval in FRED.

With the code I gave you, gr.drawImage() should always be being called with the same timing, regardless of if readfile.showcbanim() is called from script-eval or not. Did you make any other changes aside from "!=" -> "~=" and sprinkling some warnings?

Oh, duh! I'm sorry, I just realized it was actually my leftover script-eval from the near-blank FRED mission I'm using to test this that was causing the anim to disappear so fast - when it triggered (one second into the mission), the image vanished.

I just re-pasted the script in to test, with my only changes being the "if not nil" bit and adding "readfile.showcbanim(some line number)" to execute the script locally at the bottom of $On Game Init.  I then removed the event from FRED and the anim now automatically loads and plays all the way when the function is called locally..... but it only does it once and doesn't loop, which is OK since I probably want to use FRED to ultimately control the looping anyways (when I figure out why the FRED call won't load the image in the first place).

So I guess we're at roughly the same symptoms - the image definitely will load with your version of the script and play through, but only does it once (whereas mine loops indefinitely). And in either case it still doesn't draw anything if I try and invoke the function from FRED.

Have you checked the coordinates where the script draws the animation?
This part seems a bit suspicious:

Code: [Select]

  screenx = gr.getScreenWidth()
  screeny = gr.getScreenHeight()


Admittedly I haven't paid much attention to this just because the image DOES render fine if I call the script locally - it's only when I'm using script-eval in FRED to call it that it doesn't appear at all. Would this cause some kind of strange variance in the coordinates used?

Just to be sure, I tried statically setting the gr.drawImage xy arguments to 200, 200, but this made no change in my symptoms (still works fine from the script and appears where expected, but doesn't appear when triggered from script-eval)

Here's the basic event tree I'm using when trying to call the event from my mission, if it matters:

Code: [Select]

#Events ;! 1 total

$Formula: ( every-time
   ( has-time-elapsed 1 )
   ( script-eval
      "readfile.showcbanim(2)"
   )
)

(Note: I've tried both "every-time" and just "when" as conditionals)

This 'should' load cb_sm1-01_d as per what I have in cbanims.txt and play it as per the function. And it does - my ba.warning hooks throw alerts indicating it's processing the image file and advancing the associated frameindex, and I can even see it expressly loading the .ani asset (cb-sm1-01_d.ani in this case) in fs2open.log:

Code: [Select]

Got event GS_EVENT_ENTER_GAME (2) in state GS_STATE_BRIEFING (10)
Entering game at time =  70.523
ANI cb_sm1-01_d with size 440x200 (21.9% wasted)
ANI cb_sm1-01_d.ani with size 440x200 (21.9% wasted)
WARNING: "i is 15.149917602539, totalframes is 171" at lua.cpp:12105
Frame 46 too long!!: frametime = 4.433 (4.433)
WARNING: "i is 18.899917602539, totalframes is 171" at lua.cpp:12105
Frame 47 too long!!: frametime = 1.084 (1.084)
WARNING: "i is 22.649917602539, totalframes is 171" at lua.cpp:12105

But nothing actually appears on the screen if I do it this way.

You can try all this yourself if you want as well - this should work with an unmodded base game (or any other mod really). After deploying the script, create data\scripts\cbanims.txt and throw a line in with the desired animation (i.e. cb_sm1-01_d ). Then either execute the function in the script locally (i.e. from $On Game Init or whatever), or call it via script-eval and compare the difference. I'd actually be genuinely curious if anyone else can reproduce this, because I'm starting to wonder if I just have something really, really strange with my environment and that this really "should" be working. I'm almost tempted to try a clean install.

I guess to be clear, I should also mention I'm running all this on 3.7.2 RC3.

[m!m]

I just tested your script and it works perfectly. I tried starting it from a script and from FRED and it worked both times.

[Parias]

Arrrrgh, it must be something on my end then. OK, I'm going to go for a clean slate and try to see what's wrong specific to my installation. Thanks for checking.

Just for comparison, can you show me what FRED events you used and what build you're running?

Edit: Well this is embarrassing.. it was me all along. I cleaned out my tables folder a bit (which just had a scripting.tbl and an old scripting.bak file in it - I removed the .bak), cleaned out a couple of random .patch files from the root of my FS2 folder that had no godly reason to be there, and wiped / created a whole new blank mission to start from in FRED.

I can now do script-eval after has-time-elapsed (whatever) in FRED and the anim actually will appear and trigger as expected when the mission plays. Hooray!

I have no godly idea what exactly changed that was previously preventing script-eval from giving the expected results (vs calling the function from the script itself), but it seems like it's working now. God, 2 days wasted on this problem..

Thanks for helping me look into this. I may still have some more questions, but at least I've gotten past this silly blocker -- and learned a lot of valuable stuff along the way.

[AdmiralRalwood]

cleaned out a couple of random .patch files from the root of my FS2 folder that had no godly reason to be there

A loose .patch file will never cause any altered behavior, but I'm glad you solved the problem.

but it only does it once and doesn't loop

Sorry, I assumed your end goal was to play an animation once, not loop indefinitely. All you have to do is restore the modulo operation and remove the ">= totalframes" check to make it loop until another animation plays (or cbanim gets set to nil).

[Parias]

cleaned out a couple of random .patch files from the root of my FS2 folder that had no godly reason to be there

A loose .patch file will never cause any altered behavior, but I'm glad you solved the problem.

but it only does it once and doesn't loop

Sorry, I assumed your end goal was to play an animation once, not loop indefinitely. All you have to do is restore the modulo operation and remove the ">= totalframes" check to make it loop until another animation plays (or cbanim gets set to nil).

I totally agree - I honestly couldn't find much in my FS2 environment that seemed like it would have caused the issue, and even now I'm still baffled as to what exactly was causing the very specific symptoms I was seeing. You're likely correct in that it had nothing to do with the .patch file - if anything, I'm thinking maybe my FRED mission had gotten screwed up somehow and making a totally fresh one somehow helped fix it. Again totally lost on why, as I had a really simple setup and there wasn't really much room for error... I'm content to leave it a mystery for now though.

And that's OK - I've been pretty vague about my intentions with this script anyways. I've put the modulo bit in and also added a second function to set cbanim to nil. So far this seems to be working exactly as I need; I can start the anim and have it loop indefinitely, then stop it on-demand with a second function, all from FRED. This is perfect!

Thanks again everyone for all your help!

[Parias]

Sorry, one more question (and from past SEXP experience this one's probably a doozy): Is it possible to get this sort of script working properly in multiplayer?

While this all works great for the multiplayer host, client systems don't seem to process the script at all when script-eval is called.

On a whim, I tried throwing out script-eval completely from my mission events, and switched to a variable-based approach instead with the following event / variable tree:

Code: [Select]

$Formula: ( when
   ( has-time-elapsed 3 )
   ( modify-variable @playanim[0] 3 )

(...)

$Variables:
(
0 "playanim" "0" "number" "network-variable"
)

I then added this code to the $On HUD Draw hook in my script:

Code: [Select]

if (mn.SEXPVariables['playanim']:isValid()) then
if (mn.SEXPVariables['playanim'].Value) > 0 then
ba.warning("Trying to process your variable dood")
readfile.showcbanim(mn.SEXPVariables['playanim'].Value)
mn.SEXPVariables['playanim'].Value = 0
end
end

This listens constantly for the state of the 'playanim' network variable in my mission. If it changes to something more than 0 (i.e. a usable index from my cbanims.txt list of animation filenames to play), it'll run the function to actually play the anim in question. It then sets the variable value back to 0 because if I don't, I think the function gets stuck being called over and over again from scratch each frame and doesn't have time to actually play the anim (nothing appears); I just want to trigger it once per variable-change. There's also of course a debug catch at the top just to help further confirm it's being triggered.

This again works awesome on the host - because I'm using a "network-variable" type I thought it would work on the client as well, but nothing happens. If I run both the host and client in debug mode, only the host gets the "Trying to process your variable dood" debug message and renders the anim. If I move the debug message up a level (so just checking if if (mn.SEXPVariables['playanim']:isValid())) then both the client and host systems will spew the debug message (still no anim play client-side of course), but I can't seem to get the client system to recognize at all that the network-variable has switched to a valid range.

Am I doing about this the wrong way? What I'm ultimately trying to do is hack together my own functional command-briefing anims for multiplayer co-op (since they apparently aren't possible normally), but maybe I'm being too ambitious here What I have so far works surprisingly well though:

[AdmiralRalwood]

What I'm ultimately trying to do is hack together my own functional command-briefing anims for multiplayer co-op (since they apparently aren't possible normally), but maybe I'm being too ambitious here

...A bit of an ambitious goal, yes. That is quite the impressive hackjob, though.

I vaguely remember someone intending to eventually add multiplayer support for command briefings, although that was some time ago; I personally haven't even tried to look into multiplayer code yet.

[Parias]

Geez - do you ever sleep AdmiralRalwood?

Yeah, I actually asked about this a few years back and was advised it basically wasn't simple to do. With all the advances in LUA support, I decided it was finally time to try a creative workaround.

I do also know karajorma's put a ton of effort towards making sure a lot of the newer SEXP's work correctly in multiplayer (here, for example), but I have no idea if script-eval is one of them.

That's why I figured if nothing else, a network-variable would do the trick (since... I guess it's supposed to work properly over network sessions? I'm actually unclear on the technicalities of it), but in my case it doesn't seem to be working at all.

I'm so close to having a basically-functional solution for this... just need to clear this final hurdle.

[AdmiralRalwood]

Geez - do you ever sleep AdmiralRalwood?

Pacific coastie, here; it's not even midnight yet.

I figured if nothing else, a network-variable would do the trick (since... I guess it's supposed to work properly over network sessions? I'm actually unclear on the technicalities of it), but in my case it doesn't seem to be working at all.

That was, indeed, my impression of what network-variables were supposed to do, but if your code is showing that the variable is valid but staying as 0 on clients... a quick look at the code says that modify-variable is supposed to update network variables with clients, yet it sounds like that's not happening for some reason.

EDIT: Looks like the Lua interface calls sexp_modify_variable() when you set the value of a SEXP Variable from within a Lua script. If the two are happening in the same frame, the clients are probably getting both updates at the same time, and therefore have no time to start the animation.

[Parias]

EDIT: Looks like the Lua interface calls sexp_modify_variable() when you set the value of a SEXP Variable from within a Lua script. If the two are happening in the same frame, the clients are probably getting both updates at the same time, and therefore have no time to start the animation.

Thanks for checking the code. That almost makes sense, but at the least shouldn't I be seeing the debug pop-up on the client (which should happen earlier in the execution, just before the function is called and the SEXP variable is reset to 0)? I don't even get that, leading me to believe the client never even realizes the variable is set to 3. I see it happen on the host system at exactly the same time, so I know the code-flow is working (and yes, I've been keeping my script / table folders synchronized between client and host, and they are both running debug builds)

Semi-related, but woa - I just found this and it sounds like exactly what I need!

Many of your missions for Diaspora will require you to start with a tube launch from a battlestar. This is a significant problem in singleplayer but is even more difficult to achieve in multiplayer since you need to consider what to do if the player respawns. In Diaspora R1, tube launches were handled mainly using SEXPs. This approach is rather cumbersome and as a result Diaspora R1.5 introduces a brand new script based system which can be used in both multiplayer and singleplayer missions. For multiplayer missions, you can't use script-eval because it only evaluates on the server. Instead you need to use the multi-eval SEXP which allows you do say which computers evaluate the script.

This sounds Diaspora-only though - how do I get ahold of this for normal Freespace / SCP use?

[m!m]

I remember seeing that SEXP in code review somewhere but it doesn't look like it is in trunk yet.

[AdmiralRalwood]

at the least shouldn't I be seeing the debug pop-up on the client[...]?

No, because the client is getting the update that the variable was set to 0 at the same time that it was getting the update that the variable was set to 3, so the client never has a chance to execute the code while the variable is non-zero.

Semi-related, but woa - I just found this and it sounds like exactly what I need!
[...]
This sounds Diaspora-only though - how do I get ahold of this for normal Freespace / SCP use?

Actually, looks it's not even in Diaspora, or at least not in 1.1.

[niffiwan]

Here's the code, based on r10253 so it'll probably need a bit of tweaking to apply to trunk.  If you want to give it a spin some one will need to compile a custom test build for you.

[Parias]

No, because the client is getting the update that the variable was set to 0 at the same time that it was getting the update that the variable was set to 3, so the client never has a chance to execute the code while the variable is non-zero.

Ah, that makes sense - your logic is sound then. I guess I could tell for sure if I set something up to just throw a message if the client sees the variable change without all the extra functionality around it.

And thanks Niffiwan - I just dusted off my Visual Studio installation, figured out how to get and compile the current source from SVN, and managed to hack together the changes from the patch into the relevant source files (you're right, a fair amount of manual work was needed here just due to the offset placement of just about everything).  I don't really have any idea what I'm doing, but so far it looks like I've been successful in getting the new "multi-eval" SEXP to work great on the host side. I'll do a proper client-side test later today when I have access to the necessary resources.

If I get it working, I guess I'll submit a formal request to get it into the main branch (particularly since I now know first-hand it won't take a lot of work to do aside from the requisite labor around the code review)  and work with what I have for the mean time. I'll advise how this goes.

(BTW, should new SEXPs appear in FRED automatically, or do you need to recompile FRED for that to happen? I didn't see multi-eval appear in my list of available items and had to add it to the mission file by hand instead)

[AdmiralRalwood]

No, because the client is getting the update that the variable was set to 0 at the same time that it was getting the update that the variable was set to 3, so the client never has a chance to execute the code while the variable is non-zero.

Ah, that makes sense - your logic is sound then. I guess I could tell for sure if I set something up to just throw a message if the client sees the variable change without all the extra functionality around it.

What you could have done is just made it so that instead of setting the variable to zero, it set a Lua variable to the current value of the network variable and only called the function if the two values differed (and special-cased 0 to stop the animation, for instance). Then you wouldn't have to screw around with custom builds.

BTW, should new SEXPs appear in FRED automatically, or do you need to recompile FRED for that to happen?

You need to recompile FRED.

[Parias]

True! But then I wouldn't have a flimsy excuse for mucking around in the source code.

In all seriousness though that might actually be a good option to go with. I'm going to try multi-eval for now anyways just because I find it a bit more straight-forward to leverage (and having it available may provide wider-scale uses down the road), but if I don't get any traction with getting it into the main build, I might just do this instead. Above all else I don't want to have to fart around with my own custom branches of the codebase that will quickly fall out of date this just to make it work.

And I just recompiled FRED and see the new SEXP available now - thanks!

In other news, the problems never end... I fix one issue and run square into another:



Technically off-topic at this point, but arrrrgh.

This happens right as the mission starts (and the briefing stuff is supposed to appear) only on the client end, not the host (I've separately tried w/ both a dedicated server and client / host in-game setup). Line 21120 is multi_sexp_show_subtitle_text() -- I think I'm throwing too much at the show-subtitle SEXP. To work around the character limit, I'm triggering multiple show-subtitle events (each with associated messages less than 255 characters in length) when I make the briefing texts appear... if I had to guess, I'd suspect that this must be overloading the function that sends this stuff across the network.  I thought splitting this into separate SEXP calls that just happen to occur at the same time (one immediately after the other in the same event) would work, but maybe it's still batching it all together and firing too much text across at once. 

I'm going to try splitting them up w/ 1-second delays and see if that helps.

[niffiwan]

That kinda looks like memory corruption and a code bug.  Can you grab a stacktrace using the debugger?  Or maybe post the relevant mission and the steps to reproduce the crash?

[Parias]

Yeah, I was doing a bit more reading and thinking it seemed pretty similar to this report, or at least might contribute to the note at the end about there potentially being other limits elsewhere in the code potentially impacting things. This also might be sort of a different issue (since in this case we're supposed to have a limit of 255 characters per-subtitle event, vs the 31 character limit referenced there), but one way or another I'd be super-happy if this kind of problem could be fixed so that I didn't have to try and work around it.

I'll collect some more details and then fire this into Mantis as a separate thread to avoid confusion with this topic.

[Parias]

Looks like I wasn't quite correct - from what I'm reproducing, the crash actually seems to happen for clients when show-subtitle-text is triggered with a message that has more than 32 characters. The SEXP is actually supposed to support 255 AFAIK, and it does for the host system, but clients just shoot themselves in the head with that much text.

I actually dug fairly deep into this and I think I've not only found the cause, but compiled a fix for myself as well to get past this issue (although with a request for a better solution if one is needed for the main branch). My full report is here. Is this the right way to do a bug report?

With this fix put in place and multi-eval enabled, this is looking good! Host and client systems alike can play the cbriefing fairly consistently (some text-formatting issues aside) and transition into the rest of the campaign. I still have a lot of work to do (resolution scaling in particular), but things are rapidly approaching a 'playable' state. I'm going to test the heck out of multi-eval, and if I can't find any problems I'll probably formally request it get added to the main build; I'd really like to see it in there if possible