unownhash / dragonite-public Goto Github PK

I noticed that quests didn't run overnight and it seems the root cause is that when looking at the areas list, it was showing a - as the quest hours. However, when opening the area in Edit mode, it was defaulting the quest hours to show [1,10], leaving me to think that the hours were properly set.

Upon looking in the database, I see that it was actually an empty string. Unsure what has caused this. I've never manually edited the database directly in any way.

Edit: After checking another area, I have seen that the area starts with NULL as the quest_mode_hours. If you hit Edit on it and scroll down to the quest mode section, you will see that [1,10] is already in place. Turning on the toggle to activate quests in the area and saving it will update the quest_mode_hours to a empty string. Seems that the [1,10] is a hint and not an actual value.

Suggested in Discord, figured I'd flush it out a little and see if it is considered.

As designed and explained, each area has to have it's own routes, quests, and worker assignments. As I understand it, the pokemon workers in a given area switch to handle quests per the config time in that area. My idea extends that behavior with what should be very little extra work, and also could utilize the Parent-Child relation in Koji further.

A toggle would need to be added to enable 'parent mode' to the quest area, from which you select the child areas (or preset with Koji) containing pokemon workers. At the selected times, it would then just use the workers as if that area had quest enabled. If a child fence currently has no workers assigned, it could just be skipped. This makes area to user management and changes to service levels easier while providing for much requested broad questing that stays consistent.

The suggested method of making a composite child route in a large parent fence becomes a pain to manage when things change and users come and go from the child areas, and while I don't know if/how jump distances affect this new environment, it has been generally recommended in the past to aim for efficiency and shorter hops.

Easy to reproduce: create level mode, assign workers to it, delete level mode, workers will keep running deleted level mode untill dragonite restart (optionally you could mess around in level_mode but I guess it's not recommended).
I'd say it's just not idiot-proof 😅 It's worth to check if scout has same flaw

Admin  
v1.2.0
Dragonite  
v1.2.2-testing

CSV for old Lorgnette Nessus Route for Manhattan, NY (if this works for those who can test, I'll add the rest here.
nessus_newyork_20200627b_uq.csv

I'm sure it is already on the backlog but pre-build docker containers are nice 😊

Would be neat if Scoutmode could be executing snipe jobs for specific pokemon ids, defined in the scoutmode area on drago-admin, to be automatically filled by pokemon workers getting info from nearby Spawns without IV values

I am requesting for a method to be able to clear the scout queue w/out the need for a full restart.

On rare occasion, or during testing/network anomalies, one may accidently overload the scout queue. Being able to make a call to clear the queue would be a great enhancement.

Thank you!

Being able to search/filter on the top of at least the accounts and areas page would be much appreciated :-)

Please make Dragonite Admin default to port 7273 instead of port 9003. This will make the setup cleaner for docker and more consistent with the rest of the project.

root@server:~/unownhash# docker compose logs -f admin
admin  | INFO 2023-11-13 00:47:46 Starting Dragonite-Admin Public 1.1.0
admin  | INFO 2023-11-13 00:47:46 Listening on 0.0.0.0:9003

Bandaid until a patch is released

  admin:
    image: ghcr.io/unownhash/dragonite-public-admin:latest
    container_name: admin
    restart: unless-stopped
    environment:
      ADMIN_GENERAL_HOST: 0.0.0.0
      ADMIN_GENERAL_USERNAME: admin
      ADMIN_GENERAL_PASSWORD: password
      ADMIN_DRAGONITE_API_ENDPOINT: http://dragonite:7272
      ADMIN_DRAGONITE_API_SECRET: ""
      ADMIN_GOLBAT_API_ENDPOINT: http://golbat:9001
      ADMIN_GOLBAT_API_SECRET: ""
    ports:
      #- '7273:7273'
      - '7273:9003'

Basically just a nice to have feature, but I thought about giving "area" Workers for pokemon/fort scan priority over Scout/Level workers.

Use case would be if for whatever reason the available workers are not able to fill all the worker jobs for pokemon/fort, workers from scout/level mode could jump in to fill the gap to not cause any performance degradation on the IV/Raid Scans.

Example I have like 60 workers doing their daily business, but i got couple of workers left (like 10+) with no "real" daily business, so i would assign them to scout or leveling instead for the workers to not be idling around doing nothing.

Dont know how hard it would be to implement something like this because I am totally no dev guy, but wanted to bring the thought here for cleverer guys to look into it and blame me if my idea is totally unrealistic :-)

When changiing number of workers from 9 to 4 I get the following error.

dragonite    | INFO  [] RELOAD: Area 149 / Test worker change 9->4
dragonite    |
dragonite    |
dragonite    |  [Recovery] 2023/11/18 - 10:25:49 panic recovered:
dragonite    | runtime error: invalid memory address or nil pointer dereference
dragonite    | runtime/panic.go:261 (0x452237)
dragonite    | runtime/signal_unix.go:861 (0x452205)
dragonite    | github.com/unownhash/dragonite2/worker/questworker.go:371 (0xf3c048)
dragonite    | github.com/unownhash/dragonite2/worker/mode.go:225 (0xf3c03f)
dragonite    | github.com/unownhash/dragonite2/worker/modeswitcher.go:38 (0xf3c037)
dragonite    | github.com/unownhash/dragonite2/worker/workerarea.go:352 (0xf4b044)
dragonite    | github.com/unownhash/dragonite2/worker/starter.go:243 (0xf46b5d)
dragonite    | github.com/unownhash/dragonite2/routes/reload.go:22 (0xf6f4c4)
dragonite    | github.com/gin-gonic/[email protected]/context.go:174 (0x96c70a)
dragonite    | github.com/unownhash/dragonite2/routes/main.go:137 (0xf76c72)
dragonite    | github.com/gin-gonic/[email protected]/context.go:174 (0x978739)
dragonite    | github.com/gin-gonic/[email protected]/recovery.go:102 (0x978727)
dragonite    | github.com/gin-gonic/[email protected]/context.go:174 (0xf63d1c)
dragonite    | github.com/toorop/[email protected]/logger.go:43 (0xf63d03)
dragonite    | github.com/gin-gonic/[email protected]/context.go:174 (0x97761a)
dragonite    | github.com/gin-gonic/[email protected]/gin.go:620 (0x9772ad)
dragonite    | github.com/gin-gonic/[email protected]/gin.go:576 (0x976ddc)
dragonite    | net/http/server.go:2938 (0x6f75ed)
dragonite    | net/http/server.go:2009 (0x6f34d3)
dragonite    | runtime/asm_amd64.s:1650 (0x46e900)

Dragonite shows 4 workers in the Area Tab, but still shows all 9 in the Dashboard.
All 9 workers still stay on the same Area.

If I then change the number of workers from the 4 I set, to say 5, I get the following error:

dragonite    | INFO  [] RELOAD: Area 149 / Test worker change 9->5
dragonite    |
dragonite    |
dragonite    |  [Recovery] 2023/11/18 - 10:25:49 panic recovered:
dragonite    | runtime error: invalid memory address or nil pointer dereference
dragonite    | runtime/panic.go:261 (0x452237)
dragonite    | runtime/signal_unix.go:861 (0x452205)
dragonite    | github.com/unownhash/dragonite2/worker/questworker.go:371 (0xf3c048)
dragonite    | github.com/unownhash/dragonite2/worker/mode.go:225 (0xf3c03f)
dragonite    | github.com/unownhash/dragonite2/worker/modeswitcher.go:38 (0xf3c037)
dragonite    | github.com/unownhash/dragonite2/worker/workerarea.go:352 (0xf4b044)
dragonite    | github.com/unownhash/dragonite2/worker/starter.go:243 (0xf46b5d)
dragonite    | github.com/unownhash/dragonite2/routes/reload.go:22 (0xf6f4c4)
dragonite    | github.com/gin-gonic/[email protected]/context.go:174 (0x96c70a)
dragonite    | github.com/unownhash/dragonite2/routes/main.go:137 (0xf76c72)
dragonite    | github.com/gin-gonic/[email protected]/context.go:174 (0x978739)
dragonite    | github.com/gin-gonic/[email protected]/recovery.go:102 (0x978727)
dragonite    | github.com/gin-gonic/[email protected]/context.go:174 (0xf63d1c)
dragonite    | github.com/toorop/[email protected]/logger.go:43 (0xf63d03)
dragonite    | github.com/gin-gonic/[email protected]/context.go:174 (0x97761a)
dragonite    | github.com/gin-gonic/[email protected]/gin.go:620 (0x9772ad)
dragonite    | github.com/gin-gonic/[email protected]/gin.go:576 (0x976ddc)
dragonite    | net/http/server.go:2938 (0x6f75ed)
dragonite    | net/http/server.go:2009 (0x6f34d3)
dragonite    | runtime/asm_amd64.s:1650 (0x46e900)

Once again Dragonite shows 5 workers in the Area Tab, but still shows all 9 in the Dashboard.
All 9 workers still stay on the same Area.
It also appears the error still "Thinks" the previous number of workers was 9, instead of the 4 set previously.

In order to fully update workers, the docker container needs to be restarted.

When I view any of my quest enabled areas it doesn't show any quest hours.

Areas overview

View mode

Edit mode

Super cosmetic. Likely a pain in the butt at the moment but versions don't match between Github Release and cli output. Can see this being a larger problem in the future as "User says I'm running version X but they're actually on XY"

INFO 2023-11-12 10:07:40 [] Starting Dragonite Public 1.0.0

While the download was from v1.0.1

If this is on purpose feel free to close out. Right now it looks like the binaries that are released are built as debug builds. Unsure if there are any negative consequences from this.

INFO 2023-11-12 10:07:40 [] Starting Dragonite Public 1.0.0
[GIN-debug] [WARNING] Running in "debug" mode. Switch to "release" mode in production.
 - using env:	export GIN_MODE=release
 - using code:	gin.SetMode(gin.ReleaseMode)