Jump to content
×
×
  • Create New...

Script Writer Application


Dogue
 Share

Recommended Posts

  • Administrators

This is really nice, would be even cleaner in kotlin.

Especially like the folow diagram, that's good practice.

 

Few things I can suggest:

  • Use the result of #interact more, this will prevent the script from sleeping at all on misclicks. Our interact method returns pretty accurately whether the interaction succeeded or not as it hooks into game action events.
  • CPU resource is limited on mobile/emulators, I'd be keen to explore other ways the cleanup of files could be implemented so there's no need for a separate thread.
  • I'm not familiar with Tithe but is there no need for configuration for the script?
  • Be careful of filtering objects without a radius/tile/area, it's quite expensive to load all objects into memory to be filtered. Methods such as `within` & `at` will mean that only objects at the given tiles/area will be loaded into memory.

 

 

Link to post
Share on other sites

1 hour ago, const_ said:

This is really nice, would be even cleaner in kotlin.

Especially like the folow diagram, that's good practice.

 

Few things I can suggest:

  • Use the result of #interact more, this will prevent the script from sleeping at all on misclicks. Our interact method returns pretty accurately whether the interaction succeeded or not as it hooks into game action events.
  • CPU resource is limited on mobile/emulators, I'd be keen to explore other ways the cleanup of files could be implemented so there's no need for a separate thread.
  • I'm not familiar with Tithe but is there no need for configuration for the script?
  • Be careful of filtering objects without a radius/tile/area, it's quite expensive to load all objects into memory to be filtered. Methods such as `within` & `at` will mean that only objects at the given tiles/area will be loaded into memory.

 

 

Thank you for the feedback - I've made sure to limit the radius using `within`, and I've made use of the #interact return values.

As far as configuration goes, there are only three seeds to select from, only with differing xp rates but no change in functionality. The script just picks the best one. I would; however, add one for can refilling - the selections being from the water barrel or using humidify.

Link to post
Share on other sites

  • Moderators
15 hours ago, Dogue said:

I would; however, add one for can refilling - the selections being from the water barrel or using humidify.

I would argue that if the player doesn't have the required items for humidify, then there's no need to even configure it, unless you were planning to add banking to withdraw said items, not sure why you would unless/until script chaining becomes viable. 

------

Really nice script, nice clean layout and good usage of the API. I don't really have much in terms of constructive feedback however there are a few bits which aren't mandatory, but useful to note.

Order of filter usage; https://github.com/David-Rodden/DTithe/blob/529ef52e9400efaa16f5758b687d73542a72628f/src/nodes/PlantSeed.java#L46 here you use 
 

Objects.stream().within(20).name("Tithe patch").at(seedlingTile).isEmpty()

Which splits it into the following sort of logic

Objects stream - (random figure, lets go with 500 objects)
Within 20 - (argument sake, lets say it removes 250 objects)
Name "Tithe patch" - (I don't' remember how many patches there are but within a 20 radius, probably like 16 or so)
at specific tile - only 1 patch is at that tile

As far as I'm aware, there's no need to pass within AND at tile as within is filtering to 20 tiles, then at is filtering to 1 tile, may as well just filter to 1 tile; for example

Objects.stream().at(seedlingTile).name("Tithe patch").isEmpty()

So here it goes

Object stream - 500 objects
at specific tile - 5 objects
name - 1 object

I'm waffling now but hopefully you understand what I'm trying to say.

------

This one is probably personal preference but some of your conditional waits are quite long in terms of time between rechecking for example; Random.nextInt(500, 800), 3 so could be up to 800ms before it rechecks the boolean, I personally prefer to use smaller waits and more retries, so 150, 16, would be the same maximum wait time, but less redundant waiting if the boolean returns true in 200ms, you're still waiting another 600 before moving on. It doesn't sound like a lot but sometimes 500ms repeated for every action over hours, can really reduce script efficiency.

However saying that, obviously the more you check the bools the more resource is required from the system but personally I find it fine even when doing 50ms checks.

------

Either way both items mentioned are very minor and just really there as pointers however unless anyone else wants to comment, I'd be happy to welcome you to the team although you're already half way there 😛

@const_not sure if there's any further permission changes required on your end.

Link to post
Share on other sites

 Share