aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/src/libraries/love.h
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--src/libraries/love.h117
1 files changed, 117 insertions, 0 deletions
diff --git a/src/libraries/love.h b/src/libraries/love.h
index a28872a..f951a89 100644
--- a/src/libraries/love.h
+++ b/src/libraries/love.h
@@ -151,6 +151,7 @@ typedef struct _loveStuffs
151love server starts up 151love server starts up
152 scans sim disk structure looking for scripts in stuffs 152 scans sim disk structure looking for scripts in stuffs
153 keep track of which script is in which stuffs 153 keep track of which script is in which stuffs
154 hashed by stuffs uuid, store pointer to script structure
154 -> LuaSL compile script 155 -> LuaSL compile script
155 -> LuaSL load this saved state 156 -> LuaSL load this saved state
156 -> LuaSL run script 157 -> LuaSL run script
@@ -186,4 +187,120 @@ Extantz client starts up
186 send update nails commands to everyone/thing watching 187 send update nails commands to everyone/thing watching
187*/ 188*/
188 189
190
191/* More thoughts about directory structure
192
193A major goal is to have the disk structure of a sim (and inventory) be
194decently human readable. The assets should be stored as normal files of
195the appropriate type, so that they can be edited with normal editing
196software like blender, gimp, a text editor, etc.
197
198A major LL created problem is that in world objects can have the same
199name, though stuff in an objects inventory is forced to have unique
200names by automatically adding numbers to the names. In inventory you
201can have stuff with the same name to. The same named objects don't have
202to be the same object, they can be completely different. A simple
203object name to file name matching, with directories for contents, just
204wont work. Perhaps the automatic adding of numbers thing would be best?
205All names have to be coerced into operating system friendly names
206anyway, so there still needs to be some sort of mapping between objects
207and their names. Not to mention URL escaping for names to. Try to
208combine both.
209
210Should have a tool to validate a sims files.
211
212Sooo, directory structure of a sim -
213
214"sim name" -> sim%20name
215 index.omg
216 lists objects in the sim, with details about UUID, position, orientation, and size
217 maps in world name <-> file name / URL name
218 actually use file:// style URLs, so that we can pass them to clients,
219 and have the posibility of pointing to assets on some other lspace server
220 the name is a duplicate of what's inside the objects .omg file
221 Should try to keep these in sync automaticallly
222 sim index.omg files are managed by the love server,
223 so fiddling with them outside is an expert thing to do
224 "object name" -> object%20name.omg and a directory called object%20name
225 this file name could also be munged if there are objects with duplicate names
226 an external lspace server would return the .omg file when the objects URL is requested
227 .omg file contains file names / URLs of other assets like actual mesh files and textures
228 also UUID, in world name, description, owner UUID.
229 owner UUID might be better dealt with elsewhere?
230 coz links
231 directory contains the contents of the object
232 index.omg
233 lists the stuffs in the objects contents, with UUID and type for each
234 maps in world name <-> file name / URL name
235 the asset files, plus things like compiled script binaries and temporaries
236 might be better to move compiled scripts and generated Lua source to the LuaSL server's own private store?
237 LuaSL needs to assign UUIDs to compiled script binaries, so it knows which running script is which
238 coz there might be lots of copies of scripts
239 on the other hand, each copy is uniquely named inside some objects contents,
240 even if it's a link,
241 so the UUID of the stuffs plus the UUID within the stuffs contents, for this copy / link of the script should suffice?
242 except links
243
244Yes, this means that files and directories can be links in the case of duplicate assets.
245 Though the UUIDs inside .omg files would have to be unique?
246 Only for script binaries I think.
247 Would have to do copy on write for editing and other state changes, not including script state changes.
248 So links to object .omg files would all have the same UUID.
249 Which works well with using sha-1 content addressable assets. B-)
250
251People could even be free to use their own organising directory
252structure. A directory for ground level, and one for each sky box for
253instance. Relative paths inside .omg files sorts that all out.
254
255Actually, file names / URLs in .omg files would mostly be relative to
256the file name / URL of the sim, and all the way down, so relative to the
257directory things are in. It's up to the client to keep track of where
258they are and build appropriate full URL / full path file names.
259
260A sims index.omg file might be constantly updated for busy sims.
261 Could generate it on the fly by the lspace server, based on the actual contents of the sim directory.
262 Alternative lspace servers could just use a CMS system for all of this anyway.
263 They would still use the same structure for URLs and .omg files.
264
265Storing avatars in this way isn't such a good idea?
266 Avatars could have their own index.omg dealing with shape, skin, clothes, attachments, etc.
267 But instead of client asking for a list, avatar arrivals and departures are driven by love.
268 Though try to keep avatars as "just ordinary object, but with a person controlling it".
269 Still, they move around a lot.
270
271Right now I'm using Lua style .omg files, but eet would be a better
272choice I think. Saves having to write a Lua table to C structure
273system, which eet already has, sorta. Lua tables are at least more
274readable while I consider the design, but likely use eet instead when I
275have to write code to read the suckers.
276
277Might be useful to have a UUID -> asset file .cache directory, or
278something similar? Could save love server needing to keep that all in
279memory all the time. Plus, an issue with using sha-1 UUIDs and keeping
280them inside the .omg files is that this changes the sha-1 hash. Should
281think about keeping uuid's outside of them. Perhaps a .sha1 file along
282side each .omg file and asset file? Don't bother with links, if an
283asset is a link, just look for the .sha1 file where the real file is.
284The UUIDs are mostly for keeping in memory as keys to stuff, coz they
285can shrink down to a long. On the other hand, duplicated objects still
286need their own UUIDs to refer to each copy / link. Sha-1 the relative
287path to the link? It all gets trickier when assets are on different
288lspace servers, not to mention some OSes don't support links very well,
289or at all.
290
291objectName.omg + objectName.sha1 In each of these cases, the .sha1 file is the sha1 sum of the file it goes with, not of the file it points to.
292objectName.lnk + objectName.sha1 .lnk is a relative file name to objectName.omg
293objectName.url + objectName.sha1 .url is a URL to a the .omg on a different server
294 Probably need to store other info in the .url file, sha1 of the original file, other web cache info.
295 Which starts to encroach on web proxy / cache territory, which we may not want to do,
296 since we want to use real ones instead of crappy LL cache.
297
298.cache
299 sha1 as file names of .lnk or .url files.
300
301If the file system date stamps are different, then someone edited the file, recreate the sha1 files.
302 Which implies that lengthy sha1 calculations need to touch the file once done.
303
304*/
305
189#endif 306#endif