You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
local p = c.get_logistic_point(defines.logistic_member_index.character_requester)
99
-
if not p then return end
100
-
101
-
-- Ok we can do it.
102
-
end)
103
-
```
104
-
105
-
Where the conditions return early if there is nothing to be done. My preference is for the latter pattern because it
106
-
avoids the indent "waterfall". But in any case, the problem here is that these are in event handlers by themselves.
107
-
108
-
What we want to do is get off the fun names to systemic names, and then collapse these. The proposed scheme is
109
-
`fa-[cas]-key` for example `fa-c-leftbracket` is ctrl + leftbracket, `fa-j` is just j, etc. The cas are "bitflags" and
110
-
always specified in that order (none for no modifiers, `c` is control, `a` alt, `s` shift). A single prototype per key
111
-
combo covers all others that were on the key, so we drop those. Then we can perform a mostly mechanical transformation,
112
-
just far enough out that the AI can't quite do it:
113
-
114
-
```
115
-
script.on_event("old1", function(event)
116
-
if condition1 then
117
-
-- do it
118
-
end
119
-
end)
120
-
121
-
122
-
script.on_event("old2", function(event)
123
-
if condition2 then
124
-
-- Do it
125
-
end
126
-
end)
127
-
```
128
-
129
-
Would become:
130
-
131
-
```
132
-
local function kb_old1(event)
133
-
-- Code without the condition
134
-
end
135
-
136
-
local function kb_old2(event)
137
-
-- Code without the condition
138
-
end
139
-
140
-
script.on_event("fa-newkey", function(event)
141
-
if condition1 then kb_old1(event)
142
-
elseif condition2 then kb_old2(event) end
143
-
-- If we fall off the end that's fine to do nothing.
144
-
end)
145
-
```
146
-
147
-
Which ensures that only one of them runs per press. the `kb_` prefix is kind of literal, just to let us know "this is a
148
-
block of code from the keyboard", and indeed for smaller ones (e.g which already call out to a module) not having the
149
-
intermediate function is fine. You will want to pass the event around for now rather than deconstructing at the top,
150
-
and annotate:
151
-
152
-
```
153
-
---@param event EventData.CustomInputEvent
154
-
```
155
-
156
-
Note the following:
157
-
158
-
- We genuinely don't know the old order. Bias UI/menu conditions toward the top but other than that it's ambiguous and
159
-
we don't care right now because getting this far will let us see if that ever matters, since overlapping/wrong-order
160
-
conditions won't both trigger anyhmore.
161
-
- Control.lua has a ton of code duplication. For now that's out of scope, because most of it is being moved to modules
162
-
and doing so was blocked by input being a problem. For instance the menu_up/menu_left/etc. functions are very clearly
163
-
*almost* but not quite duplicates that could be "fixed", except new UI framework wants to just plug in.
164
-
- That said, don't add more if it's easy to avoid. If it's not easy to avoid, shrug.
165
-
- testing is a pain. It's fine to break stuff. The only real test is "play a full run of the game". So do your best
166
-
but don't freak out over that, no judgement as long as like really basic stuff works.
167
-
- Lua function order matters. Callees must be declared before callers when using the `local function` syntax.
168
-
- Feel free to be rid of any obvious dead code.
169
-
- Feel free to mark things which are local to control.lua as locals if you find any, though going after them is out of
170
-
scope; it's a self-resolving problem down the road.
171
-
- linked_game_control and consuming are "union". if any of the old prototypes has them the resulting prototype should
172
-
get them. It happens that such a transformation shouldn't change observable behaviors.
173
-
- What to do about things like page up which don't exist on laptop keyboards is a tbd question for now. Feel free to
174
-
punt it.
175
-
- Alternate key mappings get dropped.
176
-
- Prototypes which are only modifiers, if any, can be dropped. They weren't the greatest idea in the first place, but
177
-
they're for scanner and there are other keys already.
178
-
- There are other prototype kinds in data.lua, just leave those alone.
179
-
- To "execute" a lua file, `require('otherfile)` without assigning it to anything.
180
-
- trains will come up. If possible preserve their key handlers. You can't test those. If it's unclear where it should
181
-
go in the handling, put it in the else branch for now. Mostly these are being kept for documentation.
182
-
183
-
Concretely I recommend doing it like this. There's other ways but this is what I'd do:
184
-
185
-
- Make data/input.lua and require it from data.lua.
186
-
-`data:extend { ... }` in it so you can start moving prototypes over.
187
-
- Find the first prototype in data.lua that's an input and make the new prototype.
188
-
- Write down all of the others from data.lua that match it and delete them from data.lua.
189
-
- Go find all the event handlers in control.lua and cut them to another file (cut, not copy).
190
-
- Paste that other file back into control.lua at the bottom.
191
-
- Deal with that set.
192
-
- Repeat until done.
193
-
194
-
## Heat Pipes
195
-
196
-
We need a module for heat pipes like the module for fluids. The differences are that heat pipes don't have fluidboxes
197
-
or underground connections. Like this:
198
-
199
-
- Refactor the shape logic in fa-info and fluids.lua to be abstract enough to give you the shape of a pipe when it's not
200
-
a real fluid pipe.
201
-
- Write a function which can find all heat connections on an entity.
202
-
- Special case heat pipe itself in this to always have one connection.
203
-
- When on an entity over a heat connection probe one tile in all directions to find other entities, and check if you landed on one of their heat connections.
204
-
- It looks like floats would be an issue here but all floats for heat connections are 0.5, e.g. direct equality tests actually work out.
205
-
- Heat pipes aren't an exception, save that their heat connection is sort of faked out.
206
-
- If it is a heat pipe, grab all other adjacent heat pipes and build the shape, then announce what it connects to that's
207
-
not a heat pipe, e.g. "heat exchanger at south". Fluid code already does this, so you might be able to make it
208
-
somewhat generic again.
209
-
210
-
In 2.0 base your entities for heat are nuclear reactors and heat exchangers. Space age adds a bunch more. To determine
211
-
if an entity "participates" in heat, it is sort of enough to just find out if it has a heat connection. The only
212
-
exception to that is aquilo which we will handle later because it's not something that fits in this module (indeed it
213
-
may already work). Entities which participate in heat need to have their temperature read. Code for this already
214
-
exists in fa-info but it may not extend to Space Age entities due to special casing off prototype types.
215
-
216
-
## Aquilo iceberg scanner backend
217
-
218
-
there are a lot of things to do with scanner that we can work on but probably the easiest is aquilo icebergs. There
219
-
isn't much in this document because scanner is fully documented in devdocs/scanner.md. In practice such a backend is
220
-
just an inversion of the water one, e.g. a different tile set. Don't be fooled by the resource scanner using the
221
-
spatial hashes, which is sort of legacy; that can go in favor of tile-clusterer as well, but there's no pressing need to
222
-
rewrite so we haven't.
223
-
224
-
## Test Larger Cursors on Gleba
225
-
226
-
This is an easy one maybe. Make a large cursor and move it over gleba and see how it crashes horribly. Hopefully it
227
-
doesn't. If it does we will discuss what work needs to be done.
228
-
229
34
## Script to do Releases
230
35
231
36
This needs some scoping but since we have the spare slack it'd be a good idea. What we know wrt the flow:
0 commit comments