Register Calendar Latest Topics
 
 
 


Reply
  Author   Comment   Page 2 of 2      Prev   1   2
Dave Thaler

Registered:
Posts: 295
Reply with quote  #16 
I don't mind ships having to go back to the login screen to respawn, that's fine.   My experience with scripted missions so far though is that you can't get back in by clicking Ready to Play on the main screen of that ship - nothing happens, it just sits there at the login screen.
ryleyra

Registered:
Posts: 2,459
Reply with quote  #17 
That's not my experience. I've found that if a ship is destroyed, I just need to use if_exists and a flag variable to detect when it is created again. But then, that's with ships that are not specified in the script. I suppose it's possible ships you create have to be explicitly destroyed when they are blown up or they can't be logged back in.

The behavior may also have changed in the latest version. Let me do a test and I'll let you know what I find out.
Fish Evans

Registered:
Posts: 350
Reply with quote  #18 
to spawn a ship via ready to play a main screen needs to be selected by the person hitting ready to play.
Dave Thaler

Registered:
Posts: 295
Reply with quote  #19 
Quote:
Originally Posted by Fish Evans
5) I belive so.. but im not 100% you can cirtenly direct a warning pop up to a specific ship

Code:
 <warning_popup_message message="Test" consoles="E" name="Artemis" /> Or <warning_popup_message message="Test" consoles="E" player_slot="0" /> 


Doesn't work in general.  player_slot is ignored for warning_popup_message (the message goes to ALL ships).  And the name attribute only works for Artemis (any other name and the message won't go to any ship).

So as far as I can tell there is no way for a popup message to be directed to a ship other than Artemis.
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 1,716
Reply with quote  #20 
The entire scripting system is built to work for just one player ship with its main screen as the primary display of the server. Once you stray away from that mode of play fewer and fewer elements of the mission scripting system will work.

Put another way: the scripting system is 100% functional for a single ship with all players in the same room watching the main screen on the server.

It is perhaps 95% functional if you have one player ship with remote players who cannot see the server's main screen.

It's about 80% functional if you have multiple player ships on the same side.

It's about 70% functional if you have 3+ player ships on 3+ different sides.

It drops down to 60% if you throw in a game master and limited sensor range. We discovered this in this year's LARP when a Game Master tried to work with three player ships on three different sides with very short sensor ranges. In this mode the game master loses a lot of its omniscience.

__________________
"The Admiralty had demanded six ships; the economists offered four; and we finally compromised on eight."
- Winston Churchill
Admiral Legasse

Registered:
Posts: 12
Reply with quote  #21 
Quote:
Originally Posted by Mike Substelny
It drops down to 60% if you throw in a game master and limited sensor range. We discovered this in this year's LARP when a Game Master tried to work with three player ships on three different sides with very short sensor ranges. In this mode the game master loses a lot of its omniscience.


As one of the NPCs for the LARP, we noticed that even with limited sensor ranges obscuring player ships from one another on the science screen, we could still easily see other player ship locations on LRS. This made finding and recovering the Agamemnon trivial for the pirates.
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 1,716
Reply with quote  #22 
Quote:
Originally Posted by Admiral Legasse
As one of the NPCs for the LARP, we noticed that even with limited sensor ranges obscuring player ships from one another on the science screen, we could still easily see other player ship locations on LRS. This made finding and recovering the Agamemnon trivial for the pirates.


Yes, that was one of the unforeseen issues that spoiled the LARP. The Agamemnon was supposed to be visible only to the Game Master until much later in the game. Instead it was visible to the players but hidden from the Game Master! This is a serious bug in the Artemis software that no one knew about until it was too late.

Thom now knows about this bug, but since no one ever reported it before we can conclude that Game Mastered missions with three different side_values are very rare, so fixing the bug is a low priority.

__________________
"The Admiralty had demanded six ships; the economists offered four; and we finally compromised on eight."
- Winston Churchill
Dave Thaler

Registered:
Posts: 295
Reply with quote  #23 
Thanks folks for all the hints here.  We ran the multi-ship scripted mission ("The Diana Operation") at Norwescon this past weekend and it went off great.   There were some technical glitches at the beginning (server crashed for some reason), but switched to another server and it works.  We ran it twice, and both times the mission was completed successfully.   It included a LARP (Away Team) and video and a shuttle, all with 2.5.101.  Those will hopefully be much easier in 2.6 but I managed to find enough workarounds to make it work as follows.

Quote:

1) Is there any way to add another message to set of stock messages possible to send from one player ship to another?


Just allowed voice communications (via mumble).

Quote:

2) Is there a way to make warning_popup_message use the Fighter console?


Ended up not using the Fighter console.  For a shuttle, I used a Scout ship, and used mission coding to let it launch and dock on capital ships.  The other advantage of that approach is that it allowed a shuttle to dock on a different ship than the one it launched from, although no one used that fact during Norwescon.

Quote:

3) Is there any way to distinguish *which* ship sent a keypress?

4) If more than one console is enabled for getting keypresses, is there any way to distinguish which console sent a keypress?


Minimized the use of keypresses to things that were ok for any ship to send and found other ways to do things specific to a single ship (thanks to ryleyra's thread here).

Quote:

5) Is there a way to have a Comms message only be visible by one ship?  (I'm thinking a workaround is to use a warning popup message to comms on the one ship.)


The workaround I ended up using was to send "restricted" warning popup messages only to the Observer screen, and adding Observer as a second console on the same system running the intended ship's main screen.  That way, the popup would appear on that ship's main screen only.

Quote:

6) Is there a way for a script to get or set a property indicating whether Red Alert is on? 

7) Is there any way for a script to get or set the Pshock count? mission-file-docs.txt mentions countHoming, countNuke, countMine, and countECM but not anything for pshocks.

8) Is there any way for a script to get or set how many coolant are assigned to a given subsystem?


Didn't use any of the above due to lack of capability.  Mission used other things from ryleyra's thread instead as noted above.

Quote:

9) Is there any way to get or set upgrades for a ship? (I'm thinking a possible workaround for adding an upgrade is to create an anomaly of a given type, right on top of a player ship.)


Script creates an anomaly of a given type right on top of a player ship.

Quote:

10) Is there any way to tell whether a given console has actually been selected?  (For example, to delay a mission intro text message until someone actually chooses a Comms console.)


Workaround was to add a button on the Game Master console to cause any critical Comms message to be resent.   I did notice that the GM console has to be selected when the mission begins though or buttons won't appear.   That is, joining late as GM means you won't get the buttons.  Seems like a bug.

Quote:

11) Any way to store the value of a ship's property (angle, energy, etc.) in a variable?  I know how to copy a property from one object to another, and I know one can set a property to the value of a variable, but not the reverse.   The two workarounds I can think of are: (a) have a bunch of if_object_property events to test whether the value is in different ranges, and set a variable accordingly which just gives a rough approximation depending on how granular the ranges are, or (b) create a dummy object to copy the value to and use that object other than the variable, but then you can't use it in math expressions.


The workarounds from Fish and Mike work, and in the final mission I ended up using a variation on Fish's technique since a gradual match was fine.

Quote:

12) Is there any way to script for a variable number of ships, but still allow them to spawn when the game starts?   As far as I can tell, even when Ready to Play is select on the main screen of another ship, it will not spawn until you unselect it and select Ready to Play after the mission has been started on the server.  The only time they spawn immediately in 2.5.101 is if the script explicitly creates that ship, which means it's not a variable number of ships.  A Co-op Game allows them to spawn immediately but I can't find a way to make a Scripted Mission work the same way.


The suggestions give by various folks in this thread are all good, but I never got to implementing them as the issue was easy enough to work around manually.  I did delay the initial events until some seconds after the first ship spawns, to make sure multiple ships would have a chance to see the initial events.

Quote:

13) A (non-scripted) co-op mission lets player ships respawn if they are destroyed.   Is there a good way to provide this option in a scripted mission?


I ended up adding a way on the GM screen to allow the GM to respawn a destroyed player ship, but didn't end up needing it during the real games.   Overall the goal was that the GM screen should never be required, but was available to resolve any issues with the screen at runtime, which I did need to do a couple times to work around apparent bugs (whether in Artemis or in the mission I am not sure, but we ran the mission twice and I never had to do the same GM button press in both missions).

Oh and to summarize the development we did for features not in 2.5.101:
1) Shuttle: used a Scout with special code in the mission script.
2) Video: my Artemis Bridge Tools already had a video player that was triggerable by a mission script.   I used a variant of that code which did not require the full Artemis Bridge Tools to be installed, just a small standalone EXE that could be run alongside Artemis.  It connected as another main screen client of a particular ship, watched for a particular condition to occur, and played the video.   It worked great.
3) Special comms buttons: had to use keypresses.  But I put buttons on the GM screen to do the same thing, so as to not have a hard dependency on keypresses working.  And I did need to use them in one of the two runs when another bridge setup was trying to use the keypress.   They hit the key, nothing happened, so I hit the button on the GM console, and they figured the keypress must have worked [smile]

Thanks again for all the help in this thread, I think the Norwescon players really appreciated it.
ryleyra

Registered:
Posts: 2,459
Reply with quote  #24 
Glad it all worked out!

Quote:
Originally Posted by Dave Thaler

Workaround was to add a button on the Game Master console to cause any critical Comms message to be resent.   I did notice that the GM console has to be selected when the mission begins though or buttons won't appear.   That is, joining late as GM means you won't get the buttons.  Seems like a bug.


Yep, that's a known bug. The Comms console has a similar issue; if you log out or switch to the Options screen to add an additional console, Comms loses its record of all past message. So if Comms isn't logged in when the game begins, any initial messages sent to "set the stage" are lost. Delaying the initial events is probably a good idea.

A commonly agreed upon workaround for the GM console is to assign a timer task to refresh the menu and GM buttons at regular intervals. Probably a more efficient solution is to have a "reset" button refresh the menu, and have the timer task constantly remove and add just that one button. A third solution would be to program a keybind to refresh the menu.

I'll note that in 2.6 this will probably be the case for the scripted Comms buttons as well. The same solution should work with it.
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 1,716
Reply with quote  #25 
Quote:
Originally Posted by ryleyra

A commonly agreed upon workaround for the GM console is to assign a timer task to refresh the menu and GM buttons at regular intervals. Probably a more efficient solution is to have a "reset" button refresh the menu, and have the timer task constantly remove and add just that one button. A third solution would be to program a keybind to refresh the menu.

I'll note that in 2.6 this will probably be the case for the scripted Comms buttons as well. The same solution should work with it.


Ryleyra is correct. In the upcoming Artemis 2.6 the scripted Comms buttons are lost if Comms crashes and restarts or even returns to the Console Choice Screen without restarting. The workaround is to have binary variables indicating which Comms buttons should be visible at any given time, then periodically clearing and respawning the buttons.

It should work to offer the GM a "reset all GM buttons" key. You might try the same thing for the new Comms buttons but if you get_keypresses from Comms it will be less reliable. Furthermore, I stress that in either case you must clear the buttons before you respawn them.

  • Imagine the server has spawned GM button X-RAY. The server cannot deal with two buttons called X-RAY so it remembers a button named X-RAY already exists to prevent double-spawning.
  • Further imagine the GM console has crashed and rebooted. The GM console has lost all GM buttons including X-RAY.
  • Now imagine your script attempts to respawn X-RAY every 15 seconds. The server will refuse the command. No button will spawn on the GM console because the server thinks X-RAY is already there and it cannot be tricked into double-spawning.
  • The solution is that every 15 seconds you need to clear X-RAY and immediately respawn X-RAY. This can be in the same code block, but the clear command must precede the respawn command.

__________________
"The Admiralty had demanded six ships; the economists offered four; and we finally compromised on eight."
- Winston Churchill
ryleyra

Registered:
Posts: 2,459
Reply with quote  #26 
There are two buttons on the GM screen that are always defined, the Instructions button and the Send Comms button. It would be nice it we could tell if the Instructions button was clicked on, but all it does is pop up text, and IIRC it's subject to the same condition, so if Comms has disconnected it will show nothing. The Instructions button could tell the GM about the key to press, and be refreshed on a timer.

If we had an event that was triggered when the Instructions button is clicked on, that could be a workaround. The script could set the Instructions text and rebuild the menu. Or, there could be a button on that screen to "Reset Menu". It wouldn't help Comms, although the GM, if there is a GM, could reset the Comms buttons as well.

If there was a way to test if a given button doesn't exist, that could be a workaround as well. The real solution would be for the server to retain the button layout and initialize the GM and Comms console when they connect, but one of the above may be easier to implement. I don't like the idea of creating a button just for this purpose, but if it could be put somewhere out of the way it would be better.
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.