Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 2,391
Reply with quote  #1 
On January 25 2020 we will be testing the beta of Artemis 2.7.5 at my place. See thread under Bridge Crew Comms for details if you would like to see it for yourself.

Features of Artemis 2.7.5 that we will be testing:

General:
  1. Artemis.exe should no longer crash when a tag hits an asteroid.
  2. Helm, Weapons, and Engineering client crashes should reliable release those consoles from the server.

Scripting:
  1. The "Player_slot" token should work for all script commands.
  2. The "Player_slot" token should not cause mysterious script crashes.
  3. The long awaited get_object_property function should be fully implemented, allowing object properties to be loaded directly into variables.

I can't read Thom's mind, but if the software proves to be stable I assume he will release Artemis 2.7.5 sometime soon. If it crashes and otherwise frustrates players then the release will probably be delayed.

I do not know of any other changes/fixes/improvements in Artemis 2.7.5 so don't bother asking about your pet peeves here. When it is released we will have a thread for bug reports and wish lists for Artemis 2.7.5.

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

Avatar / Picture

Registered:
Posts: 90
Reply with quote  #2 
Quote:
  1. Artemis.exe should no longer crash when a tag hits an asteroid.
  2. Helm, Weapons, and Engineering client crashes should reliable release those consoles from the server.

Woohoo!   [biggrin]
Looking forward to both of those, especially #2  [thumb]
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 2,391
Reply with quote  #3 
UPDATE: We tested Artemis 2.7.5 last night and it worked pretty well. Thom is still making some improvements, but his code lock date for Artemis Aramda V is February 15th. That means Artemis 2.7.5 should be released very soon after February 15th.

I intend to release new mission scripts that demonstrate the new scripting features on or about February 12th, so you will have a chance to see the proper syntax for everything.

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

Registered:
Posts: 1,092
Reply with quote  #4 
Looking forward to this, particularly full functionality for player_slot. Along with get_object_property, I will be able to potentially slim down much of the code in the sandbox and make it more efficient.

Roll on February!

__________________
Fleet Captain Xavier Wise - TSN Sabre
Link to TSN RP Community website
ryleyra

Registered:
Posts: 2,929
Reply with quote  #5 

Ditto on everything Xavier said.

Unfortunately, I'm not able to do any testing myself at this moment, as I have no computer. I will have to let you guys handle it and offer my moral support. 😃

 

Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 2,391
Reply with quote  #6 
Quote:
Originally Posted by Xavier Wise
Looking forward to this, particularly full functionality for player_slot. Along with get_object_property, I will be able to potentially slim down much of the code in the sandbox and make it more efficient.

Roll on February!


At the moment both of those features work, but get_object_property is a little different from what is described in the documentation. Here is an example:

<get_object_property name="Cosmic Storm" property="positionX" variable="Stormx"/>
<get_object_property name="Cosmic Storm" property="positionZ" variable="Stormz"/>

The documentation says that this sets Stormx, Stormz to the X,Z map coordinates of the object called Cosmic Storm, and it does. But it doesn't make copies of the values, I believe it sets pointers to the values. If Cosmic Storm is in motion then Stormx and Stormz are constantly changing. At first Darrin and I were confused by this - I thought we had made coding errors.

In hindsight this could be a really useful feature. If Cosmic Storm is destroyed then Stormx, Stormz could become an instant record of its last position. That's perfect if I want to spawn another object there (a mine . . . you know all us script writers want to spawn a mine in a spot where something was destroyed!)

But I have not tested that. If the destruction of object Cosmic Storm means Windows instantly reallocates its memory it's possible that Stormx, Stormz would then be pointed at gibberish. I need to check this with some testing. Maybe tonight.

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

Registered:
Posts: 1,092
Reply with quote  #7 
Something I wanted to do some time ago was have life pods spawn automatically when a player ship was destroyed. I have the code for shuttles to fly out an pick them up, but at the moment life pods are placed manually by the GM. With get_object_property, I'll be able to set this up in a much more efficient way. The way I tried before caused a real slowdown or was just unreliable. I have a few more ideas too that went on the back burner because the functions just weren't there.

Really looking forward to getting my hands on the next version and adding to the TSN Sandbox :)

__________________
Fleet Captain Xavier Wise - TSN Sabre
Link to TSN RP Community website
Darrin

Registered:
Posts: 143
Reply with quote  #8 
Quote:
Originally Posted by Mike Substelny


In hindsight this could be a really useful feature. If Cosmic Storm is destroyed then Stormx, Stormz could become an instant record of its last position. That's perfect if I want to spawn another object there (a mine . . . you know all us script writers want to spawn a mine in a spot where something was destroyed!)

But I have not tested that. If the destruction of object Cosmic Storm means Windows instantly reallocates its memory it's possible that Stormx, Stormz would then be pointed at gibberish. I need to check this with some testing. Maybe tonight.


Using get_object_property with positionX and positionZ doesn't work that way. When the object associated with positionX and positionZ gets destroyed, the float values are zeroed out, along with the variables that point to them. I'm not sure if the code does this as part of the destroy object cleanup or Windows was cleaning up unused memory.

There's a work-around, you can copy your position variables to another set of variables, and those *don't* change. You can if_object_exists and update those variables every tick or every second, and that will keep track of your object's position. If it gets destroyed, then you have a record of it's last position.

Thom said he fixed the "dynamic variable" problem, so I believe the work-around won't be needed once he releases 2.7.5 in a week. (The work-arounds will still work, so we don't necessarily have to fix them.)


Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.