|
Notes |
|
|
|
|
The bot stops to chat when botcmd_Delay() is called, but the solution is not modifying that function. The cleanest approach is to prevent the chat command from being pushed to the stack, and I have no idea where and how that happens. |
|
|
|
|
|
Bot commands are issued by BOTCMD_RunCommand() (duh), called by CSkullBot::ParseScript, the command is determined by the value of sdwBuffer. |
|
|
|
|
|
BOTCMD_e is an enum passed as an argument to BOTCMD_RunCommand(), the following values are relevant: BOTCMD_DELAY (2), BOTCMD_SAY (49), BOTCMD_SAYFROMFILE (50), BOTCMD_SAYFROMCHATFILE (51), BOTCMD_BEGINCHATTING (52), BOTCMD_STOPCHATTING (53), BOTCMD_CHATSECTIONEXISTS (54), BOTCMD_CHATSECTIONEXISTSINFILE (55), BOTCMD_GETLASTCHATSTRING (56), BOTCMD_GETLASTCHATPLAYER (57), BOTCMD_GETCHATFREQUENCY (58), BOTCMD_SAYFROMLUMP (89), BOTCMD_SAYFROMCHATLUMP (90), BOTCMD_CHATSECTIONEXISTSINLUMP (91), BOTCMD_CHATSECTIONEXISTSINCHATLUMP (92). |
|
|
|
(0021240)
|
|
WubTheCaptain
|
2020-03-26 11:54
(edited on: 2020-03-26 11:56) |
|
Quote
Bots should not attempt to chat when bot_allowchat is false
Quote
Summary is self-explanatory.
This is as intended, no issue here.
If they do attempt to chat while bot_allowchat is false, that would be an issue.
|
|
|
|
|
|
Screenshot added with the bug happening. |
|
|
|
(0021242)
|
|
Vicious Pariah
|
2020-03-27 00:24
(edited on: 2020-03-27 01:27) |
|
I do recall this being a longstanding glitch with it. The bot full-stops (ceases all movement) to "chat" but it would seem that instead of preventing them from stopping; the only difference is no chat actually goes through. They should not stop.
|
|
|
|
|
|
Yeah, this is a bug, but I fear it's a bug in the (compiled) bot script, not in our bot VM. Properly fixing it would need to fix the script, which would need a bot script compiler, which we don't have, since Carn lost the source ages ago. |
|
|
|
|
|
|
|
|
I don't know if this reply helps at all, but apparently the "Sanity Check" failed. Here's an interesting piece I found from the repo, considering it's the last update made to this project since then:
'https://circleci.com/gh/TarCV/botc/43?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link [^]'
This is just a wild guess, but maybe this doesn't actually help to actually decompile the old botcode completely, but it's pretty close. I don't really remember much of Dusk's plan for the bot compiler, and how closely related it is to Carn's, but here is the decompiler:
'https://github.com/TarCV/debotc/ [^]'
I'm really not the best person to give advice or feedback, but I'm sure the dev team will probably look it over as best they can, whilst I try my best to understand it myself. So, I mean, in the meantime you could work with the decompiler if you want, I guess.
The best case scenario is this: we're actually not going to try to decompile a bot that used Dusk's bot compiler,'https://bitbucket.org/crimsondusk/botc [^]' but rather one of the "original" compiled bots, and see what kinds of errors it throws. And then from there you could "guess?" what kind of voodoo Carn put there? Even then it's not really a scenario that you can progress from, since we're still without Carn's version.
Oh and I've noticed my messages are like really long while everyone else's is probably like a couple sentences at most. Woops. :( |
|
|
|
|
|
The bot code is decompiled already, the problem is now fixing and completing the compiler, linked in 0021246. Not an easy task since it is written in C++ and I only know C. I have some notes written here <https://github.com/TarCV/botc/issues/2>, but that bug doesn't get much in the way to compile something, it just makes the compiler crash if there is an unknown variable. |
|
|
|
|
|
screenshot.png (100,432) 2020-03-26 17:29
bots.pk3 (15,709) 2020-04-21 07:45