[MOD] AutoCrew

The place to discuss scripting and game modifications for X Rebirth.

Moderators: Moderators for English X Forum, Scripting / Modding Moderators

pref
Posts: 5589
Joined: Sat, 10. Nov 12, 17:55
x4

[MOD] AutoCrew

Post by pref » Wed, 20. Jan 16, 01:53

AutoCrew

Assign high skilled crew for L/XL sized vessels and stations automatically.

* Shipyards now supply trained personnel for newly built vessels, but wont add them to squad.
* Your marine officer also got promoted, and now has to take care of employee selection and hiring process for all the ships you borrow.
* Small ships get a high skilled pilot as well
* Any station will get a manager & DO - if not present - when your architect finishes any build stage.

Happy smalltalking!

Workshop link
Dropbox

Thinking of charging some cash when assignments happen and cancel if there aren't enough funds. Not sure about it yet as it would most likely affect the first few acquisitions only.
Last edited by pref on Sun, 24. Apr 16, 16:28, edited 5 times in total.

pref
Posts: 5589
Joined: Sat, 10. Nov 12, 17:55
x4

Post by pref » Wed, 20. Jan 16, 05:41

I realized i forgot about small ships.. fixed pilot skills on purchase.

***

I got an error code 9 while updating the mod, so i had to recreate the thing - found nothing on google why that happens.
Got this from workshop tool

Code: Select all

ERROR: Could not upload file to Steam Workshop, error code 9
Anyone knows why this happens?


***

Another question: does anyone know how to reference the auto refuel setting of a commander/ship?
Couldn't find any doc/code sample mentioning it.

w.evans
Posts: 2963
Joined: Tue, 18. Nov 14, 16:23
x4

Post by w.evans » Wed, 20. Jan 16, 06:57

pref wrote:Another question: does anyone know how to reference the auto refuel setting of a commander/ship?
It's the captain's $config_autorefuel variable. If it's set to "1" then it's active. If "0" or if the variable is removed, it isn't.

boldhedgehog
Posts: 11
Joined: Sat, 30. Nov 13, 14:05

Post by boldhedgehog » Wed, 20. Jan 16, 13:17

Does it generate crew or "hire" from nearby stations?

Ezarkal
Posts: 1610
Joined: Wed, 22. Apr 15, 02:27
x4

Post by Ezarkal » Wed, 20. Jan 16, 15:47

Finally, someone made a mod for this!

Many thanks, pref!

I stopped playing XR since December, in order to take a break from it before the new DLC comes out, but you can be sure this is on my "to download" list as soon as I start playing again.
Humans are deuterostomes, which means that when they develop in the womb the first opening they develop is the anus.
This means that at one point you were nothing but an asshole.

Some people never develop beyond this stage.

pref
Posts: 5589
Joined: Sat, 10. Nov 12, 17:55
x4

Post by pref » Wed, 20. Jan 16, 16:36

w.evans wrote: It's the captain's $config_autorefuel variable. If it's set to "1" then it's active. If "0" or if the variable is removed, it isn't.
Thanks a lot!

Its weird, as i found this variable in move.jump, but it looked like a simple local cue variable - was referenced as this.$config_autorefuel
No clue why 'this' is a controlentity or has access to that property.
But it works anyway!! :D

Damn i cant update this now either, getting that error code 9 again :S
boldhedgehog wrote:Does it generate crew or "hire" from nearby stations?
Generates each on ship acquisition.
One of my main issues with hiring was that sometimes stations have no hirelings at all - think it's a bug but i often meet stations with a population of 4 for ex.

Phipsz
Posts: 334
Joined: Mon, 23. Apr 12, 23:56
x4

Post by Phipsz » Wed, 20. Jan 16, 17:53

pref wrote:
w.evans wrote: It's the captain's $config_autorefuel variable. If it's set to "1" then it's active. If "0" or if the variable is removed, it isn't.
Thanks a lot!

Its weird, as i found this variable in move.jump, but it looked like a simple local cue variable - was referenced as this.$config_autorefuel
No clue why 'this' is a controlentity or has access to that property.
But it works anyway!! :D
Yes, move.jump is an aiscript, therefore "this" references the entity it runs on (the commander in that case)
pref wrote: Damn i cant update this now either, getting that error code 9 again :S
have you tried posting the issue here?
pref wrote:Generates each on ship acquisition.
One of my main issues with hiring was that sometimes stations have no hirelings at all - think it's a bug but i often meet stations with a population of 4 for ex.
also, if you'd buy a ship from say Albion while being in DeVries, there would be no crew to hire at all, so good choice :)

pref
Posts: 5589
Joined: Sat, 10. Nov 12, 17:55
x4

Post by pref » Wed, 20. Jan 16, 20:16

Thanks for the explanation, i thought 'this' references just the cue im running in.
Is it like a large collection into which every property/object relevant to the current context gets merged?

Found a way to update btw, so refuel should be set to yes on every ship now.

@Ezarkal: thanks, hope it works without conflict with any of the more important mods..

w.evans
Posts: 2963
Joined: Tue, 18. Nov 14, 16:23
x4

Post by w.evans » Wed, 20. Jan 16, 21:28

In ai scripts, "this" is always the entity that is running that script. Really easy to work with once I wrapped my head around that one. I just imagine that I'm the person doing whatever that script says that I should be doing. I find MD much trickier, partly because you don't get that point of reference.

VincentTH
Posts: 6626
Joined: Wed, 6. Nov 02, 20:31
x4

Post by VincentTH » Wed, 20. Jan 16, 22:03

I need a mod that use the current smalltalk scheme, but allows crew members to level up over time based on the activity of the ship they serve. :-)

Say, every time they got shot at, Captain & Def Officer level up, and then if the Engineer fixes damage, he/she got the level up, and each zone the ship goes to, the captain level up, etc...

Sparky Sparkycorp
Moderator (English)
Moderator (English)
Posts: 8074
Joined: Tue, 30. Mar 04, 12:28
x4

Post by Sparky Sparkycorp » Wed, 20. Jan 16, 22:08

Yay, thanks :)

pref
Posts: 5589
Joined: Sat, 10. Nov 12, 17:55
x4

Post by pref » Wed, 20. Jan 16, 23:19

@w.evans: thanks, i see - those arent even cues..

@VincentTH: Should be possible, to increase a skill with a very low chance at certain events (subsystem destruction, repair finished or execution of certain commands could be some viable triggers). Skills are integers so you have to operate with a low random chance of increase rather then a predictable slow paced one.

I would never use such a mod though because it involves too much smalltalk and running around hunting crew. AC's purpose is to eliminate these kind of things entirely.

Just increasing skills slowly during use could fit the concept however - with starting skills of 2-4* instead of 4-5* perhaps. Im just not sure if its worth the effort for a mainly cosmetic change. Low skilled crew can execute the same orders as higher skilled ones - just a bit slower. And in no time all your employees would end up as 5* ones anyways.
Though it might lend some vague purpose and sense of immersion to the skill system.

@Sparky: Yay less hassle more play! :)
Hope you'll like it

w.evans
Posts: 2963
Joined: Tue, 18. Nov 14, 16:23
x4

Post by w.evans » Thu, 21. Jan 16, 07:13

pref wrote:Skills are integers so you have to operate with a low random chance of increase rather then a predictable slow paced one.
If interested, you could take a look at the boarding script. That adds a secondary variable that slowly increments every time your marine officer successfully leads a boarding op, then increases the boarding experience skill once that secondary variable reaches a certain value and, I think, resets the secondary variable.

Should be possible to do that for all NPCs. Trick would be how to implement it since the different things that the various NPCs can do are all scattered in different ai scripts.

I see you're not so interested in that, but putting this out there in case anyone is.

edit: hm. maybe an interrupt handler that's hooked into most of the ai scripts. will have to be simple though because several hundred instances of it would always be running.

pref
Posts: 5589
Joined: Sat, 10. Nov 12, 17:55
x4

Post by pref » Thu, 21. Jan 16, 20:07

Skill increase could fit the concept, i'd just need to find 'rare' events for that to hook into (like the ones i mentioned) - which dont cause conflicts with other mods preferably.

Timed checks or anything that runs for all entities (not just players) should probably be avoided. Think it could work with a low chance if without much complication and redundant data storage.

I have really no clue about what is safe regarding mod compatibility, thats the worst part of it.

w.evans
Posts: 2963
Joined: Tue, 18. Nov 14, 16:23
x4

Post by w.evans » Thu, 21. Jan 16, 23:02

Compatibility's also why I thought an interrupt handler could be good for this. Think it could be handled by a single interrupt script hooking into various ai scripts, namely:
pref wrote:subsystem destruction
fight.attack.object, fight.attack.object.capital, and fight.attack.object.station for pilots and defence officers,
pref wrote:repair finished
engineer.ai for engineers
pref wrote:execution of certain commands
we're missing captains, but that's trickier.

Inter-zone/sector/cluster movement for both pilots and captains goes through move.generic
Combat movement is move.attack.object.capital
Escort movement is move.escort (small ships, although capship captains go through this as well) and move.escort.capital

Mods could break if either:

- their patches don't land because either the node they hook into has changed, doesn't exist anymore or, if a mod relies on a node being unique, couldn't find it anymore;
- or the logic breaks.

Adding stuff in general is pretty safe. Only way that could break something is if you add something such that a formerly unique node that is referenced in a mod is no longer unique, or the logic is changed somehow.

Spot replaces are fairly safe as long as you replace only what is absolutely necessary and are very specific.

Removing stuff can be dangerous since, if a different mod looks for that node, it simply isn't there anymore. Added danger is that another modder sometimes can't just take your change into consideration because there wouldn't be something convenient to refer to at that location. That said, it sometimes can't be avoided. (Or I'm sometimes stupid. Especially when I try to stare at messy, uncommented code first thing in the morning.)

In my ai mods, once I start changing things past a certain point, I tend to move it over to a different file entirely and look for a single spot where I could divert over to my script if certain conditions are met. That way, changes to the vanilla scripts are kept to a minimum. (And much easier to keep up to date that way since you'll only have to keep track of one node per script rather than ten!) Don't think it's a good idea without those conditions though, or a way to allow the player to select which entities use which scripts (the way Yorrick, Euclid, and UniTrader do, for example) because if everything is running your script, your users won't benefit from updates at all (unless you update as well), and you'd have to be very conscious indeed of performance.

All that said, you can't be absolutely sure unless you have a pretty good idea of what's out there. And it's a good community we have here. Modders who run into a compatibility problem will often tell you about it, and will sometimes offer solutions to the problem.

ps. sorry that turned into a lecture. hope it is of some small use.

pref
Posts: 5589
Joined: Sat, 10. Nov 12, 17:55
x4

Post by pref » Fri, 22. Jan 16, 01:07

Thanks!

Could this work in fight.defend.capital for ex for DO without any performance impact?

Code: Select all

    <handler>
      <conditions>
        <event_object_destroyed object="$attacker" />
        <check_value value="this.ship.owner == faction.player" />
        <check_value value="event.object.isclass.ship and (not event.object.isclass.ship_xs)" />
        <check_value value="event.object.owner != faction.player" />
        <check_value value="event.param == this.ship" />
      </conditions>
      <actions>
        <set_value name="$IncChance" exact="0" />
        <do_if value="@$attacker.isclass.ship_xl">
          <set_value name="$IncChance" exact="25" />
        </do_if>
        <do_if value="@$attacker.isclass.ship_l">
          <set_value name="$IncChance" exact="10" />
        </do_if>
        <do_if value="@$attacker.isclass.ship_m">
          <set_value name="$IncChance" exact="2" />
        </do_if>
        <do_if value="@$attacker.isclass.ship_s">
          <set_value name="$IncChance" exact="1" />
        </do_if>
        <do_if value="true" chance="$incChance">
          <do_any>
            <do_if value="this.skills.combat lt 5" weight="40">
              <set_value name="this.skill.combat" operation="add" />
            </do_if>
            <do_if value="this.skills.leadership lt 5" weight="30">
              <set_value name="this.skill.leadership" operation="add" />
            </do_if>
            <do_if value="this.skills.morale lt 5" weight="30">
              <set_value name="this.skill.morale" operation="add" />
            </do_if>
          </do_any>
        </do_if>
      </actions>
    </handler>
Or i just wish it was so simple? :D
$attacker is just a local that doesnt even exist usually.

Captain could be in move.generic only perhaps, when target is reached (before the <break />) with a 1% chance or so.

Engineer when any component is repaired to max allowed hp.

CommanderTM
Posts: 567
Joined: Mon, 20. May 13, 09:18
xr

Post by CommanderTM » Fri, 22. Jan 16, 12:29

Sounds like an interesting mod! Will try it out. Is it safe to remove after trying??

pref
Posts: 5589
Joined: Sat, 10. Nov 12, 17:55
x4

Post by pref » Fri, 22. Jan 16, 13:02

Your employees that were generated by the mod will stay, and will keep their skills even after removing the mod.

Otherwise it has no effect on your games, so if you can live with that it's save safe.

w.evans
Posts: 2963
Joined: Tue, 18. Nov 14, 16:23
x4

Post by w.evans » Fri, 22. Jan 16, 21:16

Sorry haven't replied, pref. To be honest, I'm not familiar with fight.defend.capital, but it looks like it should work. If I read that right, it'll fire once whenever a DO kills something, and what it'll do isn't all that resource-intensive, so should be fine.

A couple of changes I would suggest:

instead of that series of do_if nodes, would change that to a simple do_if do_elseif ... do_else block. If you already know that an xl ship was killed, no need to evaluate whether or not it's also an s ship.

not sure if "weight" in that context will work. Not saying it won't. It might. Replacing them with "chance" would do something similar, but then there'd be a chance that more than one skill at a time would be incremented.

Oh, missed your do_any.

edit: no need to evaluate... rather than no way
Last edited by w.evans on Fri, 22. Jan 16, 21:42, edited 1 time in total.

pref
Posts: 5589
Joined: Sat, 10. Nov 12, 17:55
x4

Post by pref » Fri, 22. Jan 16, 21:31

Thanks!

Almost there - though noone will use it i think but it wont let me go now until i finish it...

It gets confused because the destruct event object ($attacker) doesnt exist always.

No idea how to tell it to skip an interrupt check if the object variable is null.

Post Reply

Return to “X Rebirth - Scripts and Modding”