Register Calendar Latest Topics
 
 
 


Reply
  Author   Comment   Page 2 of 3      Prev   1   2   3   Next
zorilya

Registered:
Posts: 34
Reply with quote  #16 
The use_gm_selection parameter on if_docked will always trigger if nothing is selected.
Also the if_docked suffers from a lack of distinguising between multiplayer ships hence the player_slot parameter doesn't work on this one either

The if_player_is_targeting command suffers the same problem except the use_gm_selection will trigger regardless of selection as long as something is selected. Also If no one has connected to a ship console on the ship it will trigger too.
zorilya

Registered:
Posts: 34
Reply with quote  #17 
player_slot findings

The following commands appear to work as intended with respect to the implementation of the new player_slot parameter:

set_ship_text
set_side_value
if_inside_box
if_outside_box
if_inside_sphere defaults to first player without name or player slot
if_outside_sphere

The remaining do not work correctly... some more severely than others as detailed in my prior posts

set_relative_position
addto_object_property
set_object_property
if_object_property
copy_object_property
set_player_grid_damage
set_damcon_members
warning_popup_message
if_damcon_members
if_docked first player
if_player_is_targeting


This makes me sad.

Xavier Wise

Registered:
Posts: 974
Reply with quote  #18 
Quote:
The set_player_grid_damage and set_damcon_members reacts as before without making a distinction between player ships so that any input to it will be applied to the first ship in the simulation and hence does not support the player_slot parameter.


This works with use_gm_selection, which is a bonus. 

 

Quote:

The remaining do not work correctly... some more severely than others as detailed in my prior posts

set_relative_position
addto_object_property
set_object_property
if_object_property
copy_object_property
set_player_grid_damage
set_damcon_members
warning_popup_message
if_damcon_members 
if_docked first player
if_player_is_targeting

 

I totally agree that the player_slot should work with these. If it did, my whole TSN Sandbox could use custom names. As it stands, I haven't really bothered using the player_slot parameter much at all. It is a shame because I would really be useful for any mission script. At the moment, to make the TSN Sandbox work, we open the file in Notepad and use the "Find and Replace" function to change the names. This pretty much guarantees all names are changed, both in references in the xml codes as well as in Comms messages.

What would be cool would be the ability to draw the name from the script for comms messages. E.g. "TSN [player_slot_1_Name] this is Command. Return to base immediately."

__________________
Captain Xavier Wise TSN Raven (BC-014)
Link to TSN RP Community website
Link to TSN Sandbox
Link to Blog
ryleyra

Registered:
Posts: 2,380
Reply with quote  #19 

It's starting to look like the mission-file-docs.txt file may have been correct, and changes.txt is not. But I will go through and specify which do currently work and which don't.

I will note that one thing you can do is check for when a ship is added with "if_exists player_slot" and then immediately issue "set_ship_text player_slot name=<your name>". This will keep the players from having to type in the name defined for the script, you can just force the required name.

Unfortunately, the ship names have to be in the same slot order, or I could use that with Strike Force Seven.

I'll also note (since it hasn't been mentioned) that the workaround of not creating the first player ship does not need to be used any more. You can now create the first ship, and it can have either warp or jump drive, whichever the players select, if you don't specify it yourself.

Fish Evans

Registered:
Posts: 347
Reply with quote  #20 
Quote:
Originally Posted by Wausauspace
Fish, Huge thanks!
I know you've got 100 other things to do with your time!
This Mission Editor is a major component for Artemis developers.
Thank you for all of your work on this. It is appreciated and previous versions have been used heavily by myself and my students.

I'm thinking it might be a good idea to wait until your official release.
I opened this test beta copy and right away noticed the brand new "set_gm_button" X,Y, W, H attributes are removed on open.
So I tested a save and... sure enough they were stripped out.

If there is something I can do to assist, please let me know. Your work is important to all of us.


well

uh

err

It would help
..if I had uploaded the right version... that was a test build I had mid way though armada. [frown] oops. this one should work much better Width etc should work fine. Look for a more formal and tested build in a few days. I was holding off editign things as the origional creator showed up a month before armarda and said he would be more active.. but I havent seen him since so I might as well have a stab.

[comp]
  incidentally if any one would like the sauce code for the editor just PM me.



 
Attached Files
zip ArtemisMissionEditor.zip (830.21 KB, 10 views)

ryleyra

Registered:
Posts: 2,380
Reply with quote  #21 
I'm looking forward to seeing what you've done with the Editor. I've been able to use the old editor and edit the mission file with a text editor to fill in the blacks, but it would be nice to not have it remove all my fixes. [biggrin] I'll probably download it tonight to mess with it.
Fish Evans

Registered:
Posts: 347
Reply with quote  #22 
One thing that will help is to find what values each of these expect and there meanings... for example:

  nebulaIsOpaque Valid 1 or 0 (yes/no)
  sensorSetting Valid 0-4 0=Unlimited 1=33Km 2=16Km 3=11Km 4=8Km
  
the others I will need to work out are:
  gameTimeLimit
  networkTickSpeed
  nonPlayerSpeed
  nonPlayerShield
  nonPlayerWeapon
  playerWeapon
  playerShields
  coopAdjustmentValue
ryleyra

Registered:
Posts: 2,380
Reply with quote  #23 
Quote:
Originally Posted by Fish Evans
One thing that will help is to find what values each of these expect and there meanings... for example:


Already done it.

  nebulaIsOpaque Valid 1 or 0 (yes/no)
  sensorSetting Valid 0-4 0=Unlimited 1=33Km 2=16Km 3=11Km 4=8Km
  
Both of those are correct. 

  gameTimeLimit  - in seconds, but it does not work
  networkTickSpeed - 20-500, default 380
  nonPlayerSpeed - 40-300, default 100
  nonPlayerShield - same
  nonPlayerWeapon - same
  playerWeapon - same
  playerShields - same, and yes it ends with "s" and nonPlayerShield doesn't
  coopAdjustmentValue - 0-8, where 1-8 is the number of ships in Co-Op mode

As I posted in the bug thread, any configuration setting that is set in another mode is carried over to Script mode, and vice versa.

ryleyra

Registered:
Posts: 2,380
Reply with quote  #24 
Okay, I have edited the first post to add the corrections posted by zorilya. I was unable to reproduce the error reported with if_docked when using use_gm_selection. I found that the command returned true when the player ship that was docked was selected, and false when nothing was selected, or if a player ship was not selected.

One other odd thing I found is that you could provide a name="Artemis" to warning_popup_message and it would only appear to that ship in slot 0. However, trying name="Intrepid" did not work. Using player_slot or leaving the attribute blank resulted in the popup appearing to ALL ships. I did not test if the name attribute would work with with set_player_grid_damage or set_damcom_members, but those commands are supposed to only apply to the first ship anyway, if no argument is provided.
Fish Evans

Registered:
Posts: 347
Reply with quote  #25 
Quote:
Originally Posted by ryleyra

As I posted in the bug thread, any configuration setting that is set in another mode is carried over to Script mode, and vice versa.


I think I will add theses to the default Mission start block then.
ryleyra

Registered:
Posts: 2,380
Reply with quote  #26 
Yeah, that's pretty good advice. In my case, I want to make sure the player has not messed with the configuration. I need to use shield values as a comparison to tell the different ships apart. I already noticed that NPC shield values can vary, because ships can be overpowered and underpowered. If the configuration setting changes shields on top of that, it can make it impossible to predict.

OTOH, if you explicitly want the players to be able to configure the ships, you might leave it. But the options aren't available in the Configuration screen in Script mode. So they'd have to go to Solo mode or the like, set their Configuration, and then return to Script mode and start the game. I'm hoping a later version of Artemis just provides those options, so the script can just say if it's overridden them or not.
DizzyKungFu

Registered:
Posts: 24
Reply with quote  #27 
set_special ability="" seems to work as advertised [smile]

set_special clear="" seems to do nothing, however [frown]

Anyone have different results?
Fish Evans

Registered:
Posts: 347
Reply with quote  #28 
Quote:
Originally Posted by DizzyKungFu
set_special ability="" seems to work as advertised [smile]

set_special clear="" seems to do nothing, however [frown]

Anyone have different results?


try:

set_special clear="clear"

its what I have added to the editor, I dont think it has to be "clear" but just soemthing in the quotes
ryleyra

Registered:
Posts: 2,380
Reply with quote  #29 
I think you have to clear the specific special:

set_special clear="Warp"

I don't know if there is a "clear all". I suspect that if you don't specify a special, it won't clear anything.
DizzyKungFu

Registered:
Posts: 24
Reply with quote  #30 
Quote:
Originally Posted by Fish Evans


try:

set_special clear="clear"

its what I have added to the editor, I dont think it has to be "clear" but just soemthing in the quotes


I just meant any special can go in the quotes. "clear" would clear the clear special, which does not exist.

But actually, that begs the question; is there a command to wipe out all specials and start from scratch?
Previous Topic | Next Topic
Print
Reply

Quick Navigation: