Register Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
ryleyra

Registered:
Posts: 2,419
Reply with quote  #1 
Given all the changes to scripting in Artemis 2.6, I thought I would make a list of useful notes I have found while working on the stock scripts. These are all important "gotchas" that should be remembered by script writers.

1) The new "integer" variables can only be set in the start block. If they are set in other event blocks, it is very likely the variable will be allocated, as a floating point variable, when it is referenced with "if_variable". For this reason, you should initialize any flag variables to 0 in the start block. (Flag variables are when you check if a variable is 1 before an event, and then set it to 1 after the event, to trigger it only once)

2) Related to the above, flag variables can be floating point, but it's a waste to implement in that form, and you run the risk of rounding errors if you use fractional values in your flag.

3) Similarly related, floating point values compared using "EQUALS" may return the wrong result. It is better to check "LESS_THAN" and "GREATER_THAN" using a small value like 0.1 to make sure the value is in the range you want.

4) This is actually an old change from Artemis 2.4, but always clear ally AI stacks and rebuild them from scratch. You can add the AI command "FOLLOW_COMMS_ORDERS" if you want, but allies are created with the enemy brain stack now, which means they'll try to attack enemy ships, even if they don't have any beams.

5) You must remember to set a message type if you want your Comms messages to be filtered.
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 1,666
Reply with quote  #2 
6) Scripts can now access monster brain stacks. While this change also precedes 2.6 it was never properly documented until now.

7) Scripts can specify the names and loadout of fighters/bombers on a carrier, or the names of shuttles on other capital ships. This must be done before the capital ship is instantiated.

8) Scripts can specify the names and loadout of refit fighters at player bases. This may be done at any time.

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

Registered:
Posts: 2,419
Reply with quote  #3 
Here's another interesting thing I discovered while re-writing the stock missions. As of 2.6, the GM Menu is no longer wiped out when the GM logs in late, or disconnects from the server and reconnects. The non-menu buttons ARE lost, but apparently now the server retains a copy of the menu and sends it to the GM client when it connects.

This means it is possible to define a menu option that will rebuild the screen buttons, and you no longer have to work around it by either refreshing the buttons every few minutes, or defining a keybind to refresh it. I suspect the GM Instruction button also will work even if the GM is disconnected, although I will have to test that.

This feature clearly doesn't apply to the Comms buttons, though. I think I'd like to recommend Thom implement the Comms buttons like he did the GM menu, and not the GM buttons. Just give script writers the ability to define options in the form "New Menu/SubMenu1/SubMenu2" and have them work exactly the same way the current Comms menu works, with the defined number shortcuts and clearing the whole menu column.

I'm guessing this is not going to be easy, but if the code already exists it should be easier to adapt it than to write the whole thing from scratch.

ryleyra

Registered:
Posts: 2,419
Reply with quote  #4 
A correction to the above; the GM menu is NOT built if the GM is not logged in when the server starts. Or at least, any gm buttons created in the start block are not created. If the GM is logged in when a menu button is created, though, that button is apparently retained on the client and survives switching of consoles. (I did not confirm if it survives disconnect and reconnection ON THE SAME CLIENT. But it definitely does not survive termination and reconnect on a new client)

I also found that if the game crashes when you attempt to activate a GM button, the most likely cause is that you have an if_gm_button command defined wrong. In my case, I was using the "keyText" attribute from if_gm_key instead of "text". The fact that it crashed only when a GM button was clicked was a clue that it was the if_gm_button commands that were at fault.

If you define a set_gm_button command wrong, the game will NOT crash, but apparently the event will stop executing. In particular, I found that if you did not remove an existing button with clear_gm_button, you apparently cannot create it, or it will cause unexpected results. For instance, I found top menu options changing order, or on screen buttons not appearing.

If I tried to redefine the on screen buttons without clearing the menu, even if they were no longer present on the screen, it removed ALL the buttons, including the menu. I have no idea why this happens, although I suspect it's because the client had disconnected. (Maybe the menu was retained onscreen, but not "behind the scenes" as it were) The only way I was able to refresh the buttons when any of them were lost was to remove ALL of them, and then restore all of them.

In short, the best way to create a restore options to recover from disconnection and reconnect to the server is still to define a gm key. A menu option has a possibility of being lost, and trying to remove and add just that button is problematic. A restore option, whether a button or on a timer, should remove everything and start over.
ryleyra

Registered:
Posts: 2,419
Reply with quote  #5 
Also, the GM Instructions do not survive disconnect, or when the GM logs in late. It does survive if you change console selection.
Previous Topic | Next Topic
Print
Reply

Quick Navigation: