Xeno Companion Crate

[fenndragon]

Description

Added a Xeno companion crate with an accompanying event as well as properly tweaked and readded specific non anomalous ventcritters events with major tweaks to their behavior and settings.

---

Changelog

🆑

• add: Added Xeno companion crate and accompanying event
• fix: Fixed Specific ventcritters events and re-enabled them

[Memeji]

I worked with Fenn on this a lot.
From our testing it seemed good, content-wise.

Balancing is all that may be needed, but we'll see about that after it is implemented.
Others will give their approval and request changes if needed.

[fenndragon]

commented out the ventcritters events until whatever is going wrong with the events can be fixed (the event manager firing events repeatedly for some reason/spamming events) as discussed with Fansana

[Fansana]

Merge this during the weekend so we got time to fix bugs that may arise.

[FoxxoTrystan]

Please use the "Floof" folder direction, or this is going to be a conflict merge nightmare.

[fenndragon]

Please use the "Floof" folder direction, or this is going to be a conflict merge nightmare.

I was told not to do this on things that will likely end up going upstream, as some of the EE people have showed interest in my other work like this with the events and such this was going to probably end up the same way, which would mean pulling it back out of floof

[Mnemotechnician]

Please, avoid simply copy-pasting prototypes if you are only going to change a few components in them; use inheritance instead.

[fenndragon]

Please, avoid simply copy-pasting prototypes if you are only going to change a few components in them; use inheritance instead.

I carefully considered what to parent and what not. In this instance the differences between the things resulted in parenting being less useful.

I parent the neutral versions from the base version. With changes applied where acceptable, then the specific versions from those.

To change the way this gets parented would result in more code not less. As I would need to respecify all changes listed in each specific xeno base already.

[FoxxoTrystan]

Please use the "Floof" folder direction, or this is going to be a conflict merge nightmare.

I was told not to do this on things that will likely end up going upstream, as some of the EE people have showed interest in my other work like this with the events and such this was going to probably end up the same way, which would mean pulling it back out of floof

Please still do this until its is on EE.
We will handle the conflict merge issues when EE has it and we do an upstream merge but for the moment this is requried here if not on upstream already.

[fenndragon]

Please use the "Floof" folder direction, or this is going to be a conflict merge nightmare.

I was told not to do this on things that will likely end up going upstream, as some of the EE people have showed interest in my other work like this with the events and such this was going to probably end up the same way, which would mean pulling it back out of floof

Please still do this until its is on EE. We will handle the conflict merge issues when EE has it and we do an upstream merge but for the moment this is requried here if not on upstream already.

unhappy about the extra work, but done.

[Mnemotechnician]

I carefully considered what to parent and what not. In this instance the differences between the things resulted in parenting being less useful.

I parent the neutral versions from the base version. With changes applied where acceptable, then the specific versions from those.

To change the way this gets parented would result in more code not less. As I would need to respecify all changes listed in each specific xeno base already.

I really don't see how

- type: entity
  name: Friendly NT Ravager
  id: MobXenoNeutralRavager
  parent: MobXenoRavagerNPC
  description: A friendly ravager programmed by centcomm
  components:
  - type: NpcFactionMember
    factions:
    - PetsNT
  - type: LayingDown
  - type: Sprite
    drawdepth: Mobs
    sprite: Mobs/Aliens/FXS/ravager.rsi
    scale: 0.7, 0.7
  - type: PointLight
    radius: 2
    energy: 1
    color: "#E3954D"
  - type: GhostRole
    name: ghost-role-information-friendlyxeno-name
    description: ghost-role-information-friendlyxeno-description
    rules: ghost-role-information-friendlyxeno-rules
  - type: GhostTakeoverAvailable
  - type: LanguageKnowledge
    speaks:
    - Xeno
    understands:
    - Xeno
    - TauCetiBasic

Repeated 4-5 times is any shorter than

- type: entity
  id: MobXenoNeutralBase
  abstract: true
  components:
  - type: NpcFactionMember
    factions:
    - PetsNT
  - type: LayingDown
  - type: Sprite
    drawdepth: Mobs
    scale: 0.7, 0.7
  - type: PointLight
    radius: 2
    energy: 1
  - type: GhostTakeoverAvailable
  - type: LanguageKnowledge
    speaks:
    - Xeno
    understands:
    - Xeno
    - TauCetiBasic

Followed by this, repeated 4-5 times

- type: entity
  name: Friendly NT Ravager
  id: MobXenoNeutralRavager
  parent: [MobXenoNeutralBase, MobXenoRavagerNPC]
  description: A friendly ravager programmed by centcomm
  components:
  - type: Sprite
    sprite: Mobs/Aliens/FXS/ravager.rsi
  - type: PointLight
    color: "#E3954D"

[fenndragon]

I carefully considered what to parent and what not. In this instance the differences between the things resulted in parenting being less useful.
I parent the neutral versions from the base version. With changes applied where acceptable, then the specific versions from those.
To change the way this gets parented would result in more code not less. As I would need to respecify all changes listed in each specific xeno base already.

I really don't see how

- type: entity
  name: Friendly NT Ravager
  id: MobXenoNeutralRavager
  parent: MobXenoRavagerNPC
  description: A friendly ravager programmed by centcomm
  components:
  - type: NpcFactionMember
    factions:
    - PetsNT
  - type: LayingDown
  - type: Sprite
    drawdepth: Mobs
    sprite: Mobs/Aliens/FXS/ravager.rsi
    scale: 0.7, 0.7
  - type: PointLight
    radius: 2
    energy: 1
    color: "#E3954D"
  - type: GhostRole
    name: ghost-role-information-friendlyxeno-name
    description: ghost-role-information-friendlyxeno-description
    rules: ghost-role-information-friendlyxeno-rules
  - type: GhostTakeoverAvailable
  - type: LanguageKnowledge
    speaks:
    - Xeno
    understands:
    - Xeno
    - TauCetiBasic

Repeated 4-5 times is any shorter than

- type: entity
  id: MobXenoNeutralBase
  abstract: true
  components:
  - type: NpcFactionMember
    factions:
    - PetsNT
  - type: LayingDown
  - type: Sprite
    drawdepth: Mobs
    scale: 0.7, 0.7
  - type: PointLight
    radius: 2
    energy: 1
  - type: GhostTakeoverAvailable
  - type: LanguageKnowledge
    speaks:
    - Xeno
    understands:
    - Xeno
    - TauCetiBasic

Followed by this, repeated 4-5 times

- type: entity
  name: Friendly NT Ravager
  id: MobXenoNeutralRavager
  parent: [MobXenoNeutralBase, MobXenoRavagerNPC]
  description: A friendly ravager programmed by centcomm
  components:
  - type: Sprite
    sprite: Mobs/Aliens/FXS/ravager.rsi
  - type: PointLight
    color: "#E3954D"

(Parent:MobxenoravagerNPC) On that particular instance. Comparing size of the different parents that to the size of what I have as I would need to put everything from the parent at the end. I will gladly make an estimate of the file size in question though if it satisfies you.

[fenndragon]

The file size of Xenopet in the example is merely the code of the file the other is attempting to replicate.

I rest my case.

[Mnemotechnician]

It's about verbosity, readability and maintainability, not file size. If you are going to upstream this, you need to adhere to the (relatively low compared to most other projects) code quality standards we have in place. If you want to leave this as a floof-only thing, then it's fine, code quality hardly matters.

[fenndragon]

It's about verbosity, readability and maintainability, not file size. If you are going to upstream this, you need to adhere to the (relatively low compared to most other projects) code quality standards we have in place. If you want to leave this as a floof-only thing, then it's fine, code quality hardly matters.

code is verbose and readable. each creature references its base creature as a parent and doesn't repeat any of the necessary code. the recolor/sprite changed critters are parented to their original base friendly version, I fail to understand how any of this is done incorrectly as every part of the code is necessary in my opinion.

if you wish to have this recoded in a different manner, feel free to make the changes you wish to see and comment them, I'll gladly accept the changes if they are functional.

[Mnemotechnician]

I already suggested what could be done, see above in the <details> blocks. If you want some statistics, each prototype could be 64% shorter in terms of linecount and 71% shorter in terms of the number of component redefinitions.

If you do not understand HOW or WHY it should done, I suggest asking in discord so we can discuss this in a live manner.