Jozzo

joined 1 year ago
[–] Jozzo@lemmy.world 38 points 1 month ago (8 children)

Got hit with this in the middle of work. We only have one customer using CrowdStrike, and only staff PCs, no infrastructure. But this one is REAL bad, caused by turning your PC on, and cannot be patched - each affected PC needs to be manually fixed. Would not be surprised to see Linux usage go up after this.

[–] Jozzo@lemmy.world 17 points 2 months ago (9 children)

One attendee and the shooter are dead

 

On June 29, 2024, at 6:30 P.M. Pacific Time, Roll20 learned that an administrative account was compromised. By 7:30 P.M. Pacific Time, we acted to ensure that all unauthorized access was blocked, and we began the process of investigating the incident to determine the scope.

Following our investigation, we learned that the unauthorized third-party had access to administrative tools, which may have resulted in the exposure of personal information, such as your: first and last name, email address, last known IP address, and the last 4 digits of your credit card (solely if you had a stored payment with us).

Notably, the compromised administrative tooling did not expose your password or your full payment information, such as your address or credit card number.

While we have no reason to believe that your personal information has been misused, we are notifying you out of an abundance of caution.

We take your privacy and security very seriously, and we deeply regret that this incident occurred. We will be implementing an action plan to further enhance the security of our administrative tools going forward.

If you have questions, or if you would like to view a copy of your account data that the third party may have had access to, please reach out to us at https://help.roll20.net and create a support ticket with the subject line “Incident Data Request” and we will be happy to assist you.

Here are some resources containing good best practices for protecting your information online which we recommend: https://consumer.ftc.gov/online-security

[–] Jozzo@lemmy.world 5 points 2 months ago

It depends entirely on the company you work for. Even then, I wouldn't exactly describe the work as "chill"

[–] Jozzo@lemmy.world 2 points 2 months ago

I patched together some version of this using nested dictionaries:

var abilities: Dictionary = {
	AbilityData.Trigger.BEFORE_ATTACK : {},
	AbilityData.Trigger.ON_ATTACK : {},
	AbilityData.Trigger.ON_HIT : {},
	AbilityData.Trigger.ON_KILL : {},
	AbilityData.Trigger.ON_DEATH : {},
	AbilityData.Trigger.ON_JUMP : {},
	AbilityData.Trigger.PASSIVE : {}
}

with each value being another key:value pair of { "ability_id": <ability-node> } so I can keep a reference to the Ability node and use dictionary functions like .has() to check if a character has a specific ability:

func has_ability(ability_data: AbilityData) -> bool:
	if abilities[ability_data.trigger_type].has(ability_data.id):
		return true
	return false

Then when a trigger fires, it calls this (I omitted the return code):

// Activates all abilities with the specified trigger type. Returns an array containing each ability that was activated this way.
//trigger_type is an enum
//data is just a resource containing things like position, target, ability owner, etc
func trigger(trigger_type: AbilityData.Trigger, data: AbilityActivationData) -> Array[Ability]:
	var abilities_to_activate: Dictionary = abilities.get(trigger_type)
	
	// Loops through the list of Ability nodes.
	for ability in abilities_to_activate.values():
		ability.activate(data)
		abilities_activated.append(ability)

This seems to work, but it still gives me that tickling sensation that it could be a little cleaner.

[–] Jozzo@lemmy.world 1 points 2 months ago (1 children)

I think I understand...

Instead of the player iterating through and calling all of its abilities, the ability just connects directly to whichever signal it needs on the player?

My current setup is to add each Ability as a node to the player, so right now it follows the "call down, signal up" adage that I hear everyone say. What would be a good way to implment the other way? I assume I should rework my current setup otherwise it'd be "signal down, signal up"?

 

For character abilities that have a certain trigger condition, eg. "OnAttack", "OnJump", "OnDamaged" etc..

Currently each of these triggers is a signal. When a signal fires, the character loops through all of its abilities and activates each one with that specific condition, so it just runs an if statement for every ability, regardless of whether it has that condition or not:

if ability.trigger_condition == Triggers.OnAttack:
  ability.activate()

My issue is that this could get a little unscalable with many characters on-screen each having many abilities of their own. A character could have 1 OnDamaged ability and 19 OnAttack abilities, but when an "OnDamaged" signal is received, it will still loop through all 19 OnAttack abilities.

Any advice on this is appreciated, thank you all.

[–] Jozzo@lemmy.world 2 points 3 months ago (1 children)

Win11 doesn't let you past setup if you dont have an internet connection.

[–] Jozzo@lemmy.world 1 points 6 months ago

Thanks for your input! The other commenters pointed out that I can use Godot's is_instance_valid() function to check if the bullet's owner exists before attempting to call anything on it, so will be reworking the system to use #2 + that.

[–] Jozzo@lemmy.world 1 points 6 months ago

Definitely sounds like the way to go the more I think about it. Thanks!

[–] Jozzo@lemmy.world 3 points 6 months ago

The longer I'm using the signal chain the more I'm wanting to rework it to just be a reference lol. Good point with checking if the instance is valid, if any other errors come up I could just patch around them in a similar fashion.

That said, you can probably simplify your signal code if you connected the bullet killed_enemy signal directly to the player’s on-hit handler. It seems like the weapon on-kill handler is redundant?

Ah I see what you mean, killed_enemy(enemy-object) signals directly to the player which can then pass that enemy to it's abilities if needed. You're correct that the weapon signal is mostly redundant, it was just the easiest node to connect to the bullet's signals, as it's responsible for spawning them.

I think I'll change the whole system to just use a reference. Thanks for your input!

 

Wanted some opinions on ways to set up triggering "on-kill" effects. In short: The player can have abilities that trigger effects whenever they shoot and kill an enemy. I'm also looking to extend abilities to enemies as well, so can't just hardcode a player reference.

Currently I'm doing it like this:

  • Enemy signals that it died -> the bullet receives this and signals that it killed Enemy -> the player's weapon receives this and signals that it's bullet killed Enemy -> the player receives this and triggers it's on-kill abilities.

It simultaneously feels like a good way to go about it but also a long mess. The other option I've considered is:

  • Each bullet has a reference to it's owner (eg. player). When an enemy dies to a bullet, it looks to the bullet's owner reference and tells it to trigger it's on-kill effects.

This way is a lot simpler to write, but is error prone eg. In cases where the bullet's owner is killed while their attack is mid-air.

Thank you all!

 

Figured I'd share this project as I don't see many that know about it! (Only available for Windows)

 

A massive asset bundle by Kenney is free right now on itch.io. It's only available for 9 more hours as of posting.

All included assets can be previewed here: https://kenney.nl/data/itch/preview/

Includes 2D, 3D, and audio assets!

[–] Jozzo@lemmy.world 2 points 7 months ago

You're probably right, but it's an alternative for people who don't.

 

For those that have never heard of it, PlanarAlly is an open-source self-hosted virtual tabletop (VTT) for TTRPG games. Here I've compiled the most important features/changes from their blog post. The full release notes are available on their GitHub: https://github.com/Kruptein/PlanarAlly/releases/tag/2024.1

Vision Blocking Update

A new vision blocking mode is introduced, called behind. It will accompany the existing vision mode which will be renamed to complete.

When behind mode is active, the shape marked as vision blocking will be rendered as if it’s not a vision blocking shape, but everything behind it will be fully obscured. This will for example allow you to have a tree trunk that is vision blocking, but still show the players what they are looking at (i.e. a tree trunk).

Notes Overhaul

There is no longer a difference between shape notes and campaign notes. Notes are now a single concept, can be attached to shapes and managed through a new UI element called the Note Manager.

It’s now possible to share certain notes to other users with granular access rights, eg. you can give view access to all players when they retrieve an item, or give a particular player a private note that only they can view and edit.

For a full overview of the new note system, check the notes documentation.

Asset Drop Ratio

Defines how assets should be scaled when dropped on the map. A drop ratio of 1 is the default, it means the asset will resize purely on it’s specified dimensions, eg. goblin_1x1 will take up 1 grid cell even if it represents 10ft, whereas a drop ratio of 0.5 will resize basilisk_2x2 to 1x1.

Context: Previously, assets would auto scale when dropped onto the grid if they have a dimension in their name, eg. goblin_1x1 would fit exactly 1 grid cell, dragon_3x3 would be resized to 3 by 3 grid cells. This was using a method based on the 5ft-system to automatically adjust this when a location had a bigger size (eg. 10ft maps would automatically make goblin_2x2 fit in 1 cell). This however would break anything that wasn't using the 5ft-system.

Dice History Improvements

The dice history will now show who rolled the dice (it was previously only shown on hover) and contains more details on the specific roll instead of only showing the final result.

[–] Jozzo@lemmy.world 13 points 7 months ago (1 children)

Just tried this out in one of my projects, here's what happened:

  • do something works without a problem.
  • do something else never goes off.
  • the rest of the game keeps running as normal. You can even call foo() again any number of times and do something will still go off.

Having it waiting in the background didn't seem to have much of a performance impact. I started 5000+ of them and foo() only took up ~0.6% frametime with the rest of my game running alongside it.

[–] Jozzo@lemmy.world 5 points 1 year ago

PlanarAlly is a pretty cool self-hosted VTT.

view more: next ›