#Only been playing factorio for a few

1 messages · Page 1 of 1 (latest)

novel juniper
#

Ideally normal lamps/lights would also negate the penalty if the enemy is illuminated, but that can be skipped if too hard.

Also, if I can include the player in the penalty/buff nightvision should also remove the range debuff from the player, too.

dapper phoenix
#

If Searchlight Assault gives a buff, then it's probably possible to give a debuff to things.

Just look into the code of Searchlight Assault to figure out how it does things, and then tweak it to basically do the inverse

novel juniper
#

IDEALLY IDEALLY
Instead of just being binary "is day/night?" I can just use overall light level, which seems like what solar panels do?

cerulean mangoBOT
#
LuaSurface::darkness

[R] :: float
Amount of darkness at the current time, as a number in range [0, 1].

dapper phoenix
#

There's also a daytime for use in time of day if need be

#

And in regards to turrets, I don't actually know
My gut says you'll have to affect every single turret individually, but there's also team buffs from technology

#

Either way, you'd probably want to only affect the turrets on a single surface when that surface gets too dark

#

It may not matter as much right now with 1.0, but with SA using it, it'll probably actually matter

novel juniper
#

True

novel juniper
#

Looking through SLA it looks like it has each light, when it activates boost look for all nearby objects that contain ammo and swap the ammo out for a new "boosted" ammo, and then swap it back when the boost is over.

Seems pretty kludgy.

#

Has a lot of safety checks to make sure the player doesn't design a way to get boosted ammo out of the area before the light can un-boost it to keep boosted ammo permanently.

dapper phoenix
#

Honestly sounds about right..

#

Modifying anything that you would define in a prototype tends to be pretty complicated

novel juniper
#

So, if I wanted to do what I wanted, I'd probably need to do something like:

  1. onTick on each surface check light level
  2. find all ammo on that surface
  3. (if not wearing nightvision, or otherwise immune) swap all ammo out with new light-adjusted ammo

Then, to apply "target iluminated" bonuses, I'd need to check if anything is actively shooting (I don't see like, an "onShoot" or "onAttack" event) and

  1. find their target
  2. check if the target is within a certain radius of a light/lamp, or currently targeted by a searchlight
  3. if so - swap their ammo out for normal ammo
#

That has nasty possible problems like in SE being able to move ammo on/off surface to retain boost/unboost properties. think

#

This would be best if I could find some onShoot method and just check surface light, and target illumination directly before the shot is fired.

dapper phoenix
#

I think turrets have Triggers for making the little bullet casing particles
You can make a script trigger in that, but I'm pretty sure it happens with the shooting and not before it

#

And it wouldn't give any information like who it's shooting afaik so you couldn't fake it by just damaging the biter more

novel juniper
#

I did see turrets have a "shooting Target" member that' R/W, but again, I'd need to know when they want to shoot

dapper phoenix
#

I don't know exactly how inserters/turrets behave, but if you add an extra slot for ammo you might be able to get away with only transforming the ammo within the turret
The inserter could insert into the other slot when it's low and then you'd come along a few ticks later and notice some of the wrong ammo and convert it and merge it into the initial stack

novel juniper
#

IIRC SLA just checks any entity with an inventory 4 units away from any turret and sees if it has any boost ammo and swap it back for normal ammo

#

There's also find_nearest_enemy, but doing a find nearest on every turret and player on every surface every tick also seems crazy

dapper phoenix
#

I'm thinking more about how you would go about downgrading ammo in every turret but not downgrading literally every ammo piece
And with this method, you could just not downgrade it if it's in the range of a searchlight

#

But yeah, I wouldn't be surprised if no matter what you do, it'd be kinda ups expensive

#

If you're willing to go mult-surface unsafe, you can just enable/disable a hidden research to use the technology effects to do it

#

And just choose a downgrade that directly blocks the boost searchlight does

novel juniper
#

I think SLA gets around it by the fact that the light 'links' to SPECIFIC turrets and only boosts those.

I think if it did more, or if you built a ton of lights + a ton of turrets, it'd probably be hell on UPS

#

I think looking at what's exposed by the game, I don't see a 'good' way to accomplish what I want, sadly. There's possible some super kludgy UPS-murdering ways with that would be fragile and possibly exploitable... but that doesn't seem worth it.

dapper phoenix
#

Oh if you want to make the technology hack multi-surface safe

#

You can just change the force of players nvm remote view would probably counter-act that

#

Unless you can tell that the player is looking at another surface

#

Which you probably can. Especially as you can get which entity the player currently has selected (hovered with their mouse)

#

And I wouldn't be surprised if a api request is written for an event on switching surfaces in person or in remote view

novel juniper
#

There's on_player_changed_surface

I didn't see the way to detect the player's hovered entity though?

#

I see on_gui_hover? But that's only gui objects

dapper phoenix
#

And the only reason I think it's writable, is controller support
I could be wrong though

#

I haven't used it myself

novel juniper
#

Oh, does it? Based on reading it, it sounded like it was like.. when you click on something?

#

Like, selecting a train for example

dapper phoenix
#

That would be opened

novel juniper
#

The currently selected entity. Assigning an entity will select it if is selectable, otherwise the selection is cleared.

#

I think you may be right based on this one:

update_selected_entity(position)
Select an entity, as if by hovering the mouse above it.

dapper phoenix
#

I think it's talking about this

image.png
#

Oooh

#

Yeah, I think it's writable simply because controllers move by relation to their selected entity

novel juniper
#

What makes this extra fiddly to think about is stuff like the auto-targetting behavior of the SMG and pistol.

You don't have to even select an enemy

dapper phoenix
#

(Also ignore the biter corpses. I simply used the save I used to test a fix on exfret's biter memoirs)

novel juniper
#

So like, if you assume the player is standing with an enemy on the right and another on the left, and one is in the dark and the other in the light, the idea would be even if they're both the same distance away, the one in the dark might be out of range while the one in the light would be in range

#

I honestly don't see a way to do that with the current limitations

#

You could abstract it and base it on the PLAYER being in the light, but that's NOT what I want. 😦

#

I would really need some kind of on_pre_attack event.. and even then it'd probably be super bad for the AI.

Like, when the AI is picking which target to attack, it'd need to know which ones are valid based on range...which would be based on light.

#

I suppose instead of range, maybe you could approximate some 'inaccuracy' by giving enemies in the dark some level of damage mitigation?? think

#

So like... enemies in the dark take 25% less damage or something?

#

That might be easier... let me look into that

dapper phoenix
#

That sounds more impossible to me :/

novel juniper
#

Why? think

dapper phoenix
#

Modifying biter data :)

#

Yeah, looking for resistance only brings up the prototype items

image.png
#

Unless you want to heal the biters that get damaged in the dark

#

That.. that might work

novel juniper
#

I think it may be more easily kludgable though:

  1. on_entity_damaged
  2. check surface light level
  3. look for nearby lights
  4. undo some damage
dapper phoenix
#

yeah

#

That's smarter than I was thinking

#

And you can filter for the type of "unit" since that's what biters are
And I think what basically any entity with any sort of pathing Ai is

#

(I'm basing this off of biter memoirs which I did not write, but I have contributed to)

novel juniper
#

That is assuming the damage doesn't instantly kill the target before the end of tick.
My assumption is something like

  1. damage applied
  2. on_entity_damaged sent
  3. my script heals the target
  4. death is checked

but it might not happen in that order

dapper phoenix
#

I would assume that's a pretty safe bet

#

Simply because that's a thing many people would want to do and it would be api requested to hell and back if it wasn't

novel juniper
#

Looks like you can also set LuaEntityDamagedEventFilter so you only get on damage events from biters

dapper phoenix
#

Yeah, filter for the type "unit"

#

It'll be a little more broad, but it should also include aai tanks and such

novel juniper
#

This one is a little weird:

image.png
#

I might even be able to remove damage before it's actually taken?

dapper phoenix
#

I assume that's because the event data might get out of date if you apply your own damage to it in the middle of the event

#

And it was easy to expose since it already accumulates the damage before dealing it so it could process deaths separately

#

(all assumptions)

novel juniper
#

So, I should be able to

  1. get on_damaged filtered to units
  2. check the source, if the source is immune to darkness (nightvision, etc), return
  3. check damage type, probably ignore flamethrowers and explosive
  4. check around the damaged unit for light sources
  5. create a damage 'rebate' based on the light level & damage type
  6. remove the damage rebate from 'damage_to_be_taken`
novel juniper
#

Confirming this creates invulnerable entities. So that part works.

image.png
#

Not sure what 'pending damage' does, it always seems to be 0, even when it's set. Might have to do with poison or something

dapper phoenix
#

hmm

novel juniper
#

Maybe I'm blind, but is there a quick/easy way to tell if a lamp is powered+on?

dapper phoenix
#

I know lamps kind of turn on a little scattered so I wouldn't be surprised if it's just not exposed to lua

#

Since that to me sounds like shenanigans in the engine that make exposing it non-trivial

#

There are these on the Prototype though

image.png
novel juniper
#

I'm going to just assume that despite visuals any powered non-disabled lamp is 'on', but I need to check if it's disabled

#

There's a disabled but it mentiones disabled by circuit logic specifically

#

Not sure if there's other more generic disable checks

dapper phoenix
#

(since they get turned on at some point in that range)

novel juniper
#

looks like entity.get_control_behavior().disabled

#

disabled is in LuaGenericOnOffControlBehavior which lamp's controller inherits from

#

Going to hope that works as expected

#

then need to check power

dapper phoenix
#

That's very specifically from control Behavior, so I'd be shocked if it responds that it's off

#

I still think your best bet is to check the prototype and rely on it being darker than darkness_for_all_lamps_off as that should be when they start turning on

#

There might be some discontinuity, but I think biters getting hurt more than they should is a lot more fun than not getting hurt enough

#

(I need to go to bed now so have fun)

novel juniper