Problem:
In a project I maintain after recent changes Z-level means depth, but it's not consistent, so z1>z2 not always means that z1 is located higher/lower than z2, sometimes they're not even comparable.
While needed, this system somewhat breaks default behaviour of get_step(), because it leads not where it should lead to when dir contains UP or DOWN.
So, is there any way to redefine instruction (get_step() in this case)?
(If I'd able to redefine it, all the conflicts could be easily fixed by one single change)
Jan 14 2017, 6:31 pm
|
|
Maximus_Alex2003
 |
So you want to change how get_step() operates?
|
Yes.
| |
Jammer312 wrote:
Yes. I suppose you could make your own get_step(), otherwise I don't believe there is a way to modify it like you would with most predefined processes, unless someone else can chime in. | |
What are these recent changes you guys are talking about? Z level doesn't mean what it used to anymore?
| |
It meant different places before, now it means different multi-layered places.
So, this were 2d areas before, now these are 3d areas. | |
Uh what? Nothing's changed in relation to that.
| |
Nadrew wrote:
Uh what? Nothing's changed in relation to that. ^ Yeah see I've not heard that either. Z is still Z from what I can tell. Nothing changed. | |
These were changes to project, not to byond
| |
Actually it wasn't me who done it.
It was addition to tgstation13 If you still want to see code, here's commit that adds it: https://github.com/animusdev/green/commit/ 394bfaa296528abb78f93258969476c2de5b3e3c (possibly it was changed a bit later, but still it's main change) It creates special controller at each level that knows which Z-level is located above and which one is located below the level controller is on. So Z-level is not consistent and instructions like get_step(n,UP) don't work as needed. | |
The reason I seek way to redefine instructions is that project is kinda big and finding every place where get_step is used wrong regarding Z-levels and patching it all by hand is really bad way to do it.
| |
When I worked on Scream of the Stickster, I discovered the UP and DOWN consts and how they interacted with get_step(). I had the problem that z+1 represents down and z-1 represents up in that game. In that project, the constants were irrelevant because it was a 4K; I was using the actual values 16 and 32, which are shorter. But had they been relevant, I would have simply swapped the usage of them.
For your case, it sounds like you need something more complex. I would suggest creating a utility function to do what you need, for instance GET_STEP (so it's clear that it's redefined for a reason), where it can do the necessary lookups. Then simply do a find/replace in the entire codebase (except for that proc), replacing get_step with GET_STEP. Here's a word of caution, though: SS13 is very CPU-locked. The faster any proc can operate, the better. So in cases where you absolutely know up and down are not in play, you probably don't want to use this custom GET_STEP, but rather the original built-in get_step, since that compiles to bytecode rather than an expensive proc call. | |
