Jump to content
Double Fine Action Forums
Sign in to follow this  
Cheeseness

Modders Welcome

Recommended Posts

Alrighty, so as things are starting to come together, I'd like to try to get a bunch of people in one place to chat about and brainstorm and bounce some ideas around on how any coordinated modding efforts might take shape.

It might be neat to aim to catch up an hour or two before Game Club in the #DFAdventure IRC channel (there's a webchat widget on this page). How would 7:30PM UTC on Saturday sit with people?

That'd be 2:30PM here, I might be able to make it. It's kind of right in the middle of the day though, so no guarantees. I'll try to swing by if I can.

Share this post


Link to post
Share on other sites

I'm happy to push things out another week (this week is 7DFPS and I'm majorly swamped). I'm just worried about losing any momentum that excited people might have.

I've had a little correspondence with Oliver and Matt. Moai provides zipfs functionality, so loading stuff from people's home folders might be an option for us after all (more on that as things become clearer) :D

Share this post


Link to post
Share on other sites
I'm happy to push things out another week (this week is 7DFPS and I'm majorly swamped). I'm just worried about losing any momentum that excited people might have.

I've had a little correspondence with Oliver and Matt. Moai provides zipfs functionality, so loading stuff from people's home folders might be an option for us after all (more on that as things become clearer) :D

Another week out and I think things will slow down for me a little. I'll at least have my pain meds again and be able to focus once more.

Share this post


Link to post
Share on other sites

We had a little bit of neat discussion today. AKohn was looking into how the oxygen system works, Glog78 had had some trouble compiling Moai, Jenni, flesk and bobsayshilol (who did the original multiplayer mods) were around as well.

I think next week we can aim to get a bigger turnout and see what ideas we can bounce around (hopefully by then we'll have some more stuff to play with as well).

Share this post


Link to post
Share on other sites

Do I understand right - if I have 100 types of doors or reactors or any constructible obj, I should describe them all in respective file in the "layout" folder and from EnvObjectData.lua it decides to show 'em or not (research) ??

Share this post


Link to post
Share on other sites

In my mind, it is important to get the 'fun' stuffs implemented, since 1.05 is somehow balanced. Maybe discussions for fun factor rating, based on planned development list (maybe a new idea altogether?).

What I can see happening right now is nobody is sharing their base because they are busy surviving, and most of whatever I build is focusing on the survival. I remembered the early days where we share the ecstatic part of the base, the unique shape of your base, funny moments etc.

I sincerely hope JP will be the advisor to guide how exactly the proposed development plan.

Some of fun stuff to mod:

-Delay the ending death for a little bit far later? Maybe a handicap mode to have no threat at all.

-Sandbox mode (maybe campaigns?) new game option, like Minecraft

-Naming your spacebase

-'Visiting your friends base' (for example like the game 'Clash of Clans' you can share with friends)

-Planetfall because the planet is right behind you? More user experience.

-Circle room and flood fill building tool. It it nice to have a beautiful and unique spacebase design

-Multiple level base. Again for same reason.

-Holodeck. This sounds very interesting and fun. I would like to see maybe Hack'n'slash's Alice and Bob versus Mog Chothra invasion, or maybe just a talking Massive Chalice having a pool party, to make an appearance, and we have fun accidents from there.

-Time travel. This may need some JP input, how he originally planned to make it happen. Is it change of tilesets and clothing only, or is it back to Amnesia Fortnight version of Spacebase, I am not so sure.

I think maybe mod should be about delaying death, and adding more fun stuff.

Share this post


Link to post
Share on other sites

Hey folks, good news from the latest update !

Mods can now be loaded via ZIP files from the Mods\ subdirectory of the game’s install directory. Each ZIP is loaded as a simple virtual file system which can contain directories that mirror the main game scripts and override their behavior. A file called “init.lua” in the top level of each ZIP’s directory structure will run when the mod is loaded, allowing you to perform any needed initialization. See the MyDemoObject.zip there for a simple example mod, which adds a new buildable object with its own artwork

Share this post


Link to post
Share on other sites

Woo, thanks so much!

I feel like that's a big thing for mod development that's going to enable people to feel a lot more comfortable investing their time :)

Share this post


Link to post
Share on other sites

My understanding is that it's a workload thing. If that's the case, then that prioritisation gives us two benefits - one, the devs get to focus on fixing bugs and making the game more awesome with the remaining development time they have allocated to Spacebase, and two, mod support isn't tied to Steam as a distribution platform, meaning that deployment on Humble, Desura, GOG, etc. won't cut users off from having access to mods.

Share this post


Link to post
Share on other sites

Re: no-hostile mode / creative mode etc., I just added some config flags to 1.06. If you're making a mod that wants some behavior like that, take a look at those flags.

Share this post


Link to post
Share on other sites

Personally, I'm never subscribing to any mod when it allows for full access to my system. Any mod author could decide at any time in the future to include hostile code in their mod. They could even innocently think it would be okay to just make a http request to their own server for statistics reasons and thus expose every player's IP address to them, an unexpected violation of privacy. Perhaps one day in future a popular mod author's computer will get hacked and a mod is changed to steal player's passwords and bitcoin wallets and whatever. Plenty of things can go wrong.

The modding system doesn't sandbox the scripts in any way, and automatic updates of privileged code from third parties feel like a horribly bad idea. Sure, it'd be convenient, but I'd never ever use it.

Share this post


Link to post
Share on other sites
Personally, I'm never subscribing to any mod when it allows for full access to my system. Any mod author could decide at any time in the future to include hostile code in their mod. They could even innocently think it would be okay to just make a http request to their own server for statistics reasons and thus expose every player's IP address to them, an unexpected violation of privacy. Perhaps one day in future a popular mod author's computer will get hacked and a mod is changed to steal player's passwords and bitcoin wallets and whatever. Plenty of things can go wrong.

The modding system doesn't sandbox the scripts in any way, and automatic updates of privileged code from third parties feel like a horribly bad idea. Sure, it'd be convenient, but I'd never ever use it.

This is a true and legitimate concern, but I don't think it's anything specific to Spacebase/Spacebase mods. Since mods can be distributed as assets and uncompiled Lua scripts though, there's a degree of scrutiny that a prospective player could give a mod that they were interested in.

So, it seems like our efforts to come together in IRC to bounce ideas around haven't been so successful (blame me for that, I've been swamped!).

I feel that there are two roles that feel like a good fit those of us who're interested in working together/bolstering the community:

Supporting Community Development

* Document the game's architecture (the structure of the codebase)

* Put together workflows for asset editing (extracting images from/compiling to .tex files, etc.)

* Writing example mods/tutorials

* Drawing attention to mods from other community members

Developing Spacebase

* Fix bugs (hopefully there won't be too many of these by the time DF's maintenance period comes to a close)

* Improve existing gameplay mechanics

* Address/implement things from the roadmap

* Strive for cohesive and challenging long form systems oriented gameplay (which might mean changing stuff on the roadmap or changing the behaviour of existing features if it helps Spacebase be Spacebase)

What does everybody else think?

Share this post


Link to post
Share on other sites

@DF Burger/DFMatt

In my testing of the new mod loading mechanism, it does not appear to support "overridding" the game's code files, only adding new files (content) as per the example mod provided. Please clarify if this is as intended.

The init.lua file does get loaded (roughly after game initialization) and allows for code changes through references as expected and documented.

The concern is that beginning modders will be more comfortable if they can just change the game's existing files and have the mod loader make it so the interpreter sees their custom version (in the zip file) before the standard one. As I am sure you are aware, this would require adding the mod's folder structure ahead of the game's in package.path early enough in the load process that the require statements will see the custom ones first.

The intent of this being that they would not have to be as familiar with coding or LUA to make their changes from init.lua even if that means their mods would not be as co-habitable as they could otherwise.

Another concern is control of the load order for the mods. Perhaps a mods.txt file or similar from the mods folder could be read that lists the mod zip files to load and in what order?

If overriding will not be supported, then eventually more example mods will need to be developed to show how various changes can be accomplished via init.lua so people can copy/paste/modify the code snippets as a starting point.

Thanks for whatever feedback/insight you can provide.

EDIT:

Also, I am concerned about the way linecodes are using the filename as a key in the datacache as demonstrated by the example mod. Seems the method shown to add more linecodes would restrict us from being able to reference a different language file.

Was there a reason for not accessing the loaded linecode data through g_LM.tData instead of going through the datacache? In order to support multiple languages, it seemed as though we could have a mod just reinitialize the LinecodeManager with an alternate file but not if the mods are hard coded to reference the default file because they are pulling a reference through the datacache.

Share this post


Link to post
Share on other sites
Another concern is control of the load order for the mods. Perhaps a mods.txt file or similar from the mods folder could be read that lists the mod zip files to load and in what order?

As long as overriding is fixed, load order could be implemented as a mod even if DF doesn't implement such a thing.

The hypothetical advanced modloader mod would provide an API for other mods to register their real initialization function, and each mod's init.lua would only execute a call to register the mod and its dependencies with the advanced modloader. The modloader would override some file (main.lua perhaps) in the game to perform a topological sort for the registered mods and then execute their registered callbacks in order. For extra bonus, the advanced modloader could even provide UI for enabling/disabling mods.

So, theoretically DF only has to fix the file overriding and almost every other functionality can be implemented as a mod afterwards. Well, assuming there are no other bugs in the mod system, that is :)

Share this post


Link to post
Share on other sites
As long as overriding is fixed

It also looks like the automatic mod loading stuff doesn't currently work on Linux or Mac OS, so that's something that makes things a bit awkward. I'm also not sure if the OS named (Linux/Win/Mac) subfolders are going to cause issues for cross-platform mod deployment.

Share this post


Link to post
Share on other sites
Re: no-hostile mode / creative mode etc., I just added some config flags to 1.06. If you're making a mod that wants some behavior like that, take a look at those flags.

Has anyone found these flags? I looked in the BootConfig.lua and the bootconfig file in my saves and I don't see any mention of it.

Share this post


Link to post
Share on other sites
Re: no-hostile mode / creative mode etc., I just added some config flags to 1.06. If you're making a mod that wants some behavior like that, take a look at those flags.

Has anyone found these flags? I looked in the BootConfig.lua and the bootconfig file in my saves and I don't see any mention of it.

Nope. I just finished reading all lines that changed between 1.05 and 1.06 and didn't spot anything like that.

It looks like Matt's changes didn't end up in the release version for some reason.

Share this post


Link to post
Share on other sites

The zip mods are meant to create a virtual file system where the game's base files will be non-destructively overridden, so ideally, you just pop the files in the right folder structure, zip it up, and away you go. A couple of people have reported that this isn't working properly on Windows at the moment though, and zipped mods don't seem to load on Linux or Mac OS at all :(

It looks like Matt's changes didn't end up in the release version for some reason.

If this is the case, then it might explain why things aren't working as expected.

Share this post


Link to post
Share on other sites

Has anyone made a mod using the formal system to actually modify existing variables (as opposed to creating new objects)? I tried one I found on the Steam forums and it did nothing (a new base should have had at least more resources, but it didn't). I tried creating a really basic one and it just kept crashing. I'm not familiar with Lua, but am with programming in general. What are the requirements of the init.lua to run properly?

Share this post


Link to post
Share on other sites

I went ahead and converted the Sandbox Mode mod to an ini.lua based version so it can be loaded by zip file as well as updated the Delay of Annoyance mod so players can see that they are loaded from the title screen.

Team DoubleSpank's MOD - Delay of Annoyance

http://steamcommunity.com/app/246090/discussions/0/617319460893528038/ (mod thread)

http://public.justcloud.com/dyho1g4w2n.79931479 (my version v02c)

Sandbox Mode Mod v1 by Cridge

http://steamcommunity.com/app/246090/discussions/0/617320628356448175/ (mod thread)

http://public.justcloud.com/dyhn0v64m1.79931479 (my current version)

It appears the game loads the mod zip files in alphabetical order so for now we can put numbers/letters at the start of the file name to control load order. The last mod loaded that changes the same variable wins so in this case, if sandbox is loaded last then starting matter is 2mil whereas if DoA is loaded last then starting matter is 5000. Otherwise, the two should work fine loaded together.

@buckysrevenge

I am interested to know if you are not able to get either of these mods to load and work. So far, I have not had any trouble. You will not see the increased matter until you start a new game but most of the other changes should affect existing and new game saves.

@Cheeseness

I currently do not have access to a Mac or *nix system to test these mods on. Perhaps you could try them out and let me know what you find? As long as you have a "Mods" folder to drop them in, they should work since all the changes are in the init.lua file. thx

Share this post


Link to post
Share on other sites
@Cheeseness

I currently do not have access to a Mac or *nix system to test these mods on. Perhaps you could try them out and let me know what you find? As long as you have a "Mods" folder to drop them in, they should work since all the changes are in the init.lua file. thx

As I said earlier, the current builds don't seem to load mods on Mac or Linux at all.

Share this post


Link to post
Share on other sites

Ah, ok, did not realize you had meant no mod loading at all. Hmm, was the "Mods" folder added to the game's installation similar to "...\steamapps\common\SpacebaseDF9\Mods"? Perhaps try changing the folder name to all lowercase? Sadly, the mod loading code is in the executable so it is hard to say what logic was used around the MOAIFileSystem.mountVirtualDirectory feature which I guess was what the DF guys were talking about.

Share this post


Link to post
Share on other sites

Okay, I guess I should have read Cheesness' previous post closer... I'm running Linux and the mods don't work at all (they didn't crash, they just didn't do anything, even to a new base). Glad to know that my version of the mod (which was pretty much the same) wasn't broken, just the game :(. And yes, the Mods folder is there (created by the install, JP's sample mod is there, too), verified game cache integrity, too. I tried changing the case of the name (MODS, mods) and it didn't make a difference.

Anyone know who's in charge of the SBDF9 bug fixing since JP's gone now?

Share this post


Link to post
Share on other sites
Anyone know who's in charge of the SBDF9 bug fixing since JP's gone now?

They might have laid off everyone who knew the game's internals. 12 people is a lot, and those who remain might have their hands full of work even without having to deal with Spacebase.

It's possible that there won't be any patches in months, not until they've stabilized their financial situation and gotten some of the ongoing projects out of the door.

The mod support not working on Mac/linux is so huge issue that I think they'll eventually fix at least that. But not necessarily anytime soon.

Share this post


Link to post
Share on other sites
I'm running Linux and the mods don't work at all (they didn't crash, they just didn't do anything, even to a new base).

Ok, thx for the feedback. Make sure folder name is back to "Mods". So does DFMatt's example mod even work on non-windows platforms? If so, then maybe we need to not use spaces in the zip file name as he did? Otherwise there must be a bug in his code to traverse the virtual folders under Mods to locate and run the init.lua files. I doubt the MOAI platform's mounting of virtual folders does not work on non-windows platforms.

Share this post


Link to post
Share on other sites
Ah, ok, did not realize you had meant no mod loading at all. Hmm, was the "Mods" folder added to the game's installation similar to "...\steamapps\common\SpacebaseDF9\Mods"? Perhaps try changing the folder name to all lowercase? Sadly, the mod loading code is in the executable so it is hard to say what logic was used around the MOAIFileSystem.mountVirtualDirectory feature which I guess was what the DF guys were talking about.

Yeah, I had a bit of a fiddle around. I spoke with Matt briefly about it, and he said he'd tested it on Linux before pushing it live. I can only assume that the right build didn't go up (which happens sometimes).

The example mod doesn't work on Linux or Mac OS. That's what I'd been asking people to test with when I realised something was up.

Share this post


Link to post
Share on other sites

I thought I'd mentioned it in this thread, but I guess I hadn't. I was going to suggest that people digging into the Lua sources should probably document their findings somewhere. This Spacebase wiki seems like an appropriate place to do that.

Share this post


Link to post
Share on other sites
Sign in to follow this  

×
×
  • Create New...