[Archived] Original Mod Collaboration Thread

[KidneyBeanBoy]

So someone mentioned, awhile back, about a small wind funnel, or something. I think that something like that, which would randomly send you somewhere on the map, would be cool to implement as an attack, or something, but I'm not sure there's a suitable base yet.

 

That was me. it was a tornado idea that I had.

[debugman18]

And by the way, I noticed we can't really customize the world entity with a cloudrealm one. From gamelogic.lua:

local world = nillocal ceiling = nilif savedata.map.prefab == "cave" then         world = SpawnPrefab("cave")        -- ceiling = SpawnPrefab("ceiling")else        world = SpawnPrefab("forest")end

There is no way to bypass it? We couldn't remove the forest prefab during worldgen, and spawn realm instead? It's all derived from the world...

[Craig_Perry]

And by the way, I noticed we can't really customize the world entity with a cloudrealm one. From gamelogic.lua:

local world = nillocal ceiling = nilif savedata.map.prefab == "cave" then         world = SpawnPrefab("cave")        -- ceiling = SpawnPrefab("ceiling")else        world = SpawnPrefab("forest")end

that's rather unfortunate, you don't want a forest awaiting you up the beanstalk at all!

[debugman18]

that's rather unfortunate, you don't want a forest awaiting you up the beanstalk at all!

That's not actually what forest means here. Forest is basically the regular worldtype, while cave is the cave worldtype.

[Craig_Perry]

That's not actually what forest means here. Forest is basically the regular worldtype, while cave is the cave worldtype.

oops, too used to turf types after playing don't starve for a while, apologies for my lack of knowledge on this subject. Hope there's a bypass for it though

[ArcticFox789]

And by the way, I noticed we can't really customize the world entity with a cloudrealm one. From gamelogic.lua:

local world = nillocal ceiling = nilif savedata.map.prefab == "cave" then         world = SpawnPrefab("cave")        -- ceiling = SpawnPrefab("ceiling")else        world = SpawnPrefab("forest")end

 

Oh.

Edited September 2, 2013 by ArcticFox789

[lifemare]

@lifemare - Seems how this would make the perfect PDF manual to go in the finished mod, do we want text on it, (like a couple of small sentences, about the item/mob)?

 

This is your manual, so I'd say it was your choice.  

 

EDIT:

---

Special properties of each mob and item aswell as observations and ideas can be added as notes to each page

 

For now.

[simplex]

Consequences of choosing as a base:

Adventure mode:

[*]The world entity will be the "forest" prefab.

[*]The map may be disconnected.

[*]Time freezes in the survival world while in the cloud realm.

Caves:

[*]The world entity will be the "cave" prefab.

[*]The map can't have roads (for adventure, this is configurable).

[*]Time advances in the survival world while in the clould realm.

On final note is that for a cave, the default impassable tile is different (GROUND.WALL_ROCKY instead of GROUND.IMPASSABLE, and yes, "walls" still exist, only their wally visual aspect was changed). This may prevent code that just checks the ground type against GROUND.IMPASSABLE to work (wicker's IsValidPoint() works in both cases, though).

Edited September 2, 2013 by simplex

[debugman18]

Consequences of choosing as a base:

Adventure mode:

[*]The world entity will be the "forest" prefab.

[*]The map may be disconnected.

[*]Time freezes in the survival world while in the cloud realm.

Caves:

[*]The world entity will be the "cave" prefab.

[*]The map can't have roads (for adventure, this is configurable).

[*]Time advances in the survival world while in the clould realm.

On final note is that for a cave, the default impassable tile is different (GROUND.WALL_ROCKY instead of GROUND.IMPASSABLE, and yes, "walls" still exist, only their wally visual aspect was changed). This may prevent code that just checks the ground type against GROUND.IMPASSABLE to work (wicker's IsValidPoint() works in both cases, though).

 

For adventure:

1. We can change the contents of either, correct?

2. That could be bad, depending on setpieces we want placed.

3. I don't know if I like that.

 

For caves:

1. We can change the contents of either, correct?

2. That's with me. Roads that need to be placed can be done so with static setpeices, I believe.

3. It gives the player a sense of responsibility for the world below, which is nice.

 

As for GROUND.IMPASSIBLE, the only place that is really referenced is in placing structures, so I don't see it as a major roadblock or anything. Especially since we can just add an additional check for GROUND.WALL_ROCKY, for compatibility with the regular world, if thats where a player decides to construct an Up and Away structure.

 

I... I'm leaning towards caves, still. It doesn't involve patching the saveindex, which is a plus, and it already has built in functionality for additional levels.

[simplex]

For adventure:1. We can change the contents of either, correct?2. That could be bad, depending on setpieces we want placed.3. I don't know if I like that. For caves:1. We can change the contents of either, correct?2. That's with me. Roads that need to be placed can be done so with static setpeices, I believe.3. It gives the player a sense of responsibility for the world below, which is nice. As for GROUND.IMPASSIBLE, the only place that is really referenced is in placing structures, so I don't see it as a major roadblock or anything. Especially since we can just add an additional check for GROUND.WALL_ROCKY, for compatibility with the regular world, if thats where a player decides to construct an Up and Away structure. I... I'm leaning towards caves, still. It doesn't involve patching the saveindex, which is a plus, and it already has built in functionality for additional levels.

1. Yes. Both are just a tweaked world prefab (instead of calling CreateEntity(), they call SpawnPrefab("world") and then tweak it). We can always adjust it through postinits.2. Adding static cobblestone is sure possible. But proper roads can only be done at worldgen (they are implemented as a "skeleton" for the node graph).3. I also prefer time not freezing. This alone is, to me, enough reason to go with caves.I'll try to use negative level numbers for the cloud realm. Not only does that make sense, but it reduces the likelihood of conflicts with additional cave levels (be it a mod or DLC).

[debugman18]

I added my take on the monolith to the guide. Definitely needs another go, though.

[simplex]

And there we have it, cloud caves! And yes, I'm using negative level numbers (which is working great, the negative number even shows up on the save file and on the game selection screen). And yes, now the cloud world is persistent. And yes, I implemented support for multiple cloud levels. The implementation is so flexible that if you spawn a beanstalk inside a cave it will function as a cave exit. Reciprocally, if you spawn a beanstalk_exit in a cave (or on the surface) it will function as a sinkhole.Everything's abstracted in a AddCloudLevel function and a Climbable component. When a climbable entity (such as a beanstalk) is removed, or when its climbable component is removed, the savedata gets erased automatically. In particular, if you chop down a beanstalk, its associated cloud world will be cleanly purged from existence.

Edited September 3, 2013 by simplex

[simplex]

Oh, and even though I'm using negative numbers now, this is not hardcoded anywhere in the implementation. All that is assumed is the cloud level numbers are consecutive, either increasingly or decreasingly. Changing their direction of growth or offsetting the first used number would require editing at most 2 lines of code.

I wrote it that way so it'll be basically impossible for our mod to conflict with others adding new levels (unless they do something really bad and mod-unfriendly).

[debugman18]

And there we have it, cloud caves! And yes, I'm using negative level numbers (which is working great, the negative number even shows up on the save file and on the game selection screen). And yes, now the cloud world is persistent. And yes, I implemented support for multiple cloud levels. The implementation is so flexible that if you spawn a beanstalk inside a cave it will function as a cave exit. Reciprocally, if you spawn a beanstalk_exit in a cave (or on the surface) it will function as a sinkhole.

Everything's abstracted in a AddCloudLevel function and a Climbable component. When a climbable entity (such as a beanstalk) is removed, or when its climbable component is removed, the savedata gets erased automatically. In particular, if you chop down a beanstalk, its associated cloud world will be cleanly purged from existence.

 

Awesome news! Especially the not-conflicting part!

 

I'm still doing work on prefabs. Probably going to add some food/recipes, as well. Of course, minus the art, for now. I may get around to some of the mob brains, also. In the next day, anyways.

[simplex]

@debugman18For future reference, to add a higher cloud level all you have to do is... add it. The levels added through AddCloudLevel (which you'd usually call as TheMod:AddCloudLevel()) are given consecutive heights, so their "vertical order" is determined by the order you pass them to AddCloudLevel.Once added, it will just work. A beanstalk will lead you to the level that corresponds to your current height plus one (that's why they work in caves).AddCloudLevel is used exactly the same way as AddLevel. Except that you don't pass the LEVELTYPE as a first parameter, you give it the level table directly.EDIT

---

Actually, it wouldn't be too hard to extend my implementation to get a non-linear progression, with branching at a given height leading to different levels according to either a predetermined or randomized attribution to beanstalks (I mean, to a climbable entity). As I said before, I wrote very flexible code. :razz:And by the way, both the beanstalk and the beanstalk_exit are climbable. The only difference is that in the beanstalk I wrote

inst.components.climbable:SetDirection("UP")

and in the beanstalk_exit I wrote

inst.components.climbable:SetDirection("DOWN")

To do the actual climbing (world transition, possibly preceded by generation), all you'd write is

inst.components.climbable:Climb()

for either. The rest of the "climbing code" directly in the prefabs is just about showing a confirmation dialogue to the player. Edited September 3, 2013 by simplex

[simplex]

And I've been thinking. There is no clean way to make the world entity be our own "cloudrealm" instead of "cave". While we could add and remove functionality from it to customize it how we want, I don't know, I think the cloudrealm should properly exist. :razz:With the new code I added for the worldgen, we're now able to detect if the current world (either being played or being generated) is a cloud realm. So we could bring the cloudrealm prefab to life in an "almost clean" way*. What do you think?* For the coders:

local oldSpawnPrefab = SpawnPrefabfunction SpawnPrefab(name)    if Pred.IsCloudLevel() and name == "cave" then        name = "cloudrealm"    end    return oldSpawnPrefab(name)end

[debugman18]

And I've been thinking. There is no clean way to make the world entity be our own "cloudrealm" instead of "cave". While we could add and remove functionality from it to customize it how we want, I don't know, I think the cloudrealm should properly exist. :razz:With the new code I added for the worldgen, we're now able to detect if the current world (either being played or being generated) is a cloud realm. So we could bring the cloudrealm prefab to life in an "almost clean" way*. What do you think?* For the coders:

local oldSpawnPrefab = SpawnPrefabfunction SpawnPrefab(name)    if Pred.IsCloudLevel() and name == "cave" then        name = "cloudrealm"    end    return oldSpawnPrefab(name)end

That would allow for the cloud waves, custom reverb, all sorts of nice things, components, right?... I like it.

[simplex]

That would allow for the cloud waves, custom reverb, all sorts of nice things, components, right?... I like it.

Well, we could also do that through postinits. The main difference is how we'll handle it. Using postinits, we'll have to first undo the cave-specific logic before adding our own, which is a pain and requires constant attention regarding updates, since if Klei adds new cave stuff applied to the cave prefab itself we'll have to update our code to undo them. Using our own prefab, the concern is an update breaking the cloud level detecting logic.

However, I think it's very unlikely that it'll break. I'll give an overview on how I organized the fundamentals of my implementation so you can emit a judgement yourself.

The basic method for detecting a cloud level is doing arithmetic on the level number. Level numbers are unique (and that must always be the case, since they are keys in a table: a duplicate level number means overwriting a level). If the level number is in the "cloud range", then it's treated as a cloud level. This necessarily works for brand new worlds*, the only concern being we changing our cloud level order/organization, modifying these numbers, which could break compatibility with older saves. That's why I only use this approach in worldgen and if there's no other available.

The primary method for detecting a cloud world is savedata. I organized levels by height. The surface has height 0, cave levels have negative height (the first cave level has height -1, the ruins have height -2, and if new cave levels are added, be it by Klei or a mod, they'll automatically be given the appropriate height, which is just their level number with the sign inversed) and cloud levels have positive height (determined by the order they are given to AddCloudLevel). So what I'm doing is attaching a dummy component (upandaway_metadata) to the world entity through a postinit, whose purpose is simply to store the world's height as savedata (and only if that hasn't been stored already).

The cloud level detecting algorithm is thus the following:

[*]If we are in worldgen, proceed to step 3.

[*]If the world entity exists, has the upandaway_metadata component and there's a "height" entry stored in it, use this as the height and proceed to step 4.

[*]Compute the height based on the current level number.

[*]If the height is positive, we are in a cloud level.

Also, if somehow the above logic were to break (and I really can't think of how that could happen), then a lot more serious aspects in the worldgen implementation would break. So I think assuming it'll always work for this simple thing is more than fair.

* Brand new cloud worlds. How old the survival save is doesn't matter.

Edited September 3, 2013 by simplex

[simplex]

I sketched up some basic worldgen with some of our core assets: turf, skyflowers and sheep.

Grab it from the git repo and check it for yourselves. Just spawn a beanstalk and climb!

And, hmm, looking at how it all fits together I'm thinking we need some kind of tree. Or at least some tall vegetation (or something passing for that). The world looks quite empty without it.

Also, I'm noticing some stutter sometimes when walking around the cloud level. It seems to be caused by the game dynamically loading/unloading assets (such as textures and animations) too frequently. What the game does for its own level types is include common assets and prefabs in the dependencies of the world entity, preventing that. So I think we really need to have our own cloudrealm entity, for the sake of smooth gameplay.

Edited September 3, 2013 by simplex

[Warrick]

frankly, im excited for this mod

[simplex]

frankly, im excited for this mod

So am I!Everyone, how's the situation on the cloud/sky "waves"? And, more generally, what's out artists' take on the organization/sharing of art? Except maybe for @lifemare, I don't think you feel git is the best method for that, and things get easily lost in this thread.One unannounced feature of my TEX converter is that it converts images from URLs. So, as long as there's a public, fixed URL for the atlases being worked, automating their integration in the git repo is a breeze. Edited September 3, 2013 by simplex

[simplex]

I just noticed this happens when you enable the mod:

How sneaky, @debugman18!

[MilleniumCount]

And git is what exactly? A file sharing program?

Jeez so much to read....^^

[simplex]

And git is what exactly? A file sharing program?Jeez so much to read....^^

It's a distributed version control and source code management software (from Wikipedia! ).I just added mist to the cloud level. Buuut... it's pretty much invisible in contrast with the cloud turf. I'll check another time how it can be tweaked to be more visible, not I have to leave. Edited September 3, 2013 by simplex

[Tayburro]

I have an update idea im writing with the exact same name funnily enough, anyway mine is much different instead having hot air balloons and what not if anyone asks me ill submit it in some format.