Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment   Page 2 of 2      Prev   1   2
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 2,390
Reply with quote  #16 
Quote:
Originally Posted by LawsonThompson
BUG, low impact(?): Haven't fully tested, but after launching a normal scripted game, then pausing for a <unknown> length of time, then restarting the mission script:


LawsonThompson, what script was it?

Did you exit the script and restart, or did you un-pause the game?

Scripts have timers to trigger actions, and one of the "features" of Artemis is that pausing does not stop the timers. Thus if one or more timers reached zero while the game was paused it is possible that the mission ended or it became impossible to continue in some other way before you unpaused.

For instance, the Armada IV script has a bunch of timers. Most of them are used to regulate events in the "situations" but a few are part of setting up the start of the game. In that script if you paused while a situation was going it might have caused trouble.

This does not apply if you exited the script and restarted it. In that case you really have encountered some sort of Artemis bug.

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

Registered:
Posts: 622
Reply with quote  #17 
Quote:
Originally Posted by Mike Substelny


LawsonThompson, what script was it?

Did you exit the script and restart, or did you un-pause the game?

Scripts have timers to trigger actions, and one of the "features" of Artemis is that pausing does not stop the timers. Thus if one or more timers reached zero while the game was paused it is possible that the mission ended or it became impossible to continue in some other way before you unpaused.

For instance, the Armada IV script has a bunch of timers. Most of them are used to regulate events in the "situations" but a few are part of setting up the start of the game. In that script if you paused while a situation was going it might have caused trouble.

This does not apply if you exited the script and restarted it. In that case you really have encountered some sort of Artemis bug.


I started the Armada IV script, used GM to spawn a simple sector, but didn't start any of the situations, nor spawn enemy fleets.

I then paused the game for at least 10 and perhaps as long as 45 minutes while the training video ran on the server via a Windows shortcut (not scripted).

A few folks wandered in while the training video was looping, and I was able to demo some of the client UI bits while the mission was paused. We poked at buttons and such, and I noted the ship would not actually move nor weapons load because it was paused, as expected.

When the next crew arrived for their mission, as GM I picked a different sector of the map and started spawning enemies. Minutes into the mission, we noted the oddities: Helm and Weapons had the wrong ship type, Science won't lock, etc.

I assumed the script had gotten confused, so I "End Mission" in the script and restarted the script. The clients still were seeing the wrong data and misbehaving.

I exited the server to the desktop and relaunched, and had the clients disconnect and reconnect: and the problem still persisted.

After exiting the clients to the desktop and relaunching, they all reconnected and everything was fine.

It seems more of a client bug of some sort, not a server thing. Maybe clients paused for too long get into some sort of a "half-there" state?



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

Avatar / Picture

Administrator
Registered:
Posts: 2,390
Reply with quote  #18 
Quote:
Originally Posted by LawsonThompson

It seems more of a client bug of some sort, not a server thing. Maybe clients paused for too long get into some sort of a "half-there" state?



Oh, that IS interesting! While the server is paused there is nothing in the script that would interact with the clients. The clients don't even know that a script is running, in fact with the Armada IV script the clients don't even need a copy of the script. I suppose it's possible that someone could have done something strange during the pause, such as two players on the Helm and Server both trying to change the player vessel class and creating a conflict. That might have screwy effects (I should test it!).

But the script itself has no code to change player vessel class, no matter what the states of all the variables and timers.

Something in this is unexplored territory.

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

Registered:
Posts: 142
Reply with quote  #19 
Quote:
Originally Posted by LawsonThompson

When the next crew arrived for their mission, as GM I picked a different sector of the map and started spawning enemies. Minutes into the mission, we noted the oddities: Helm and Weapons had the wrong ship type, Science won't lock, etc.


I have noticed similar behavior sometimes when I test my scripts. So I'd see this on a server and client running on the same PC/laptop. It doesn't happen often, but when it does, it's usually because the script or a player has chosen a hull type that isn't a light cruiser, and the clients for some reason really want the ship to be a light cruiser. It hasn't happened often enough for me to figure out what's going on.

Best fix is to close the server and all clients, start them all fresh.




 
CodiX

Registered:
Posts: 9
Reply with quote  #20 

New Ximni hotkeys (quick jump forward & backwards) are reversed. Player from my group modified controls.ini like that:


BUTTON_QUICK_JUMP_FORWARD = UI_INPUT_UP
BUTTON_QUICK_JUMP_BACKWARD = UI_INPUT_DOWN

but in game pressing up arrow button results in jumping backwards, and down arrow button sends ship forward.

Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 2,390
Reply with quote  #21 
Quote:
Originally Posted by CodiX

New Ximni hotkeys (quick jump forward & backwards) are reversed. Player from my group modified controls.ini like that:


BUTTON_QUICK_JUMP_FORWARD = UI_INPUT_UP
BUTTON_QUICK_JUMP_BACKWARD = UI_INPUT_DOWN

but in game pressing up arrow button results in jumping backwards, and down arrow button sends ship forward.



That's a good catch, human! Apparently some native Ximni control arrangements don't make sense to human brains, so you must edit your controls.ini file. [cool]

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

Registered:
Posts: 488
Reply with quote  #22 
DOC BUG: mission-file-docs.txt still contains no mention of set_player_carried_type or clear_player_station_carried
Dave Thaler

Registered:
Posts: 488
Reply with quote  #23 
BUG: GM console does not show all player ships in a PvP game with limited sensor range, it only shows the ships on one side (based on the ship chosen from the console screen) and enemy ships that are within sensor range.   The same applies to a scripted mission if the player ships are not on the same side.  I would expect the GM screen to always show all ships regardless of sensor range.
Dave Thaler

Registered:
Posts: 488
Reply with quote  #24 
BUG (previously reported by Dart_Tech here, still present in 2.7.5): The triggersMines property does not work.  The value can be set on a shielded ship (and get_object_property works with it) but it has no effect, the ship will always trigger mines.
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.