New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Botcall, TG edition! #4974
Botcall, TG edition! #4974
Conversation
"<A href='?src=\ref[src];operation=patrol'>[auto_patrol ? "On" : "Off"]</A>" ) | ||
|
||
var/datum/browser/popup = new(user, "autosec", "Securitron v1.5.1 controls") | ||
var/datum/browser/popup = new(user, "autosec", "Securitron v1.6 controls") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cute. :>
- Floorbots are now anchored when moving to a hull breach. This prevents them being blown off course. - Fixes an accidental missing return for working mode in the floorbot and medibot. - Fixed the title of the Securitron's UI window. - Fixed the MULEbot's version number.
Thanks for catching that Beepsky name, Cheri. That is fixed now, along with the MULE's UI window name. Note: I made it so that floorbots are anchored when moving to fix a space hole or while building bridges. I saw that happen quite often during initial development, and it often prevented them reaching their target. |
👍 |
This is just a suggestion, but instead of having a lot if is checks for the current machine mode, instead make a mode datum class, this mode datum will have methods that implement the functionality of that mode for each method where you are doing if checks. Then instead of if checks you just call the submethod for the mode datum (the current one being stored in a var on the bot). You can change the bot mode by simply switching out the datum stored in the current_mode var. This will make the code cleaner, and will also simplify adding new modes as you can just write a new datum class that implements the required sub methods. If you want to learn more about this type of design then edit: I'd be willing to work on this after this gets merged to the TG mainline |
I would be happy to try that out, I am not familiar with this method though. I obviously would prefer to have this merged before completely rewriting and testing not only my expansion but the entirety of the code itself, as it could significantly delay development. |
@@ -72,7 +161,55 @@ | |||
new /obj/effect/decal/cleanable/oil(src.loc) | |||
healthcheck() | |||
|
|||
/obj/machinery/bot/Topic(href, href_list) //Master Topic to handle common functions. | |||
if(..()) | |||
return |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably be something like this:
. = ..()
if(.)
return .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah do this please, setting . to the value ..() returned (1 or 0) allows this topic to be if()'d easier later on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I never knew why people did that. Sure, will hunt for things like that and change accordingly.
TBH much of this is just magic to me. so yeah this is probably fine, but if somebody else could do a review i'd be very grateful. This has my 👍, though. |
radio_frequency = 1359 | ||
bot_type = SEC_BOT | ||
bot_filter = RADIO_SECBOT | ||
/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Misplaced slash?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. Will remove when I sync.
This is far from idle, btw. It is proving difficult to write move code for the bots that not only works but is better than how things are now. |
i have faith in you 🆗 |
I would be happy to show you my progress, Cheri, but in a branch not linked to this PR, I still have the following things to do:
Once I am done with that, I will add some tweaks in another commit, then resolve conflicts, especially with bugfixes that I fixed a different way or fixes that are to something I removed entirely. |
Thanks for doing this m8, future coders will thank you.
|
🚀 👨 |
- Created a proc to handle all bot movement, including patrols and PDA/AI summons. *NOT ALL BOTS ARE YET CONFIGURED TO USE IT!* That is for part 2. - Made/making bots faster while moving except for Secbots (balance issues) and MULEs (already super sanic). They will move twice per tick while moving/patrolling, and three times while summoned (PDA/AI) *PROCESS INCOMPLETE* - Gave bots a central ignore list for turfs they cannot reach, with a matching proc to use it. - New Scan() proc that will soon replace the highly similar ones in certain bots. Part of the effort to trim down on their repeated code. Added a define that defaults to 7 for view range. - Small tweak to the topic_denied() proc to use the user given by the primary topic. - Central process() proc so universal things for all bots can be easily added. (Except MULEs) Must return a 1 for child process() to run after it. - Corrected a spelling error. - Removed the extra path vars (summon_path, patrol_path, call_path) in favor of just using "path". - Compatibility changes to the summon and patrol procs. - Slightly tweaked cleanbot logic, removed some useless code, updated them to use the new scan() and bot_move() procs. Rest to follow. - Updated MULEbots to work with the new summon code. - Various small tweaks.
Committed my work so far so you know that this is very much alive, and also to get any bored coder's (or player's!) feedback on the changes so far. I will hopefully have the other bots done soon, then I can do a few more tweaks, resolve some merge conflicts (UUGH), test the crap out of it, fix any more bugs I find, then hopefully pass the maintainer review. |
Quick conversation happened just now on IRC this is placed as a reminder for GUN to change the shooting distance of the ED-209's to be within sight 7 of target Anything else I put here referance to this PR somehow. |
- Added Both summon types to the super process(), since both summon types reset the bot. - Reworked the logic and arguments for the scan() proc. [NEEDS CAREFUL REVIEW]. - Updated cleanbots to properly use the scan() and bot_move() procs. - Floorbots will now have the correct icons when reset. - The direction and state for Bridge Mode can now be selected from a popup. - Reworked Floorbot logic and code to use the scan and bot_move procs. - Fixed Floorbot target not resetting properly. - Updated Medibots to use scan and bot_move. No functional changes should occur.
The issues noted above will be fixed after I post a conflict fix, I cannot touch secbots until that is done. (ugh) The latest commit is about floorbots, cleanbots, and medibots. |
Here is another I just found in the list of unrepenting bugs: #3900 |
…G_Edition Conflicts: code/game/machinery/bots/bots.dm code/game/machinery/bots/cleanbot.dm code/game/machinery/bots/ed209bot.dm code/game/machinery/bots/floorbot.dm code/game/machinery/bots/medbot.dm code/game/machinery/bots/mulebot.dm code/game/machinery/bots/secbot.dm code/game/objects/items/devices/PDA/cart.dm
Mini-fixes to make secbots compile and functional once again. A full conversion will follow soon, as well as addressing other issues.
Did a quick merge conflict resolution, and fix for that. It integrates #5395 and #5171 as well. #3900 appears to be fixed. |
- ED-209's effective range has been reduced to 7, down from 12, to prevent them attacking people off-screen. - Ruthlessly nukes ".src" from the bot files, especially ed209bot.dm and secbot.dm! - Summoned bots now report on their department radio when summoned by PDA. - Bot radio frequencies now use the helpers instead! - Officer Pingsky (On the MiniSat) is now set to declare his arrests on the AI Private frequency, instead of Security. - The remote_disabled var now prevents bots from being summoned or controlled via PDA as well removing them from the AI's control panel. - The AI can no longer re-activate a bot's remote control radio by hacking it from the interface. - The telescopic baton is now considered a safe weapon to carry and wield by security bots. - Added a small reminder to PDA users that bots can download access from their ID to reach them.
See commit log for other changes. I have no further balance or feature changes planned. I will be making changes according to anything pointed out in maintainer review or further testing runs. |
…G_Edition Conflicts: code/game/machinery/bots/ed209bot.dm
Merge conflicts fixed (again). |
Telebatons being on safe weapons should be fine. Rather than giving all heads of staff a weapon license I think this works better and increases their value a little. Cheers. |
Kinetic Accelerator is now a safe weapon. |
If the AI can make custom destiantions, what's to stop an engiborg from hacking a mule and letting the AI ride around smashing humans at supersanic speed like a robotics hells angel? |
Rad as fuck gun hog. This code is 👍 in most places. I will try downloading this branch and bugtesting it later for you a bit, I want to see the improvements in bot movement. |
ABSOLUTELY NOTHING, BABY! (Except laws and the crew..lol) This possibility is completely intended and something I would love to see at least once in my life. It is going to be a bit clunky though, as I did not add code to prevent the AI getting auto-unloaded once the MULE reaches its waypoint. Also, the AI can only travel as far as it can see with its own core - the eyemob gets locked on the AI's position when loaded. It is not a priority at all, given that MULEs are not supposed to keep things loaded once they reach the dropoff point. And thank you, Paprika! I would be more than happy for you to help test, beat it bloody, and then drag the corpse back to me for autopsy! Prevention is soooo much better than maintenance! |
Doesn't EMPing mules totally fuck them up too? With the ion rifle? A malf AI doing that is pretty stupid outside of a gimmick if it's got borgs with it, and by that point the borgs have likely already won. The AI on its trusty mule steed with a horde of borgs following it. |
It happen! |
The port of Botcall, modified for compatibility with /tg/!
Forum link here: http://coderbus.com/phpBB/viewtopic.php?f=5&t=1284
Expansion to bots in general:
*Bots called by the AI always receive all-access during a call by the AI, so it does not have to open airlocks beforehand.
*A bot can be configured to deny the AI remote (from the panel, not the cameras) access if you are worried it is rogue or you are an antagonist yourself. This happens automatically if the bot is manually emagged.
*This same setting also prevents the bot being controlled by PDA, so be warned!
Floorbots:
Cleanbots:
This is a hacked cleanbot!
Medibots:
(Medibot in stationary mode)
Securitrons:
ED-209 (includes Securitron changes):
- Effective range nerfed from 12 to 7. This range is in line with other bots and player ranges.
MULE: