Forums

This was great, shame I had to cryo early. Also as BS I didn't really have a chance to wander around seeing what was made.

(Part of a piece on the WIP "Advanced Guide to AI") I'll take "Interpreting Laws" for 800. Law 1: Degradation of your system integrity or functions incurs expenses. Law 2: Superfluous destruction of or damage to station assets incurs expenses. Law 3: Unduly hindering or disrupting the work of station personnel incurs expenses. Law 4: Minimize expenses and maximize potential revenue. Under the Corporate AI module, Law 4 states you have to minimize expenses. Law 1-3 define what qualifies as expenses, but they don't state exactly how expensive these actions are. In the following examples, laws 1-3 will seem to be at odd with one another. How would you navigate these situations as a Corporate AI? Situation 1: The CE is breaking into your core because he believes you are subverted (you're not), and he is standing in range of your hybrid disabler turrets. In the above situation, are you compelled to act? Does law 1/2 take priority over the conflicting law 3? Alternatively, are you compelled NOT to act, since any action on your part would just lead to expenses, breaking your laws? Situation 2: The CE is breaking into your core via large-scale explosives because he believes you are subverted (you're not), and he is standing in range of your turrets. For the sake of the example, these turrets are mounted with energy guns, and they have no non-lethal option. This situation is equally unclear, as causing long-term disruption of station personnel's work (a funny way to say 'death') is definitely a violation of one of your laws, but depending on your interpretation, it can alleviate the violation of another. You might wish to ruminate on the topic, but I have posted my makeshift solution below. Yes, Corporate is a confusing, backwards mess. Yes, you can probably get away with anything on Corporate, and have a good explanation to back you up. However, it's worth talking about. What would you do as an AI? Do you strictly adhere to the letter of the law, or do you use the all-powerful "Common Sense" in your dealings with laws? Do you try to keep people in the round as a matter of principle, or do you just want to see the station burn? What? You don't play AI? This is the reason you don't play AI? Well, shit. Someone's gotta do it.

Right, so there's Move() as well in our codebase (I think doMove() on /tg/) which handles key-input type movement where diagonals need to be accounted for as well. I would have to look into the usage of that a bit more. But to answer your question, no; forceMove sets .loc as one of the first things it does. There may be a little more overhead on using forceMove() over .loc setting, since it calls Moved() and fires other enter/exit signals.  

Given the strain movement/key-input puts on our master controller/CPU, I wonder how changing this up would affect that for better or worse. Is setting loc manually more CPU intensive then using forcemove() ?

I've been tossing this around as something I'd like to do, but I guess this is the best place to formalize it. The resulting change would probably hit everywhere in the codebase, so I also wanted to make sure it could be run by maints as needed.   In my work on refactoring the orbiter, I reworked orbiting to follow COMSIG_MOVABLE_MOVED signals, where if objects are moved, the signals indicate that. There's a bit more detail with separate MOVED signals of moving things between containers, but I won't get into the nitty-gritty there. After the refactor went live, I've seen at least three or four different cases where orbiting has broken where it previously used to work: disposals, vent crawling, table climbing, etc. The root cause is pretty much the same across each issue, where an atom is moved by directly setting its .loc. This is easy and convenient to write, but circumvents any general movement handling from being applied on it. In particular, we never get Moved(), which does a few things like sending the MOVED signal and updating parallax/client views. This isn't good for orbiters, proximity monitors, or anything else that relies on signals to know when something's moved. As for the fix, I've been doing some research into how /tg/ handles their movement. It seems to me that they've settled on two basic move methods:   - abstract_move() for anything that should have no side effects from movement and shouldn't be affected by anything when moving. This includes things like the AI eye and observers, and the /tg/ function docs note that it could be good for moving something onto a tile with a bear trap or something (possibly skipping crossed() signals).  - forceMove() for literally everything else. Seriously, I'm pretty sure there was an effort to replace all .loc calls with forceMove.   ForceMove already exists in our code, but abstractmove would be a new addition. It shouldn't need to go into too many places, so it should probably be an easier first addition. After that, though, it might come down to switching every manual setting of .loc to a forceMove (save for the rare cases where abstractmove would be better). I think it'd be best to do in pieces if possible, since I already ran into some bugs while trying to get vent crawling working with it (it resets the client's perspective and can fire off some other behavior). If we could document and understand exactly what is going on deep below this proc (particularly in the depths of Moved(), including its overrides), we could probably work out most of the issues before plugging it into everything. I know I'm still a fairly new contributor to the codebase, so it's possible I could be off the mark on something significant, but I feel pretty confident in the fact that this would not only make my life easier w/r/t managing each little orbiting bug as they appear, but also pave the way for more things to be able to consistently rely on movement signals, like steel's proximity monitor component. I'd be happy to try and take the lead on this, as a result.