Commit Graph

17 Commits

Author SHA1 Message Date
John Willard
fa31403353 LateInitialize is not allowed to call parent anymore (#82540)
## About The Pull Request

I've seen a few cases in the past where LateInitialize is done cause of
the init return value being set to do so for no real reason, I thought I
should try to avoid that by ensuring LateInitialize isn't ever called
without overriding.

This fixes a ton of machine's LateInitialize not calling parent
(mechpad, door buttons, message monitor, a lot of tram machines,
abductor console, holodeck computer & disposal bin), avoiding having to
set itself up to be connected to power. If they were intended to not
connect to power, they should be using ``NO_POWER_USE`` instead.

Also removes a ton of returns to LateInit when it's already getting it
from parent regardless (many cases of that in machine code).

## Why It's Good For The Game

I think this is better for coding standard reasons as well as just
making sure we're not calling this proc on things that does absolutely
nothing with them. A machine not using power can be seen evidently not
using power with ``NO_POWER_USE``, not so much if it's LateInitialize
not calling parent.

## Changelog

🆑
fix: Mech pads, door buttons, message monitors, tram machines, abductor
consoles & holodeck computers now use power.
/🆑
2024-04-08 22:15:07 -06:00
Bloop
f34174414d Cleans up some extra args in Destroy() (#80642)
## About The Pull Request

After https://github.com/tgstation/tgstation/pull/80628, these shouldn't
be needed anymore right?

## Why It's Good For The Game

Cleans up some vestigial code

## Changelog
EDIT: Not player-facing.
2023-12-30 03:54:07 +01:00
MrMelbert
1e76fd70b4 Attack chain refactoring: Broadening tool_act into item_interact, moving some item interactions to... atom/item_interact / item/interact_with_atom (#79968)
## About The Pull Request

Implements half of this (with some minor changes): 


![image](https://github.com/tgstation/tgstation/assets/51863163/bf5cc4bb-5a1f-42e3-921d-9a57bc6096cc)

The ultimate goal of this is to split our attack chain in two: 
- One for non-combat item interactions
  - Health analyzer scanning
  - using tools on stuff
  - surgery
  - Niche other interactions
- One for combat attacking
  - Item hit thing, item deal damage. 
  - Special effects on attack would go here.  

This PR begins this by broadining tool act into item interact. 

Item interact is a catch-all proc ran at the beginning of attack chain,
before `pre_attack` and such, that handles the first part of the chain.

This allows us to easily catch item interaction and cancel the attack
part of the chain by using deliberate bitflag return values, rather than
`TRUE` / `FALSE`*.

*Because right now, `TRUE` = `cancel attack`, no matter what, which is
unclear to people.

Instead of moving as much as possible to the new proc in this PR, I
started by doing some easy, obvious things. More things can be moved in
the future, or technically they don't even need to move in a lot of
cases.

## Changelog

🆑 Melbert
refactor: Refactored some methods of items interacting with other
objects or mobs, such as surgery and health analzyers. Report if
anything seems wrong
/🆑
2023-12-08 23:50:19 -07:00
jimmyl
ef0a98aa85 exodrone travel time balance, grammar, fixes and tweaks (#78378)
Exodrones fixes and balance
2023-09-27 09:24:21 +02:00
zeckle/licks-the-crystal
d0dffe7ca6 Fixes a large amount of spelling and grammatical errors in the Exploration Drones section. Also fixes an angry pine tree quip. (#77095)
## About The Pull Request
Title

## Why It's Good For The Game
It bothered me

## Changelog

🆑 Licks-The-Crystal
spellcheck: Corrected a large quantity of spelling, grammatical and
phrasing errors with Exploration Drone content.
/🆑

---------

Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
2023-07-31 12:18:45 +00:00
Helg2
c9749aa416 Adds already existing circuits to exodrone consoles. (#76826)
Consoles for exodronning didn't have circuits so you couldn't unscrew
and move them or similar.
2023-07-15 16:21:28 -04:00
LemonInTheDark
ae5a4f955d Pulls apart the vestiges of components still hanging onto signals (#75914)
## About The Pull Request

Signals were initially only usable with component listeners, which while
no longer the case has lead to outdated documentation, names, and a
similar location in code.

This pr pulls the two apart. Partially because mso thinks we should, but
also because they really aren't directly linked anymore, and having them
in this midstate just confuses people.

[Renames comp_lookup to listen_lookup, since that's what it
does](102b79694f)

[Moves signal procs over to their own
file](33d07d01fd)

[Renames the PREQDELETING and QDELETING comsigs to drop the parent bit
since they can hook to more then just comps
now](335ea4ad08)

[Does something similar to the attackby comsigs (PARENT ->
ATOM)](210e57051d)

[And finally passes over the examine
signals](65917658fb)

## Why It's Good For The Game

Code makes more sense, things are better teased apart, s just good imo

## Changelog
🆑
refactor: Pulled apart the last vestiges of names/docs directly linking
signals to components
/🆑
2023-06-09 06:14:31 +00:00
san7890
ccef887efe Lints Against Unmanaged Local Defines (#74333)
# MAINTAINER - USE THE BUTTON THAT SAYS "MERGE MASTER" THEN SET THE PR
TO AUTO-MERGE! IT'S MUCH EASIER FOR ME TO FIX THINGS BEFORE THEY SKEW
RATHER THAN AFTER THE FACT.

## About The Pull Request

Hey there,

This took a while to do, but here's the gist:

Python file now regexes every file in `/code` except for those that have
some valid reason to be tacking on more global defines. Some of those
reasons are simply just that I don't have the time right now (doing what
you see in this PR took a few hours) to refactor and parse what should
belong and what should be thrown out. For the time being though, this PR
will at least _halt_ people making the mistake of not `#undef`ing any
files they `#define` "locally", or within the scope of a file.

Most people forget to do this and this leads to a lot of mess later on
due to how many variables can be unmanaged on the global level. I've
made this mistake, you've made this mistake, it's a common thing. Let's
automatically check for it so it can be fixed no-stress.

Scenarios this PR corrects:

* Forgetting to undef a define but undeffing others.
* Not undeffing any defines in your file.
* Earmarking a define as a "file local" define, but not defining it.
* Having a define be a "file local" define, but having it be used
elsewhere.
* Having a "local" define not even be in the file that it only shows up
in.
* Having a completely unused define*

(* I kept some of these because they seemed important... Others were
junked.)
## Why It's Good For The Game

If you wanna use it across multiple files, no reason to not make it a
global define (maybe there's a few reasons but let's assume that this is
the 95% case).

Let me know if you don't like how I re-arranged some of the defines and
how you'd rather see it be implemented, and I'd be happy to do that.
This was mostly just "eh does it need it or not" sorta stuff.

I used a pretty cool way to detect if we should use the standardized
GitHub "error" output, you can see the results of that here
https://github.com/san7890/bruhstation/actions/runs/4549766579/jobs/8022186846#step:7:792
## Changelog
Nothing that really concerns players.

(I fixed up all this stuff using vscode, no regexes beyond what you see
in the python script. sorry downstreams)
2023-03-29 10:17:03 -07:00
Mothblocks
fa7688d043 Save 0.6-0.7s of init time by splitting registering lists of signals into its own proc, and optimizing QDELETED (#71056)
- Makes QDELETED use isnull(x) instead of !x, giving about 0.2 to 0.25s
of speed.
- Make disposal constructs only update icon state rather than go through
expensive overlay code. Unfortunately did not have much effect, but is
something they should've been doing nonetheless.
- Makes RegisterSignal only take signals directly as opposed to
allocating a fresh list of signals. Very few consumers actually used
this and it costs about 0.4s. Also I think this is just a bad API anyway
and that separate procs are important

`\bRegisterSignal\((.*)list\(` replaced with `RegisterSignals($1list(`
2022-11-22 07:40:05 +00:00
ShizCalev
9dab26371c Throws a bunch of parenthesis around to ensure dear Aunt Sally is always properly excused. (#71281)
Similar vein to #37116

This is supposed to be standard, yet here we are.

SHOULDN'T change anything, but there's likely something out there that's
bound to behave different because of it.


These were done manually, regex to find things that MIGHT need to be
corrected;
`^#define.+\+((?!\)).)*$`
`^#define.+-((?!\)).)*$`
`^#define.+\*((?!\)).)*$`
`^#define.+\/((?!\)).)*$` (yeah that's a lot of stuff.)
`^#define.+%((?!\)).)*$`
`^#define.+SECONDS((?!\)).)*$`
`^#define.+MINUTES((?!\)).)*$`
2022-11-21 20:53:06 -08:00
AnturK
4d6a8bc537 515 Compatibility (#71161)
Makes the code compatible with 515.1594+

Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword

And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.

@tgstation/commit-access Since the .proc/stuff is pretty big change.

Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
2022-11-15 03:50:11 +00:00
Ghilker
ffd1ae5fc0 Rebalanced Power consumption, increase for machines (#66059)
Machinery power consumption rebalance.
2022-04-20 09:50:54 +02:00
John Willard
2db00c7dc5 standardizes default unfasten wrench (#65425)
I'll do more in the future but I'll limit myself to this because I'm tired, bored, and don't want to make so many PRs touching the same things that I have to deal with conflicts each time one is merged.
Just as an example, screwdriver's gotta be done as well, does the exact same thing wrenches do, I believe.
Standardizes (and touches) each time default_unfasten_wrench is used.

Fixes tool logs, since it relies on tool acts to exist, I'm trying to move as many tool acts to its proper proc. Like a spiritual successor to the tool superpack PRs.

Co-authored-by: Luc <89928798+lewcc@users.noreply.github.com>
2022-04-04 12:44:14 -07:00
tralezab
6c01cc2c01 every case of initialize that should have mapload, does (#61623)
## About The Pull Request

stop forgetting to include mapload, if you don't include it then every single subtype past it by default doesn't include it

for example, `obj/item` didn't include mapload so every single item by default didn't fill in mapload

![](https://media.discordapp.net/attachments/823293417186000909/875122648605147146/image0.gif)

## Regex used:

procs without args, not even regex

`/Initialize()`

procs with args
`\/Initialize\((?!mapload)((.)*\w)?`

cleanup of things i didn't want to mapload:
`\/datum\/(.)*\/Initialize\(mapload`
2021-09-24 17:56:50 -04:00
Kylerace
740a471dbb large refactor of machine/power code to cut down on processing time and wasted lists (#60317)
original pr here: #59789 (Closed because he didn't think it was good enough)
came back to this because i realized that

    all machines were area sensitive, meaning they had a list with at least a reference to themselves (assuming they arent in the contents of another movable which most arent) for the purposes of handling power differences when their area changes
    pipes are machines
    there are ~14k machines and ~6k pipes
    i made this problem worse with a recent pr by making it a nested list

so i needed to track what machines needed power, and this pr had work already done that could be used for that purpose. now machines that have use_power == NO_POWER_USE do not have this extra memory overhead for no reason

currently every machine that uses power draws that amount from its area from a dynamic channel via auto_use_power() which is called every SSmachines fire(), then in apc/process() the area's dynamic power draw is reset and the power is used. with static power its not calculated then reset every loop, its just taken from the grid. so now machines handle updating their static power usage from their current area (this doesnt touch power machines that require a wire connection). in order to allow this, use_power, idle_power_usage, and active_power_usage have setters to track state correctly and update the static power usage on the machines current area and handle area sensitivity.

also goes through a lot of heavy abusers of SSmachine processing time and tries to make it faster. makes airalarm/process() into a signal handler for COMSIG_TURF_EXPOSE since air alarms only need to process for changes.
Why It's Good For The Game

SSmachines isnt the heaviest hitter in terms of total cpu and certainly not in terms of overtime, but its not a lightweight. it frequently takes > 50ms to complete a run and seems to be in the top 5 or so of subsystem costs looking at some round profilers

also gets rid of a few thousand lists since every pipe no longer has two useless lists each (and any other machines that dont use power)

Love ya kyler

Co-authored-by: Rohesie <rohesie@gmail.com>
2021-09-01 18:10:47 -07:00
Kylerace
e13fe75590 use SIGNAL_HANDLER REEEEEE (#59242)
makes as many procs as i can find use the SIGNAL_HANDLER define which i assumed they all already did
2021-05-24 15:28:02 -04:00
AnturK
8b1ffd1e49 Adds explorer drones / adventures. (#57851)
A new side-job for cargo. Prepare and launch exploration drones at distant sites to encounter weird adventures, collect loot and expand the station cargo network. Adventures - the main content type here, can be written by anyone without any knowledge of programming. The purpose here is creating an way of interesting way of delivering lore (and adding some new job content/cargo expansion method).

Co-authored-by: tralezab <40974010+tralezab@users.noreply.github.com>
Co-authored-by: EOBGames <58124831+EOBGames@users.noreply.github.com>
Co-authored-by: Fikou <piotrbryla@onet.pl>
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
2021-03-26 11:38:39 +02:00