No docs?

[Cobradabest]

Hey, I'm very interested in using there, so I installed it via Haxelib, but I don't see any docs on how to use it, like creating and compiling a project with it.

How can I get started with this?

[Brian151]

how the heck did you install via haxelib?! i haven't yet got any of my projects up there as it's yet another thing to figure out.
i also haven't touched this in ages, so it hardly does anything... /:
there's no docu because thus far, it doesn't really work in any meaningful capacity

the rust port of the decompiler probably is of more use to you
https://github.com/ProjectorRays/ProjectorRays

i hope to continue work on this some day, along with multiple other projects

[Cobradabest]

I installed it via haxelib git shockwave https://github.com/Earthquake-Project/EarthQuake-Haxe, which seemed to work.

Well, I hope you continue work on this one day, because I'd love to try and make Shockwave stuff one day!

[Brian151]

that... is interesting... TIL
i was worried you found some shady place/person who uploaded this to the haxelib site without notice/authorization.
which worries me mostly from a security standpoint.

my goal has always primarily been breaking it, not making it.
i may or may not implement functions for generating movies/casts
however, there will be particulars about how i do this.

for one, shockwave player is actually a degree more annoying than flash player to get working [it's dumb luck xtras never caused more support issues than a few isolated incidents]
and i'd be lying if i said i ever liked the player. i hate it...
there's some neat things that can be done, but frankly, many could be re-implemented via flash.

i have theorized how i would build a modern day director/shockwave movie/cast, and of this much i am certain:
1] the format is arcane as-is, i would modernize it [and FOSS it]
2] xtras are a liability in many ways, i'd drop them for embedded compiled code like flash did. which was possible due to the extensive API provided, and the creation of the ByteArrayAsset class. also, it helps that flash never implemented a system of external native DLLs to begin with.
3] i don't really want to try compiling lingo code, and i don't want to interpret its bytecode. i'd probably compile [hopefully through an existing tool something] something target-specific like js, web assembly, native x86/ARM/RISC V/etc... code. given lingo bytecode as the source, i MIGHT try to transpile the bytecode. [this falls under the same flavor of problems with interpreting it, AND dealing with the XTRAs] it would be feasible, but it'd be quite awful.

so, i really want to continue this project. but it's hard to do. currently, one of my parents has an issue with over-commitment and the burden/consequence of it gets dropped on me. besides that [and the bigger issue], this is just not a nice format. people call flash this "horrible black box" , but between official documentation and hackers, this isn't true anymore. and flash also was more streamlined. it still has multiple sub-formats [+ versioned] and asset dependency. but nothing insane like director/shockwave. director/shockwave is full of co-dependent resources, rando external third party code dependencies [the XTRAs], and all kinds of smaller formats that often come with variation. [and also some formats depend on XTRAs. director/shockwave as-is cannot read/write them, and a few are not common/open/documented formats]. it's just not fun to work with. hence why even now, anyone wanting to do anything particularly involved with this, is having to use or work with/around the "official" resources/tools. things are marginally improved, but what this project specifically set-out to do, is not accomplished. it is more likely i'll have documentation of the format written [rather, transcribed] + published here before i have working code.

[Brian151]

so, i brought this up in the discord server. i cannot implement this by myself. to some extent, i could, but not such issues as code compilation. and that's a big issue... i can probably do most of the rest. probably/hopefully...

bottom line is, none of us feel strongly about saving these files. that goes double for building an editor, we absolutely will NOT build editors.

also, no one really wants to start from scratch or sees the reasons to do so. we have tools for parsing/converting, and there's also SCUMMVM for running them.

i don't feel as strongly about this, either... i never have... we brought it up not long after this project started under the name "openshockwave". given a day, i assure you, i could re-spec the file format. at least, a decent chunk of it. and even when i somewhat had the time to do this, i never did it.

our primary goal has always been to completely dissect this format. enable everything ever made with director/shockwave to potentially be decompiled + data-mined. document the format for others to build tools, as well. but making new stuff always was an extended stretch goal and of exceptionally low priority.

i wouldn't say that something concerning file generation will never happen, but it won't happen anytime soon.

i still intend to update this specific version of the lib, but this again won't likely happen to soon, or at least, not at a rapid rate. best case, you're looking at several months to a year before this becomes anything comparable to projectorrays. and given my current personal/life issues, that is almost entirely too optimistic.

another thing, when/if i do work on this again, it's all going to remain web/browser-based for quite some time. a rather painful compromise i had to make for all projects because handling cross-platform right now is just out of my time budget and beyond my mental capacity. some might not be too happy about this... i at least am trying to keep the "core" code as platform-agnostic as possible.