- Joined
- Aug 21, 2015
- Messages
- 585
- Reaction score
- 327
Ok, so I still completing a wrapper that I've been writing for quite some time. I call it "Wrapper 2.0". It has quests, events, and a plethora of unique commands only available on LvD. I would like to release a ton of new features when systems 2.0 is released, such as automated events where players engage in team vs team battles, or unique spontaneous happenings occur throughout the galaxy, such as distress calls being sent to players.. Another example might be a quest where the player must gather a specific custom block from storages throughout a base and then the wrapper detects when they place the items into a storage..
But I am finding that I am quite limited right now in what the wrapper can and cannot see. And some console output messages are sooo.. very... close to being incredibly useful! So, this suggestion is to change these log entries so that they contain the information they need. This is by no means a complete list, but here are some of the outputs I could reaally, really use:
Activation Gates:
Right now this is what it shows.
There is some lacking information here, but which would be very handy to have wrappers detect that the player activates a gate and then this triggers other events to occur. Such as simulated conversation as they pass through different areas of a base. Or maybe welcome messages as they move through the start area of spawn.. Or traps spring when they go the wrong way through a quest as an astronaut.
Information needed:
- The name of the player and/or entity that triggered the activation gate.
- The UID of the ship (if what is already provided is the ship name and not UID - I did not test for this yet)
- The local coordinates of the activation gate computer that was activated (not spacial coordinates, but the coordinates relative to the core/center of the ship or base)
Other information preferred:
- The sector coordinates the activation gate was triggered in.
- The spacial coordinates the player was at when activating the gate (very optional).
What we Don't need:
- There does not need to be 2 messages. This complicates scripting that then has to detect duplicates and only act on one set, which is especially problematic if events are being processed asynchronously.
Storages:
Right now the game shows some very useful information, BUT the information that is needed to use the data is not there, and so it cannot be utilized. Here's what it shows:
Unfortunately, I cannot use the current data due to there being no identifying information about who accessed the storage and what storage it was. But if I could use this data, then it will really open the doors for a lot of quest management. For example, let's say a player takes an item from a secret storage and they are congratulated on finding a secret. Or they open a storage that is "booby trapped" and suddenly pirate NPC's are warped around them. Or maybe a player must gather a certain amount of a custom items for the quest and once enough of the item has been deposited to a storage, the player is able to finish the quest and receive a reward.
Other information needed:
- The name of the player placing or removing items into the storage.
- The UID of the entity the storage is on.
- The local coordinates of the storage.
- The two messages need to be combined into one message so that a wrapper can connect all the data together. Two separate messages creates a lot of complications when processing the data, especially asynchronously.
Other information preferred:
- The sector the storage was in when accessed.
- The name of the entity the storage is on.
Player Inventory Changes:
Presently the wrapper shows the following when..
Dropping an item into space:
Picking an item up from space:
This information is insufficient. When dropping the item, the information needs to be on the same line, so that the wrapper can connect the player with the items dropped. And when picking up items, it lacks any sort of identifying information.
Other information needed:
- The name of the player picking up an item.
- The information when a player drops the item needs to all be on 1 line, not separated.
Other information preferred:
- The name and UID of the entity a player is in when picking up or dropping the item.
Deaths:
Right now death messages contain almost all of the necessary information, but there is one key piece of information missing. The UID of the entity that killed a player is not included. Instead the NAME of a ship is included. This information is useful, but it's not enough, because sometimes multiple ships will have the same name. For example, if I do a sector import to a few places, each ship imported will have the same name. I must be able to have the wrapper differentiate based on UID, not name. Also, there is more information that would be rather useful to have, such as where the player died.
Other information needed:
- The UID of the ship that killed a player
- The sector the player was in when they died
- The spacial coordinates for the player when they died
Other information preferred:
- The faction the ship that caused the death.
- The <owner> of the ship that caused the death.
- The fleet name the attacking ship was in (and the faction number that fleet is a part of)
- The sector the ship was in when it killed the player
Ship Overheats:
I spoke with Lancake already and the dev build actually already has had some information added, and this is wonderful! I am going to be able to do a lot with this information. However, there are a few more pieces of information that would be very useful. Last I checked the dev build provides information such as the following:
This is great, BUT the UID of the entity that caused the ship is missing. If a ship causes another ship to overheat, then the "by" part says "null". For example:
Not having the UID of the attacking ship is a big handicap. For example, when having automated dueling events, such as tournaments or team vs team combat where fleets are non-piloted ships are used, the scripting needs to know which entity caused the overheat. Was it a pirate? A ship owned by a certain faction or player? Another example would be involving the distress calls I plan on implementing, where one possible outcome is where the pirates killed the ship in distress. Some simulated dialogue could trigger. The pirates laugh at the player's feeble attempt to save the civilians and then more pirates spawn to try and kill the player.
Other information needed:
- The UID of the entity that caused the entity to overheat
Other information preferred:
- The weapon system that caused the overheat (as is given for player deaths)
- The faction the ship is in that caused the overheat.
- The <owner> of the ship that caused the overheat.
- The fleet name the attacking ship was in.
- The name of the entity that caused the overheat (not UID, but name)
Activation Blocks:
Now, there are some other bits of information I would *like* to have, but I understand that they would be a bit more difficult to implement, such as an activation block turning on and off. Activation blocks are a difficult question because I have seen some crazy logic contraptions before that might be triggering activation blocks to turn on and off thousands of times per second across multiple entities in the sectors and we don't necessarily want that kind of information spamming the console for every entity in any loaded sector. This would not be feasible to try and parse with a wrapper. So this brings me to my next idea:
- Allow activation blocks to have another attribute that makes them trigger logging. For example, an activation block could be toggled by an admin using a special key combination so that it now provides console output when it is turned on or off. If the activation block is picked up and then placed back down, it will no longer trigger the logging events.
Console/Log Information Needed:
- The UID and/or player that caused the activation block to turn on or off
- Whether the block was turned on or off
- The location of the activation block that as turned on or off.
- The UID and type of entity the activation block was on
- The local coordinates of the activation block (in relation to the ship core or start block)
Other information preferred:
- The logic block that caused the activation block to turn on or off and it's location.
Well, I think that's enough for now. These changes would really help me quite a bit so that I can create a lot more interesting quests, pvp events, and other random occurrences throughout our galaxy using wrapper-backed solutions.
But I am finding that I am quite limited right now in what the wrapper can and cannot see. And some console output messages are sooo.. very... close to being incredibly useful! So, this suggestion is to change these log entries so that they contain the information they need. This is by no means a complete list, but here are some of the outputs I could reaally, really use:
Activation Gates:
Right now this is what it shows.
Code:
[2017-12-04 13:20:57] [ACTIVATIONGATE] ACTIVATING PCGhostObjExt(9287->Attached(Ship[Benevolent27_1512410249676](11420)))@226738218
[2017-12-04 13:20:57] [ACTIVATIONGATE] Server(0) activating object: PCGhostObjExt(9287->Attached(Ship[Benevolent27_1512410249676](11420)))@226738218Information needed:
- The name of the player and/or entity that triggered the activation gate.
- The UID of the ship (if what is already provided is the ship name and not UID - I did not test for this yet)
- The local coordinates of the activation gate computer that was activated (not spacial coordinates, but the coordinates relative to the core/center of the ship or base)
Other information preferred:
- The sector coordinates the activation gate was triggered in.
- The spacial coordinates the player was at when activating the gate (very optional).
What we Don't need:
- There does not need to be 2 messages. This complicates scripting that then has to detect duplicates and only act on one set, which is especially problematic if events are being processed asynchronously.
Storages:
Right now the game shows some very useful information, BUT the information that is needed to use the data is not there, and so it cannot be utilized. Here's what it shows:
Code:
[2017-12-04 12:20:41] [INVENTORY] DO Executing action: Other Inventory is ok 14.850000590085983 / 5000.0; SlotA: 0.0; SlotB: 0.15000000596046448
[2017-12-04 12:20:41] [INVENTORY] PUT NOW ORIGINAL: [slot 7; t White Standard Armor(81); c 1; mt -1] ON 7Other information needed:
- The name of the player placing or removing items into the storage.
- The UID of the entity the storage is on.
- The local coordinates of the storage.
- The two messages need to be combined into one message so that a wrapper can connect all the data together. Two separate messages creates a lot of complications when processing the data, especially asynchronously.
Other information preferred:
- The sector the storage was in when accessed.
- The name of the entity the storage is on.
Player Inventory Changes:
Presently the wrapper shows the following when..
Dropping an item into space:
Code:
[2017-12-04 14:49:30] [SERVER][PLAYER] DROPPING NORMAL SLOT White Standard Armor(81): 1
[2017-12-04 14:49:30] [SERVER][PLAYER] PlS[Benevolent27 [Benevolent27]*; id(9117)(16)f(10001)] dropping item from PlayerCharacter[(ENTITY_PLAYERCHARACTER_Benevolent27)(9287)]
Code:
[2017-12-04 14:49:33] [SERVER][PLAYERSTATE] Picked up: Type 81; Count 1; Meta -1Other information needed:
- The name of the player picking up an item.
- The information when a player drops the item needs to all be on 1 line, not separated.
Other information preferred:
- The name and UID of the entity a player is in when picking up or dropping the item.
Deaths:
Right now death messages contain almost all of the necessary information, but there is one key piece of information missing. The UID of the entity that killed a player is not included. Instead the NAME of a ship is included. This information is useful, but it's not enough, because sometimes multiple ships will have the same name. For example, if I do a sector import to a few places, each ship imported will have the same name. I must be able to have the wrapper differentiate based on UID, not name. Also, there is more information that would be rather useful to have, such as where the player died.
Other information needed:
- The UID of the ship that killed a player
- The sector the player was in when they died
- The spacial coordinates for the player when they died
Other information preferred:
- The faction the ship that caused the death.
- The <owner> of the ship that caused the death.
- The fleet name the attacking ship was in (and the faction number that fleet is a part of)
- The sector the ship was in when it killed the player
Ship Overheats:
I spoke with Lancake already and the dev build actually already has had some information added, and this is wonderful! I am going to be able to do a lot with this information. However, there are a few more pieces of information that would be very useful. Last I checked the dev build provides information such as the following:
Code:
[SERVER] MAIN CORE STARTED DESTRUCTION [ENTITY_SHIP_deathShipTest] (999, 1000,1000) in 60 seconds - started 1512030891667 caused by benevolent27
Code:
[SERVER] MAIN CORE STARTED DESTRUCTION [ENTITY_SHIP_deathShipTest] (999, 1000,1000) in 60 seconds - started 1512030891667 caused by nullOther information needed:
- The UID of the entity that caused the entity to overheat
Other information preferred:
- The weapon system that caused the overheat (as is given for player deaths)
- The faction the ship is in that caused the overheat.
- The <owner> of the ship that caused the overheat.
- The fleet name the attacking ship was in.
- The name of the entity that caused the overheat (not UID, but name)
Activation Blocks:
Now, there are some other bits of information I would *like* to have, but I understand that they would be a bit more difficult to implement, such as an activation block turning on and off. Activation blocks are a difficult question because I have seen some crazy logic contraptions before that might be triggering activation blocks to turn on and off thousands of times per second across multiple entities in the sectors and we don't necessarily want that kind of information spamming the console for every entity in any loaded sector. This would not be feasible to try and parse with a wrapper. So this brings me to my next idea:
- Allow activation blocks to have another attribute that makes them trigger logging. For example, an activation block could be toggled by an admin using a special key combination so that it now provides console output when it is turned on or off. If the activation block is picked up and then placed back down, it will no longer trigger the logging events.
Console/Log Information Needed:
- The UID and/or player that caused the activation block to turn on or off
- Whether the block was turned on or off
- The location of the activation block that as turned on or off.
- The UID and type of entity the activation block was on
- The local coordinates of the activation block (in relation to the ship core or start block)
Other information preferred:
- The logic block that caused the activation block to turn on or off and it's location.
Well, I think that's enough for now. These changes would really help me quite a bit so that I can create a lot more interesting quests, pvp events, and other random occurrences throughout our galaxy using wrapper-backed solutions.
Last edited:
