Quickbar shortcut unlocks?

[Deadlock989]

Run across something that has me really puzzled, think there's a gap in my knowledge. I've worked with new shortcut prototypes before but whether they are enabled or not is controlled by script, not by technologies.

In vanilla, when you unlock construction bots, some things are handled by the unlock effects - the bot recipes, the ghost timeouts. But if you want to unlock a quickbar shortcut as well, that's a property of the shortcut's prototype, technology_to_unlock, not the technology.

All the ghost-building-related shortcuts are all set in data.raw (at least they were a few versions ago) to be unlocked by "construction-robotics", which makes total sense. However when I test the game with no mods installed, I'm finding that they are all unlocked anyway - cut, paste, copy, blueprint, blueprint book, upgrader, decon. The only exception seems to be "undo".

I mean, there's nothing wrong with that behaviour, makes total sense, why not have players work with blueprints from the start - they can revive ghosts too. But that's not what the prototypes are saying. What am I missing?

I have another dilemma where I need two different technologies to unlock the personal roboport toggle shortcut, but ideally those technologies wouldn't have a dependency relationship, and the property can only can only specify one technology. Will probably just unlock it at game start unless there's a better way.

[eradicator]

Ran into this myself before. The unlock status of shortcuts is stored in player-data.json, and is thus persistant across all savegames. That means when it's unlocked (by technology or script doesn't matter) *once* in any map you play, it is thereafter available on *any* other map.

As i needed a shortcut that is *only* available when the technology is reserached on *that specific map* i had to manually implement that behavior using on LuaPlayer.set_shortcut_available() etc. Which allows me to make shortcuts unclickable, but i don't get any control over the position of the button ofc (nor do i need to). So if a player unlocked it and selected it to be visible it'll still be there on any other map.

[eradicator]

I have another dilemma where I need two different technologies to unlock the personal roboport toggle shortcut, but ideally those technologies wouldn't have a dependency relationship, and the property can only can only specify one technology. Will probably just unlock it at game start unless there's a better way.

You could use the "nothing" technology effect to give the user a visual clue+description, and then unlock the shortcut manually via script.

[Deadlock989]

Ran into this myself before. The unlock status of shortcuts is stored in player-data.json, and is thus persistant across all savegames. That means when it's unlocked (by technology or script doesn't matter) *once* in any map you play, it is thereafter available on *any* other map.

Ohhhh. That's ... unexpected.

Thanks for the tip-off.

[Deadlock989]

This is what I did in on_research_finished to "double up" any shortcut unlocks, if you want to have more than one tech unlock a shortcut but you don't want them to depend on each other:

Code: Select all

if event.research and event.research.name == "[secondary tech id goes here]" then
	for _,player in pairs(event.research.force.players) do
		for _,shortcut in pairs(game.shortcut_prototypes) do
			if shortcut.technology_to_unlock == "[prototype tech id goes here]" then player.set_shortcut_available(shortcut.name,true) end
		end
	end
end

Turns out the reason the "undo" button wasn't being activated was because ... I hadn't built anything

[eradicator]

Code: Select all

if shortcut.technology_to_unlock == "[prototype tech id goes here]" 

That looks as if your're not checking if the "first" tech is actually researched.

Here's a more generic solution:

Code: Select all

/c
local function unlock(force,condition,shortcut)
  for t,_ in pairs(condition) do if not force.technologies[t].researched then return end end
  for _,p in pairs(force.players) do p.set_shortcut_available(shortcut,true) end
  end

script.on_event(defines.events.on_research_finished,function(e)
  local unlocks = {
    [{['tech1']=true,['tech2']=true}] = 'shortcut_name',
    }
  for t,s in pairs(unlocks) do 
    if t[e.research.name] then unlock(event.research.force,t,s) end
    end
  end)

Ofc this'll still be a permanent unlock. And most people probably already have it unlocked from vanilla freeplay anyway ^^.

[Deadlock989]

Code: Select all

if shortcut.technology_to_unlock == "[prototype tech id goes here]" 

That looks as if your're not checking if the "first" tech is actually researched.

Doesn't need to be. This is for two different researches that are a mile apart in the tree, but they both need to unlock the quickbar buttons.

[eradicator]

Code: Select all

if shortcut.technology_to_unlock == "[prototype tech id goes here]" 

That looks as if your're not checking if the "first" tech is actually researched.

Doesn't need to be. This is for two different researches that are a mile apart in the tree, but they both need to unlock the quickbar buttons.

Hm...how does that even work anyway. If the shortcut prototype defines a tech to unlock, then that tech will unlock the shortcut on its own. So...that's not a valid solution to the "must unlock only when both techs are researched" if the techs can be researched in any order. I'm missing some piece of the puzzle here. But as long as it works for you...

[Deadlock989]

that's not a valid solution to the "must unlock only when both techs are researched"

That wasn't the issue. Probably wasn't clear what it was I wanted.

Tech A is the one defined in all the shortcut prototypes as the unlocking tech. So it doesn't need any manual intervention.

Tech B is some other tech. It doesn't depend on Tech A, Tech A doesn't depend on it.

Both of them individually need to unlock the quickbar if researched. Either one, not both.

[eradicator]

Either one, not both.

Ah, that is a different problem than i understood :). Can you not simply add the tech_to_unlock to *both* of them then though?

[Deadlock989]

Ah, that is a different problem than i understood . Can you not simply add the tech_to_unlock to *both* of them then though?

No, because as mentioned in the OP, the tech_to_unlock property isn't in the tech. It's in the shortcut prototype. It's a string, not a table, so it can only "point to" one tech.

[eradicator]

Ah, that is a different problem than i understood :). Can you not simply add the tech_to_unlock to *both* of them then though?

No, because as mentioned in the OP, the tech_to_unlock property isn't in the tech. It's in the shortcut prototype. It's a string, not a table, so it can only "point to" one tech.

Hrng, yes, ofc. Scattered mind syndrome :D. At least it works now.

(Unrelated: I saw some guy who describes what sounds like a bug in IR.)