Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment   Page 2 of 6      Prev   1   2   3   4   5   Next   »
Nhaima

Registered:
Posts: 21
Reply with quote  #16 
BUG
Engineering presets 8-0 are unavailable when using a 800x600 sized console.
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 2,401
Reply with quote  #17 
Quote:
Originally Posted by ryleyra
Yeah, I anticipated this issue, since in programming a floating point value is almost never tested for equality. You always use < and > with some small factor. Thom could add code that would automatically use the range test instead of exact equality for his EQUALS operator, but then it would do that even with integer variables.

It's not really an issue for which there is an easy solution. The best way is to set it up so you only have to test for < or >.


I ran into this in the canonical script "A Race for Distant Dawn" in which the ships must be turned to face a certain series of angles in radians. It's impossible to achieve all of the values exactly to infinite precision, so instead the script checks for to see if the angle is > < between two values. This works well.

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

Registered:
Posts: 2,985
Reply with quote  #18 
I just got around to testing the Comms buttons. They are a neat shade of orange. I've got an issue, though, not really a bug, but not quite right:

ISSUE
Comms buttons added via script command are all labelled with the number "0", and none of them respond to the "0" key.

This means the Comms buttons can't be accessed through the keyboard interface. They could be used in conjunction with a keypress, but there is no way (besides putting it in the button name) to associate the button with the keypress.

And another:

ISSUE
GM Console has no means to set message category for messages sent to Comms. It will appear as uncategorized. (Grey)
LawsonThompson

Registered:
Posts: 623
Reply with quote  #19 
A few days ago, I tested v2.6 by leaving the server and every other bridge position connected over 12 hours in the "AI" mode, with no crashes or problems. It seems that launching fighters kills it.

I think I have a repeatable crash bug, though it's not a particularly popular situation.

ISSUE: Server crash with one client connected as Fighter.

SETUP:
  • Launch server with Siege, level 4, no environment settings (all None).
  • Set main ship as Dreadnaught with 2 fighters, no shuttle.
  • Connect client, selecting only Fighter.
  • Launch mission.
  • Press E on server to enable the AI mode. Maybe this feature is what's killing it?
  • When the ship approaches an enemy, launch the fighter and pilot it.
Server crashes with "Artemis.exe has stopped working" but no other error message.


Note: this is under Windows 10 64-bit v1607, tested on 2 different server PCs and three different clients. 

Is there any proper way for me to collect further crash log information?

__________________
----
Visit us at http://www.ltebridge.com
ryleyra

Registered:
Posts: 2,985
Reply with quote  #20 

I didn't even know "E" was still working. I'll bet it is the fighter AI that is crashing the system. It's only recently that it became possible for allied NPC ships to launch fighters.

Mike's "Attract Mode" was intended to replace the AI mode.

LawsonThompson

Registered:
Posts: 623
Reply with quote  #21 
Quote:
Originally Posted by LawsonThompson


ISSUE: Server crash with one client connected as Fighter.


I have seen this happen pretty quickly: if you don't have Helm and Weapons connected and only connect fighters, the server will die in short order, even if you don't activate the AI mode.

Not that you'd ever play with this configuration of course! But donning my security hat, "A crash is the first step in an exploit. Control a crash, pwn the system."

The server and fighter were running Windows 10, for what it's worth.

__________________
----
Visit us at http://www.ltebridge.com
k9lego

Registered:
Posts: 88
Reply with quote  #22 
Quote:
Originally Posted by ryleyra
ISSUE
GM Console has no means to set message category for messages sent to Comms. It will appear as uncategorized. (Grey)

Was this problem ever solved? Things got interesting on my last GMed mission. [frown]
eaglestallon

Registered:
Posts: 1
Reply with quote  #23 

Issue/Bug: Upon freshly downloading the program through steam and launching it I get this:

  Capture.JPG 

Solution:
After talking to some players in a discord channel, they eventually figured out that my multi display was causing the issue.
Capture3.JPG 
I have to go to "Show only on 1" to get the full launcher, after the launcher is up and running I can switch back to the "Extend these displays" to go back to my normal setup.

My graphics card is an AMD Radeon HD 5450 with drivers that are currently updated.

People that helped: 
Nhaima from the USN discord group. Thanks for taking the time to help me troubleshoot!


ryleyra

Registered:
Posts: 2,985
Reply with quote  #24 
Quote:
Originally Posted by eaglestallon

Issue/Bug: Upon freshly downloading the program through steam and launching it I get this:

  Capture.JPG 



This bug has been discussed extensively in this thread: https://artemis.forumchitchat.com/post/tiny-start-screen-6557341?trail=15

The conclusion is that changing your display resolution will solve the problem. Just change resolution and change back and the window should be fixed. This may be caused by a problem with Windows 10, since it often appears when you upgrade.

It's still a bug, and if Thom can track down the cause of it and fix it that would be great.
ryleyra

Registered:
Posts: 2,985
Reply with quote  #25 
Bug:
The scan_desc attribute of set_ship_text is ignored. This appears to have been true since 2.3 at least.
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 2,401
Reply with quote  #26 
Quote:
Originally Posted by ryleyra
Bug: The scan_desc attribute of set_ship_text is ignored. This appears to have been true since 2.3 at least.


I think scan_desc does work for enemy ships, but not in real time. If Science scans an enemy ship and reads scan_desc, then the script changes it, the field does not change on Science screen. But if Science thereafter looks at another object then comes back to the enemy ship in question then Science can see the new scan_desc.

Friendly ships cannot be scanned. The only way for a script to give the players new information from them is through hail_text.

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

Registered:
Posts: 2,985
Reply with quote  #27 
Quote:
Originally Posted by Mike Substelny

I think scan_desc does work for enemy ships, but not in real time. If Science scans an enemy ship and reads scan_desc, then the script changes it, the field does not change on Science screen. But if Science thereafter looks at another object then comes back to the enemy ship in question then Science can see the new scan_desc.


I didn't notice this, but I didn't check enemy ships that thoroughly. The scan_desc was changed when the ship was created, though (actually a few seconds later) and I never saw the Intel change to the new information. I'll double check selecting something else and then coming back after a second scan.

Quote:
Friendly ships cannot be scanned. The only way for a script to give the players new information from them is through hail_text.


This is what I discovered in "Havok in the Hamak Sector". I ended up combining desc and scan_desc into desc in order to show the whole message. And added hail_text too. [biggrin] 

Quite frankly, I think even if it works on enemy ships I'm not going to mess with "Hamak Sector" any more. I think it's fine as is.

ryleyra

Registered:
Posts: 2,985
Reply with quote  #28 
I did some testing and my results were somewhat interesting. The scan_desc did not show up when I called set_ship_text without a few seconds of when the ship was created, but if I created it after another pause, it was set and showed up, whether I scanned the ship BEFORE the text was changed or after. It's also possible that the first call to set_ship_text didn't change scan_desc, but the second one did. I didn't do enough experimenting to find out.

The conclusion, I suppose, is that this isn't a bug, but you should make sure you set scan_desc as close to the time you want the modified Intel to appear as you can. And test it before assuming it worked.
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 2,401
Reply with quote  #29 
Quote:
Originally Posted by ryleyra
I did some testing and my results were somewhat interesting. The scan_desc did not show up when I called set_ship_text without a few seconds of when the ship was created, but if I created it after another pause, it was set and showed up, whether I scanned the ship BEFORE the text was changed or after. It's also possible that the first call to set_ship_text didn't change scan_desc, but the second one did. I didn't do enough experimenting to find out.

The conclusion, I suppose, is that this isn't a bug, but you should make sure you set scan_desc as close to the time you want the modified Intel to appear as you can. And test it before assuming it worked.


I actually believe that Thom does consider this to be a bug.

I discussed this with Thom last week while making final touches to my mission script for Phoenix Comicon. It turns out to be a communication issue between client and server. When a mission script sets all the fields in set_ship_text Thom meant to push them all from the server to the clients immediately. But in implementation he only pushed newname, race, class, and desc. He forgot to immediately push scan_desc and hailtext from server to client. Players don't notice the hailtext problem because the field gets pushed when Comms asks for it. But the scan_desc field is a problem. Even though the field's value has been changed, Science can't see the new value until the server sends it to the Science console. It might be possible for Science to force the server to push the data by scanning another ship then returning to the scan_desc ship. But that workflow is illogical for a Science Officer unless he/she knows the scan_desc field is due to change.

I haven't tested this, but in a multi-bridge mission it might be possible for different Science Officers looking at the same ship to see different values of scan_desc at the same time. This might depend on whether they have taken actions that would cause the server to send the updated value to their individual clients.

TL;DR: In Artemis 2.6 your script does change scan_desc immediately on the server, but the Science console doesn't see the change until some arbitrary time later. This is not what Thom intended and he will probably fix it in a future version.

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

Registered:
Posts: 2,985
Reply with quote  #30 
Quote:
Originally Posted by Mike Substelny

TL;DR: In Artemis 2.6 your script does change scan_desc immediately on the server, but the Science console doesn't see the change until some arbitrary time later. This is not what Thom intended and he will probably fix it in a future version.


That explains why my test results were inconsistent. At least we know it can work, there just needs to be some fudging, maybe a Comms message suggesting Science should switch targets. That's if you even want to use the scan_desc attribute at all.

The way I see it, straight info would be in desc. You would use scan_desc to replace the taunt immunity message, which you probably don't want to do in most cases.

Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.