rubber duck tf fic (Patreon)

let's try a new approach.
usually i make posts after i've made something because i dislike talking about work i haven't already done.
but im sitting here working on some code and thinking "this is probably something i could make a post about, but i oughta focus on actually doing it"
the inherent problem there is that after i've already done something i often don't have the time or energy to post right away, and by the time i do have the time or energy, i want to use it on making progress again, and then whatever i was working on before is like Stale to me, and then i just never post it and never post for months.
sucks

but in coding there's a concept called rubber-ducking, where programmers just talk out loud about what they're doing to a simple silly rubber duck sitting on their desk, and the act of trying to explaining what the fuck we're doing to another presumably conscious individual (believe in the spirit of the ducky) helps focus and straighten out the mental knots that coding is wont to involve

so if you're reading this, congratulations, you've just been contracted as my rubber duck. i'll just write the post as i'm working on the thing.

one of the things i've been excited to do lately (over the past couple months since i came back to working on stuff) is trying to do my own devops-- i.e figure out how i can make making the game faster.
a poignant example of this was with the message system-- coding events felt super daunting before because i had to put in the message frame manually for every text box, and update every character's facial expressions every time the speaker changed, and reference ever speaker by id number, etcetc
so that alone meant i was doing every event in like 3-5 passes instead of just one and im honestly not sure how i made the demo that way, that was not a good idea to be honest lmao
so lately i've been looking for ways to make things easier and faster for myself and that has honestly lightened the load so much already.

but we can do more!

so today i'm looking to make events easier on myself by creating a function that says "please make character X face character Y regardless of where they are"
RPG Maker has this for making events (characters) face the player. It does not have this for making the player face another event, or making an event face another one. There have been a lot of times I've had to manually do silly stuff in Reborn where I say-- here, here's an example:

This is the Victoria/Fern battle event after the Grand Stairway. Victoria can be talked to from all 4 directions, meaning if I want the player to face victoria again after fern leaves, I need four branches to make the player face her no matter where they're standing. Here, I set Self Switches earlier in the event to store which direction we talked to her from, but in many other cases I have resorted to a manual coordinate check, asking if the player was standing at position X,Y 25,30, or 26,29, or 25,28, or 24,29-- and facing based on that.
horrible. absolutely horrible.

so we're not doing that again, thanks.

So, RMMV actually already has a function to make one event turn towards another, we use it here for making events do that when attacking each other in tactical battles. It just isn't accessible during eventing. I've copied that function over into the map scene and we're going to adapt it for free use in events.

strictly speaking, this would just Work As Is, but for two things. firstly, direction fixing. direction fix true means the character is locked into their current facing; nothing that happens will be able to change them to a different direction. this is good for the tactical system because facing has to be static there since it matters a lot; it is not good for events because right now it will always get turned on after this command and that will be Annoying.

so step 1 is making it respect the existing property:

we get its current direction fix status, save it, set it to false because if we're calling this command we definitely want it to turn directions, and then restore the old setting.

the second reason that this won't work as is, is because of the variables that are passed to it. this function is expecting whole event objects-- the actual data of the event itself, but that is also a pain to get from eventing. so, let's make this a little easier on myself.

i've been through this with message arts already. Like I said above, I used to have to refer to message arts strictly by id, as I have done in projects since i was 12. but things get a lot easier when i set up a function for myself to just be able to refer to characters by name and let the code figure out whos name belongs to who's id. So, we have this sanitizeId function from message arts; let's make it sanitizeEventId here.

this code is from message arts; unlike the above, it won't fly at all. but there are a couple useful lines that i copied in for myself, such as making strings fully lower case. it starts by asking if the provided value is already an integer, and if so, it doesn't need to do anything for message arts. rather than an integer, this time we ultimately want the event object. so let's start by asking if it is an object.

if it's an object, spit back the object; nothing to do here. we just kind of have to assume it's an eventObject and that i haven't somehow managed to give it a particle or something stupid.
if it's a number, get the eventObject from an array; spit that back out, easy.
if it's a string-- and i'm usually going to be feeding this strings because it's easier to say "face Victoria towards Fern" rather than "face event 50 towards event 51"-- then we need to do some extra work.

It takes some extra finagling, but we eventually get to this:

$dataMap is a collection of information about the event that is generally unused by the game, as distinct from $gameMap which holds the real objects manipulated by the game. so we gotta look up the name in one to use it with the other.

now let's do some error proofing. right now if i typo a name it'll just crash. no bueno. we'll add a condition for if the search doesn't find anything; it won't crash but it will put a message into the console for me to check myself rather than wreck myself.

secondly, what if I want one of the events to be the player? this is easy enough to handle; I just have to make sure I do so.

our final result for sanitizeEventId is this:

let's do some quick tests:

missed an apostrophe; otherwise looking good. Game_Player is just a specialized Game_Event.

now let's put our new function to use in our original project:

this isn't the sort of thing that i can really make a good gif out of, but a few more tests shows it's working great. this will be a lifesaver for me.

i'm not done though. there's another tool that i want to make for myself. It's kind of similar to what I just showed off the other day, actually-- but something that will detect when we are or are not within a certain range of a given event.

I started using this a little bit in Reborn as well. You know how the leaves in Rhodochrine Jungle get denser the closer you get to the tree?

this is already running a similar check every so often-- detect how close the player is to the tree and do some math to adjust the leaves' opacity based on that. I did this in scripts rather than events just for optimization (event processing is not very fast), but were it more readily available, there are many cases in which it would have been handy.
so let's have it for starlight!

there's already a case where I'm doing this just with the couple NPCs I have:

that "manhattan" function is just a quick way of running the math to get the distance between two events. idk what makes manhattan so special but that's what it's called. anyway, doing the rest of that through events is obnoxious. so let's check it.

start with the event sanitization we just set up. we no longer need to save the X/Y manually because we have them as part of the event object. run the calc. return the result:

Works easy. Suddenly the above is simplified to this:

Easy gains every time. Should've done this ages ago for Reborn. Now there's not really much use in it for me, but you know what they say about hindsight.

Thanks for sticking around, duckies. I'm gonna go play with my new toys.