General Development

[ArcticFox789]

Ow snap. I've just realised a problem with the Ball O' Steel: stunning is a unique feature for RoG :/

 

Ah. That is an issue, and we have a strict rule of keeping content open for all players. Anyway around this, possible changes to the Ball O'Steel?

[ArcticFox789]

Maybe that can tie into the whole plot about how you ruin the Cloud Realm's ecosystem by stealing too many Golden Eggs.

 

The plot is quite different now, but not massively different, some concepts have remained. The Golden Eggs idea has been scrapped, but the plot is quite hush-hush so far at least, so I won't divulge further.

[Battal]

It's because I'm Canadian, isn't it!

[simplex]

Ah. That is an issue, and we have a strict rule of keeping content open for all players. Anyway around this, possible changes to the Ball O'Steel?

It doesn't sound like a big issue, though I need to check how stunning works in RoG. But for that I need someone to explain me what this "RoG stunning" is .

[debugman18]

@simplex

I think 0.0.6 is practically ready. Is there anything else you think should be done for it?

[simplex]

@simplex

I think 0.0.6 is practically ready. Is there anything else you think should be done for it?

I was going to say the short wave drawing distance, but I just fixed that. So the only thing I can think of is taking care of the sharp colour transition in the intersection of the semi-transparent blue's edge with another wave:

I think the best way to handle this would be making the alpha fade towards the upper edge.

[debugman18]

I was going to say the short wave drawing distance, but I just fixed that. So the only thing I can think of is taking care of the sharp colour transition in the intersection of the semi-transparent blue's edge with another wave:

I think the best way to handle this would be making the alpha fade towards the upper edge.

 

I'm working on that right now, I'll post the completed version when it's done.

[debugman18]

Alright, so that's done.

 

Except the waves look like this:

 

 

There's a weird bug somebody reported with a whirlwind crash, if you check the workshop bug thread. It doesn't actually give a useful error, at least at face value.

 

https://docs.google.com/file/d/0B5XSGLNqSOjJWVk1dmktbVN1eE0/edit

 

It's pointing to this function in scheduler.lua:

    for k, v in pairs(self.running) do            if coroutine.status(v.co) == "dead" then            --The task is finished. kill it!            task:SetList(nil)            self.tasks[v.co] = nil        else             local success, yieldtype, yieldparam = coroutine.resume(v.co, v.param)            if success and coroutine.status(v.co) ~= "dead" then                if yieldtype == HIBERNATE then                    v:SetList(self.hibernating)                elseif yieldtype == SLEEP then                    yieldparam = math.floor(yieldparam)                    local list = self.waitingfortick[yieldparam]                    if not list then                        list = GetNewList()                        self.waitingfortick[yieldparam] = list                    end                    v:SetList(list)                end            else                v:SetList(nil)                v.retval = yieldtype                if not success then                    print (debug.traceback(v.co, "\nCOROUTINE "..tostring(v.id).." SCRIPT CRASH:\n".. tostring(yieldtype)))                    TheSim:DebugPause()                    self:KillTask(v)                    return                end                self:KillTask(v)                            end        end    end

[simplex]

Alright, so that's done.

 

Except the waves look like this:

It seems waves are made darker and more opaque the closer they are to the camera. We better undo the changes in this last commit, then, since before the issue was less visible.

There's a weird bug somebody reported with a whirlwind crash, if you check the workshop bug thread. It doesn't actually give a useful error, at least at face value.

 

https://docs.google.com/file/d/0B5XSGLNqSOjJWVk1dmktbVN1eE0/edit

 

It's pointing to this function in scheduler.lua:

How do you know it's a whirlwind crash?

And you could've said the name of the function . Though, since I dealt with this issue many times before, I already know it's Scheduler:Run, he. But this log doesn't make sense. We're patching Scheduler:Run in code/modenv.lua, but modenv.lua doesn't appear in the stack trace. Could you check if any of the mods you have enabled are interacting with Scheduler:Run in any way? (try scheduler:Run and scheduler.Run, since scheduler with a lowercase 's' is the name of the global variable of the class Scheduler, and the class Scheduler is not exposed anyway).

[debugman18]

It seems waves are made darker and more opaque the closer they are to the camera. We better undo the changes in this last commit, then, since before the issue was less visible.

How do you know it's a whirlwind crash?

And you could've said the name of the function . Though, since I dealt with this issue many times before, I already know it's Scheduler:Run, he. But this log doesn't make sense. We're patching Scheduler:Run in code/modenv.lua, but modenv.lua doesn't appear in the stack trace. Could you check if any of the mods you have enabled are interacting with Scheduler:Run in any way? (try scheduler:Run and scheduler.Run, since scheduler with a lowercase 's' is the name of the global variable of the class Scheduler, and the class Scheduler is not exposed anyway).

 

Which commit? The waves with the fixed transparency, or the change to the cloudrealm wave setting?

 

This isn't my crash. I'll look at the mods they are using.

[simplex]

Which commit? The waves with the fixed transparency, or the change to the cloudrealm wave setting?

The change in transparency. Isn't that what caused the awkwardness? And what do you mean by "fixed transparency", isn't it supposed to be a gradient?

This isn't my crash. I'll look at the mods they are using.

Oh, don't bother. That's exactly what was addressed in the Scheduler:Run patch I mentioned. I was worried this was still happening somehow in stable or dev.

[debugman18]

The change in transparency. Isn't that what caused the awkwardness? And what do you mean by "fixed transparency", isn't it supposed to be a gradient?

Oh, don't bother. That's exactly what was addressed in the Scheduler:Run patch I mentioned. I was worried this was still happening somehow in stable or dev.

 

By fixed transparency, I mean that I fixed the transparency. Previously it was a gradient, but it didn't turn into total alpha. I changed it so that the transition was from semi-transparent blue to total transparency.

 

I also have no idea if it was the change to the transparency or to the way waves are configured in cloudrealm.lua, since I didn't test your commit before implementing the tweaked waves.

 

I'll check to see if it can be fixed without undoing the transparency change.

[debugman18]

@simplex

This is what I managed on my end. Do you think that's about right?

 

[simplex]

@simplex

This is what I managed on my end. Do you think that's about right?

Looks pretty good to me!

I liked the blue effect over the clouds when the semitransparent part extended higher, but given the issues I think this is the way to go. But just to be sure, that white vertical stripe is just mist, right?

[debugman18]

Looks pretty good to me!

I liked the blue effect over the clouds when the semitransparent part extended higher, but given the issues I think this is the way to go. But just to be sure, that white vertical stripe is just mist, right?

 

The blue part actually is higher than it was before, because I had to darken and bring it higher so that the space between clouds would be virtually invisible. I wish Klei would maybe do the waves in a different way (for starters, not at the engine-level) but that's probably asking a bit much.

 

On the right? Yeah, that's just mist.

[simplex]

The blue part actually is higher than it was before, because I had to darken and bring it higher so that the space between clouds would be virtually invisible. I wish Klei would maybe do the waves in a different way (for starters, not at the engine-level) but that's probably asking a bit much.

 

On the right? Yeah, that's just mist.

Very well, I think 0.0.6 is ready.

[debugman18]

Very well, I think 0.0.6 is ready.

 

Alright, I'll merge and sign then release.

[debugman18]

Merged and tagged/signed.

 

Now I'm uploading.

[simplex]

My PreChewedTree character mod is going great with the help of Dryiicefox and orian34. Just thought I would say this here!

Great! I hope you have fun with your first mod!

[debugman18]

Done here, still uploading to Steam.

 

I think that's all (or nearly all) of the bugs, now we can focus on balance. As I said in the developer comments on Steam, I think prefab density and things of that nature should wait until beta release, along with the new world content, to minimize players having to regen their cloudworld.

[simplex]

Done here, still uploading to Steam.

 

I think that's all (or nearly all) of the bugs, now we can focus on balance. As I said in the developer comments on Steam, I think prefab density and things of that nature should wait until beta release, along with the new world content, to minimize players having to regen their cloudworld.

I think we should try to take care of prefab density and worldgen related balance in alpha. Players aren't forced to regen (though I think we should give them an easy way to regen just the cloudrealm, at least during alpha and maybe early beta). They'd have an incentive to regen, of course, but I'd rather do this is alpha than in beta, to keep beta more stable, allowing longer runs of the mod.

[debugman18]

I think we should try to take care of prefab density and worldgen related balance in alpha. Players aren't forced to regen (though I think we should give them an easy way to regen just the cloudrealm, at least during alpha and maybe early beta). They'd have an incentive to regen, of course, but I'd rather do this is alpha than in beta, to keep beta more stable, allowing longer runs of the mod.

 

That's pretty reasonable. Alright then, alpha it is.

 

How do you think we should implement the regen? As an option when they climb the beanstalk?

[Battal]

How do you think we should implement the regen? As an option when they climb the beanstalk?

 

Yeah, like the old caves.  I support this idea.

[simplex]

How do you think we should implement the regen? As an option when they climb the beanstalk?

I think as an option when climbing would be the most familiar way to players, and the simplest to implement on our end (a nice set of qualities for a temporary feature ).

[DwerBomb]

But about the bugs there is still that one with the food, where you see, instead of the coloured backround of the food item, a strange combination of all the three colours...