General Development


debugman18
 Share

Recommended Posts

I also added some 'abilities' to the thunder logs and dragonblood logs.

 

When a thunder log is used in a fire, it will bring down a lightning strike. Pretty predictable, I may tweak this in the future.

 

When a dragonblood log is used on a firepit, a few things happen. Firstly, the fire will go out initially. After that, the flame will be red, and much hotter (enough to cause overheating in the cloud realm), although it burns out a little over 10x quicker. The firepit will never revert to a regular fire afterwards. It's useful for a quick heat boost, but it consumes too much fuel to be reliable, so the player should have to find other ways to keep warm longer. It also has a 10% chance to go out every two seconds. I'm going to see if I can make foods cooked on it turn into ash.

 

Of course, either of these are up for criticism and tweaking or even removal if people don't like them. :razz:

 

My plan is to possibly even move effects like these to other firepit variants in the future.

I think a lightning strike is too much for using a thunder log. If we had a subtle electrical spark effect (and no, "sparks" doesn't count :razz:), then sure, but if it's between a full blown lightning strike and nothing I vote for nothing.

And I also didn't like the permanent change to the firepit. Why make the player waste a firepit (or, more likely, never use a dragonblood log except in a huge emergency)? I'm not too convinced of the short-lived fire burst idea as a whole, what's its purpose?

Link to comment
Share on other sites

I think a lightning strike is too much for using a thunder log. If we had a subtle electrical spark effect (and no, "sparks" doesn't count :razz:), then sure, but if it's between a full blown lightning strike and nothing I vote for nothing.

And I also didn't like the permanent change to the firepit. Why make the player waste a firepit (or, more likely, never use a dragonblood log except in a huge emergency)? I'm not too convinced of the short-lived fire burst idea as a whole, what's its purpose?

 

Okay, so no lightning strike with thunder logs.

 

The purpose of the fire burst would be to allow the player to quickly warm up to leave again, at the cost of a fair amount of fuel. I suppose it doesn't need to be a permanent effect. (Or even an effect at all.) Apparently I didn't implement the chance of going out, also.

 

You don't seem too thrilled about either addition. :razz: I'm just experimenting with ways to make the thunder and dragonblood logs more interesting. I think they should do something other than just burn like every other burnable right now.

 

Maybe I'm barking up the wrong tree with that thought, and they're fine the way they are. :razz:

Edited by debugman18
Link to comment
Share on other sites

Okay, so no lightning strike with thunder logs.

 

The purpose of the fire burst would be to allow the player to quickly warm up to leave again, at the cost of a fair amount of fuel. I suppose it doesn't need to be a permanent effect. (Or even an effect at all.) Apparently I didn't implement the chance of going out, also.

 

You don't seem too thrilled about either addition. :razz: I'm just experimenting with ways to make the thunder and dragonblood logs more interesting. I think they should do something other than just burn like every other burnable right now.

 

Maybe I'm barking up the wrong tree with that thought, and they're fine the way they are. :razz:

I'm not too thrilled about the additions because they feel a bit... gimmicky. We already have a bunch of cool effects and flashy things, what we miss most is basic resources allowing the player to just survive as the cloudrealm is explored.

But thinking about it some more, I warmed up to the dragonblood log effect. Not to its permanent side-effect, but the short burst of heat is interesting, and complements the standard log type in the cloud realm (thunder logs) nicely. It should be very hard to implement this, though. I haven't seen how you did it yet, but handling properly the addition of regular fuel on top of dragonblood logs (or the other way around) should be fairly hard. I'm not even sure what the outcome of this interaction should be. And making this distinguished effect of the fire persist across save reloading (only while the dragonblood fuel lasts) should also be tricky.

Link to comment
Share on other sites

I'm not too thrilled about the additions because they feel a bit... gimmicky. We already have a bunch of cool effects and flashy things, what we miss most is basic resources allowing the player to just survive as the cloudrealm is explored.

But thinking about it some more, I warmed up to the dragonblood log effect. Not to its permanent side-effect, but the short burst of heat is interesting, and complements the standard log type in the cloud realm (thunder logs) nicely. It should be very hard to implement this, though. I haven't seen how you did it yet, but handling properly the addition of regular fuel on top of dragonblood logs (or the other way around) should be fairly hard. I'm not even sure what the outcome of this interaction should be. And making this distinguished effect of the fire persist across save reloading (only while the dragonblood fuel lasts) should also be tricky.

 

It wouldn't be very hard, the way I've got it working right now.

 

Right now the way it is implemented is that when the dragonblood log is put onto the fire, it puts out the current fire* and spawns a special fire. We could simply add a timer to it, or even just wait until it burns out, then replace it with the original fire.

 

*The default fire is campfire_fire, and the dragonblood logs replaces it with its own fire type.

 

I created a postinit for the firepit for onsave and onload (since it doesn't use any itself, it's components handle that) so persistence shouldn't be too much of a problem either. We wouldn't even have to change the way the permanence works; we'd just have to add the part where it reverts to a normal fire.

 

 

Any feedback on the animations?

 

I haven't seen the rose yet, but the skytrap was nice. A note, though. The bottom of the animation should be at the middle of the screen. The intersection is actually ground level in-game. :razz: I fixed that for the skytrap, but I figured I'd let you know.

Edited by debugman18
Link to comment
Share on other sites

Okay, so I nerfed the way dragonblood logs worked. Now, they put out the fire, bring up a very short burst of very hot fire, and the fire goes out again. It seems more fitting to me, let me know if you have any suggestions or complaints about it. :p

  • Like 1
Link to comment
Share on other sites

Hm. Gotta agree with simplex on this one.

 

It seems to me like the right thing to do would be to make the dragonblood logs last longer than other fire sources, since low oxygen in all. That will actually make them worthwhile without being gimmicky. And for balance's sake, make them rarer.

Edited by Silentdarkness1
Link to comment
Share on other sites

Hm. Gotta agree with simplex on this one.

 

It seems to me like the right thing to do would be to make the dragonblood logs last longer than other fire sources, since low oxygen in all. That will actually make them worthwhile without being gimmicky. And for balance's sake, make them rarer.

 

They've been tweaked since their addition. Currently they give you a brief flash of very hot fire (which warms you up quicker than a full firepit, but a little more quickly) and then the fire goes out completely. I don't see them as overpowered right now, if anything, they allow you to get back to exploring more quickly at the cost of more fuel. It should also be noted that the intense fire from the dragonblood log can and likely will burn stuff around it like a campfire, if you use it in the overworld.

 

Currently you can carry them in stacks of five. A stack allows you to warm up enough to head out again. As for their rarity, you have to chop them down, which is difficult on its own, since the biome they inhabit is quite hostile.

 

At what point of progression are you in current testing? It's important to have something to balance them against, if they do indeed need balancing.

Link to comment
Share on other sites

Well, I didn't really have any trouble gathering the logs from their proper biome. Even if I turned godmode off.

 

I don't mind balancing them, but it'd be good to know what to balance them against. Are they too warm? Are trees too common? Do too many logs drop? Is the trip from the spawnpoint to the biome easy/hard? Are the enemies in the area easy/hard? What advantages do you see from using them? Are you using winter clothes, heat rocks, golden eggs, warm food, ball lightnings, firepits, etc?

 

Sorry if that's too many questions, but I'd like to know what other things should be factored into the balancing.

Edited by debugman18
Link to comment
Share on other sites

No, no. I don't mind all the questions. It's a good thing. I wasn't being nearly descriptive enough, apologies.

 

Well, for one, the Beanlets seem to be rather uncatchable without a ranged weapon. Also, Geese eat all the Green Beans before I can get to them. And Geese and Beanlets went hand in hand in my world. Getting back to the dragonblood trees, besides the fact that they don't seem to break off after being chopped, which is understandable because not all the animations are there, it just seemed like there wasn't any tangible threat to chopping them down.

 

I haven't tried other survival items yet, because I simply did emergency testing. Turned on godmode the whole time :p

 

The only two real threats I encountered so far were the Owls and the Gummy Bears. Owls seemed to just be pigs, and Gummy Bears were just Werepigs, right down to the animations themselves. I do think the areas around the Dragonblood trees are too easy. Perhaps we need Dragontreeguards or some sort of persistant guardian.

  • Like 1
Link to comment
Share on other sites

I think it's awesome.

 

Fantastic. So, we're just waiting on Luggs with Winnie's strings. I've updated the modinfo in my local copy to show version "alpha-0.1" (which I believe is the format we decided on, if not, I'll change it) but I'm not pushing until the strings are ready. The only changes are Winnie's strings (only Mycological's at the moment) and the Shopkeeper being on the main menu.

 

 

Yup.  Yeppers.  Maybe he could randomly spew lines.

 

Well, right now he currently plays his idle animation, which consists of him tapping his foot occasionally. It has quite a mysterious feel to it.

Link to comment
Share on other sites

I've updated the modinfo in my local copy to show version "alpha-0.1" (which I believe is the format we decided on, if not, I'll change it)

I think we should use alpha-0.0.1. MAJOR.MINOR.REVISION. I managed to inflate ktech and krane's version number to 4.1.1 because I added the revision number late, thinking it wouldn't be necessary, and U&A will certainly need many more updates than them :razz:.

Edited by simplex
Link to comment
Share on other sites

I think we should use alpha-0.0.1. MAJOR.MINOR.REVISION. I managed to inflate ktech and krane's version number to 4.1.1 because I added the revision number late, thinking it wouldn't be necessary, and U&A will certainly need many more updates than them :razz:.

 

Alright then, alpha-0.0.1 it is.

 

What kinds of things do you think will warrant increasing the minor and revision fields, respectively?

Link to comment
Share on other sites

Alright then, alpha-0.0.1 it is.

 

What kinds of things do you think will warrant increasing the minor and revision fields, respectively?

The revision number is for things like bug fixes and tweaks. The minor number is for content addition, though we should restrain ourselves from releasing content in too small chunks: I think a minor bump should roughly correspond to the updates in DS beta. We could keep the major always at 0 during alpha, to avoid the impression of us being somewhat "done" caused by a bump to version 1.0.0, but if we're going to increase it, it should be either for really large additions (such as adventure mode) or for a change breaking compatibility with older saves.

EDIT: On second thought, I think we should release in smaller chunks than Klei did for DS beta. But still not too small.

Edited by simplex
Link to comment
Share on other sites

The revision number is for things like bug fixes and tweaks. The minor number is for content addition, though we should restrain ourselves from releasing content in too small chunks: I think a minor bump should roughly correspond to the updates in DS beta. We could keep the major always at 0 during alpha, to avoid the impression of us being somewhat "done" caused by a bump to version 1.0.0, but if we're going to increase it, it should be either for really large additions (such as adventure mode) or for a change breaking compatibility with older saves.

EDIT: On second thought, I think we should release in smaller chunks than Klei did for DS beta. But still not too small.

 

Yeah, I think content updates a little smaller than Klei's would be ideal.

Link to comment
Share on other sites

And oh, we need to compile some screenshots and art samples showcasing the mod in its description and announcement thread.

A video would also be very important.

 

I'll get together some decent screenshots.

 

I don't have video capture software though. I could try and run something, or worst case grab some footage from Windows.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share