Suggestions


Recommended Posts

This is more a suggestion for the forum rather than the actual mod, but I think you should have a separate thread for artwork and animations and stuff.  Just so it's more organized.

we have several art threads, they are just not public ;)

Edited by kraken121
Link to comment
Share on other sites

I have a little suggestions.

1. Gas Geysers (if I'm saying it correctly):

- Spawning at swamp

- Deals 40 dmg when player step on it during eruption

- Overheats player during explosion

- Explodes in 30 secs

2. Gigantic frogs:

- 400 HP

- Deals 3x more dmg than frogs

- Have frogs abilities + they will suck off things from your inventory

- Spawns only during rain

- VERY rare

- Maybe drops special weapons (like poison sword?)

Link to comment
Share on other sites

I have a little suggestions.

1. Gas Geysers (if I'm saying it correctly):

- Spawning at swamp

- Deals 40 dmg when player step on it during eruption

- Overheats player during explosion

- Explodes in 30 secs

2. Gigantic frogs:

- 400 HP

- Deals 3x more dmg than frogs

- Have frogs abilities + they will suck off things from your inventory

- Spawns only during rain

- VERY rare

- Maybe drops special weapons (like poison sword?)

1. we already have something like this in the lava mines

 

2. no more frogs, we hate frogs, unless it's frog legs, yum! :D

Link to comment
Share on other sites

Ah.  Well in that case, take this thing I did for practice.  You might find a use for it in your mod.

 

https://www.dropbox.com/s/0efqr7e7qvyztd5/Corpse%20Worm.rar

 

That looks a heck of a lot better than your beanclops, nice progress ;)

 

I would say that needs a bit more polish art wise though, the animation looks like you're getting better with Spriter as well, but would still need to be worked on a little. (like the angry anim good work), If it was polished up a lil more, I could possibly use it for purple worms and plug it in to see how it looks in game. 

 

We do need some anims for this spell, http://www.dandwiki.com/wiki/SRD:Black_Tentacles if you want to give a go at that, pretty much almost the same as the tentacles in game, but maybe with slightly diff anim and looks of course. 

  • Like 1
Link to comment
Share on other sites

nope...

 

Death spent a ton of time trying to figure it out and I have no clue whats causing it.

It also seems that if I use the mem fix, I will crash going into adventure mode while our mod is active, but it will not crash Death. Using the Mem fix with UnA is not crashing the adventure mode for me though, so we been trying to figure out what the cause of this is...Death has some theories though.

 

Yes, which require the ability to rebuild lua with debug flags (whihc is impossible on statically linked lib), and/or DS symbol table (which is unreachable for obvious reason) etc... In short, no, she does not. I don't even know which exact revision of 5.1 it's using, but that's likely irrelevant. I have no further insight on what's causing access violation than I did initially, It seems memory corruption is manifesting itself outside of the normal script code I have access to, stack overflow in last gc call? double free on cleanup code? who knows... I sure don't.

 

Serves to remind me why I hate script languages. And I still can't reproduce the adv mode crash anyway.

 

Either way, I thought they'd get around to fix the bloody flags and double reloading, and see if it persists, which clearly did not happen (I guess kids poking themselves with pixel spears are more important). Ultimately, the whole thing should be fixed on 'upper level', if one flag is too hard, what am I wasting my time on here?

 

TL;DR /WONTFIX this mod on its own will likely never cause outofmemory with LAA on even in current state of game code, the rest is beyond the amount of time/nerves I'm willing to waste for a game mod. Internal version of fix will be removed next rev, it will be up to you if what kind of crash you prefer if you're running with 100+ mods.

Link to comment
Share on other sites

Yes, which require the ability to rebuild lua with debug flags (whihc is impossible on statically linked lib), and/or DS symbol table (which is unreachable for obvious reason) etc... In short, no, she does not. I don't even know which exact revision of 5.1 it's using, but that's likely irrelevant. I have no further insight on what's causing access violation than I did initially, It seems memory corruption is manifesting itself outside of the normal script code I have access to, stack overflow in last gc call? double free on cleanup code? who knows... I sure don't.

 

Serves to remind me why I hate script languages. And I still can't reproduce the adv mode crash anyway.

 

Either way, I thought they'd get around to fix the bloody flags and double reloading, and see if it persists, which clearly did not happen (I guess kids poking themselves with pixel spears are more important). Ultimately, the whole thing should be fixed on 'upper level', if one flag is too hard, what am I wasting my time on here?

 

TL;DR /WONTFIX this mod on its own will likely never cause outofmemory with LAA on even in current state of game code, the rest is beyond the amount of time/nerves I'm willing to waste for a game mod. Internal version of fix will be removed next rev, it will be up to you if what kind of crash you prefer if you're running with 100+ mods.

The double asset loading wasn't fixed? I didn't check it myself, though Cheerio did claim he had commited the fix to their internal dev version.

And by the way, Don't Starve uses Lua 5.1.4.

--[[-- The following determines the full Lua version based on bugs found in-- each version.---- See http://www.lua.org/bugs.html for details. In what follows, a comment-- such as [5.1.4].3 indicates that the bug number 3 (as listed in the link-- provided) found in version 5.1.4 was used.--]]function _G.VersionCheck()	-- Revision number.	local rev = 5	local function full_version()		return GLOBAL._VERSION.."."..rev	end	-- [5.1.4].3	if (((1 or false) and true) or false) == 1 then		-- At most.		rev = 4	else		return full_version()	end	-- [5.1.3].9	if ("abc"):byte(-5) ~= nil then		rev = 3	else		return full_version()	end	-- [5.1.2].10	do		local t = {1, 2, 3}		table.remove(t, 4)		if t[3] == nil then			rev = 2		else			return full_version()		end	end	-- [5.1.1].4	if not GLOBAL.pcall(GLOBAL.os.date, "") then		rev = 1	else		return full_version()	end	-- [5.1].4	if ("%q"):format("\r") == '"\r"' then		rev = 0	else		return full_version()	end	return full_version()end

EDIT: And oh, I could never replicate any of the HitD crashes (the 1 <-> goblin dungeon transition and the adventure mode death ones), and I tried many times. There might be something Windows specific going on.

Edited by simplex
Link to comment
Share on other sites

 

EDIT: And oh, I could never replicate any of the HitD crashes (the 1 <-> goblin dungeon transition and the adventure mode death ones), and I tried many times. There might be something Windows specific going on.

 

 

We talked about that a little bit, since I'm using win7 (32) on this laptop and she is using win7 (64)

Link to comment
Share on other sites

We talked about that a little bit, since I'm using win7 (32) on this laptop and she is using win7 (64)

For the adventure mode one, I just tried killing myself three times in a row, so I didn't test it all that much. But for the gobling dungeon case, I spent about 5 mins pretty much just punching the spacebar on dungeon entrances/exits between the 1st and 2nd dungeon levels, and nothing happened. Memory usage remained stable as well. So it seems it doesn't happen at all in my system, unless there are other factors required for it to happen (this was a fresh save, and all I was wearing was a miner hat).

Edited by simplex
Link to comment
Share on other sites

The double asset loading wasn't fixed? I didn't check it myself, though Cheerio did claim he had commited the fix to their internal dev version.

And by the way, Don't Starve uses Lua 5.1.4.

--[[-- The following determines the full Lua version based on bugs found in-- each version.---- See http://www.lua.org/bugs.html for details. In what follows, a comment-- such as [5.1.4].3 indicates that the bug number 3 (as listed in the link-- provided) found in version 5.1.4 was used.--]]function _G.VersionCheck()	-- Revision number.	local rev = 5	local function full_version()		return GLOBAL._VERSION.."."..rev	end	-- [5.1.4].3	if (((1 or false) and true) or false) == 1 then		-- At most.		rev = 4	else		return full_version()	end	-- [5.1.3].9	if ("abc"):byte(-5) ~= nil then		rev = 3	else		return full_version()	end	-- [5.1.2].10	do		local t = {1, 2, 3}		table.remove(t, 4)		if t[3] == nil then			rev = 2		else			return full_version()		end	end	-- [5.1.1].4	if not GLOBAL.pcall(GLOBAL.os.date, "") then		rev = 1	else		return full_version()	end	-- [5.1].4	if ("%q"):format("\r") == '"\r"' then		rev = 0	else		return full_version()	end	return full_version()end

EDIT: And oh, I could never replicate any of the HitD crashes (the 1 <-> goblin dungeon transition and the adventure mode death ones), and I tried many times. There might be something Windows specific going on.

 

Hmph... you may be right, he may have fixed it, tho I still 'somehow' get +200mb on load on certain games that dropped down later, but I wasn't paying attention to the full graph and moments of it. I have erroneously guessed the cause, the spikes happened after the initial drop to base mem use, not before, and not happening on new games, so it's safe to assume the cause is different in nature... well certainly works for me if he did.

 

Love that version detection lol. Wonder why not 1.5 at least? This is the only thing semi-interesting imo, but that's not memory corruption... but mixed with another issue (that i cant find for the life of me now) of gc stack size being preset at start and unable to grow dynamically due to premature optimization might cause stack overflow - showing as access violation crash. But if that was the case it would've crashed on manual gc call right before the engine cleanup too, which it doesn't. Meh.

Link to comment
Share on other sites

For the adventure mode one, I just tried killing myself three times in a row, so I didn't test it all that much. But for the gobling dungeon case, I spent about 5 mins pretty much just punching the spacebar on dungeon entrances/exits between the 1st and 2nd dungeon levels, and nothing happened. Memory usage remained stable as well. So it seems it doesn't happen at all in my system, unless there are other factors required for it to happen (this was a fresh save, and all I was wearing was a miner hat).

When we both were testing it, it was on new saves as well with min gear. I would crash every 3 to 5 enter/exit to the dungeons, I think she was a lil longer. For the Adventure mode, I will crash pretty much every time I enter, she will not crash at all. I have not tested this new update though.

Link to comment
Share on other sites

Love that version detection lol. Wonder why not 1.5 at least? This is the only thing semi-interesting imo, but that's not memory corruption... but mixed with another issue (that i cant find for the life of me now) of gc stack size being preset at start and unable to grow dynamically due to premature optimization might cause stack overflow - showing as access violation crash. But if that was the case it would've crashed on manual gc call right before the engine cleanup too, which it doesn't. Meh.

I have no idea why they don't use 5.1.5. Kevin once mentioned they wanted to switch to 5.2, but due to some code (mainly the mod loading code) depending on 5.1 only features they didn't (it would be perfectly possible to migrate the mod loading code to 5.2, though, but it'd take some refactoring); but why they didn't at least upgrade to the latest 5.1, I don't know.

But anyway, are you positive the dungeon crash still happens with the latest game version? And, if so, does running the game within cmd.exe give any final error output not put in the log? I'd like to help you guys with this issue (provided there's something that can be done without being able to tweak the engine), but since I can't replicate it I'm very limited in what I can do.

Link to comment
Share on other sites

I have no idea why they don't use 5.1.5. Kevin once mentioned they wanted to switch to 5.2, but due to some code (mainly the mod loading code) depending on 5.1 only features they didn't (it would be perfectly possible to migrate the mod loading code to 5.2, though, but it'd take some refactoring); but why they didn't at least upgrade to the latest 5.1, I don't know.

But anyway, are you positive the dungeon crash still happens with the latest game version? And, if so, does running the game within cmd.exe give any final error output not put in the log? I'd like to help you guys with this issue (provided there's something that can be done without being able to tweak the engine), but since I can't replicate it I'm very limited in what I can do.

I'll run a series of tests using the new patch in about an hour or so, in the middle of something atm.

Link to comment
Share on other sites

Nope, no console crash that I can catch. I can run the thing through VS debugger, but as I said, without symbol table I have no clue where I am or what I'm looking at. - some sort of a loop search through linked list going out of bounds... tells me much, esp since the break point is getting hit sometimes before sometimes after the actual level load (and is obviously not crashing every time, at that). Calling collectgarbage is not triggering the breakpoint at all so it's not gc itself. And of course I cant get the crash to happen when running within debugger itself - and level load takes 10 min each....

 

Unhandled exception at 0x01323212 in dontstarve.exe: 0xC0000005: Access violation reading location 0xAFBD6F84.

 

EDIT well when it crashes it's clearly executing before level even starts to load, or worldgen starts, and according to log right after the save is finished/before even gc fires up... yet when i run full debug mode it runs after all the loading goes through and i actually have the initial graphics loaded the moment the breakpoint fires up (and I can't get it to crash in debugger for the life of me). Stupid multithreading. I tried setting process affinity to just 1 core, still crashing, the exact same way, matter of fact it seems to be crashing more with just 1 core than 6.

Edited by DeathDisciple
Link to comment
Share on other sites

I'm still unable to replicate any crashes. I tried regenerating the 2nd gobling dungeon level over and over again (using the 'regen_level()' command exported by Mod Testing Toolbox), and still nothing. The only strange this I saw was this in the log:

scripts/components/seasonmanager.lua(1529,1) SPRING TIME	../mods/HeroInTheDark/modmain.lua(1549,1) in cave postinit	5	Could not find anim build barbscripts/gamelogic.lua(494,1) Loading Nav Grid	../mods/HeroInTheDark/modmain.lua(1421,1) prevcavelevel	4	scripts/components/seasonmanager.lua(1560,1) SUMMER TIME	scripts/components/seasonmanager.lua(1586,1) AUTUMN TIME	scripts/saveindex.lua(395,1) ClearCurrentResurrectors CB	
I was playing as barb, and it did show up properly... Is there something else in the 2nd goblin dungeon that could be using the barb build? If not (even though it did show up properly, which is strange) maybe it's the character prefab that needs to be loaded? You could test it by

AddPrefabPostInit("world", function()    GLOBAL.TheSim:LoadPrefabs({GLOBAL.SaveGameIndex:GetSlotCharacter()})end)
And oh, just a little something I stumbled upon. Here, in fa_dungeon_entrance.lua, you're using pairs:

			for k,v in pairs(fa_levels) do				if(v>=level) then					level_to_go=v					break				end			end
but the order in which pairs iterates is undefined behaviour, which could cause issues with a higher than needed level being picked. I think it'd be best to use ipairs instead, or to iterate through the whole table and pick the smallest level you can (if you'd prefer a more robust but more involved approach). Edited by simplex
Link to comment
Share on other sites

thats just the mismatch of the name supplied to makeplayercharacter and actual anim used (that's set in the prefab itself). I don't have the anim sources and don't want to break compat, so I'm just leaving it as is - yeah i could just rename the build but was lazy to do so.

 

As for the pairs, yeah you're right, that's one of the result of learning the language the wrong way (from klei that is). Way too many places they assume pairs are ordered (or it looked that way), I simply adopted the bad practice :p

Link to comment
Share on other sites

thats just the mismatch of the name supplied to makeplayercharacter and actual anim used (that's set in the prefab itself). I don't have the anim sources and don't want to break compat, so I'm just leaving it as is - yeah i could just rename the build but was lazy to do so.

Oh yes, the actual barb build is called "barbarian". So once again I have no guesses. And I still can't replicate it, not even once.

As for the pairs, yeah you're right, that's one of the result of learning the language the wrong way (from klei that is). Way too many places they assume pairs are ordered (or it looked that way), I simply adopted the bad practice :razz:

Yeah, they do it all the time.

Link to comment
Share on other sites

I'm still unable to replicate any crashes. I tried regenerating the 2nd gobling dungeon level over and over again (using the 'regen_level()' command exported by Mod Testing Toolbox), and still nothing.

regen_level() refuses to crash me at all... I was just running GoTo("fa_dungeon_entrance") to the last level then GoTo("fa_dungeon_exit") back up and it would crash me at some point for sure.... hmm

Link to comment
Share on other sites

regen_level() refuses to crash me at all... I was just running GoTo("fa_dungeon_entrance") to the last level then GoTo("fa_dungeon_exit") back up and it would crash me at some point for sure.... hmm

Strange, since (after deleting the level savedata) regen_level() triggers the level creation in the same way as it would otherwise, by calling StartNextInstance.

Maybe the issue is caused by asset unloading? The Lua state resets whenever you switch levels, but the engine keeps running (to some extent, likely for asset loading/handling). An engine level crash caused by weird asset issues is

Assertion "mPurgeList.empty()" failed!
which I'm guessing is a linked list kept by the game for which assets to deallocate (possibly at the end of each main loop), and that this assert runs after the game runs through this list to clean it. This might be the same linked list you saw when debugging the game code, which would suggest the issue is actually in unloading assets. But this assertion failure has always been strange. I've seen it several times, for several very distinct reasons without any clear connection to preventing assets from being deallocated (or requesting their deallocation in the "wrong time", if that's at all possible).

Maybe you have a build or bank you didn't rename, and that's causing an internal override causing the original asset to not be properly deallocated? This is just a wild guess, of course; and I don't see how MemSpikeFix would be particularly relevant to this scenario (except for changing the moment when the mod assets are loaded).

Edited by simplex
Link to comment
Share on other sites

Strange, since (after deleting the level savedata) regen_level() triggers the level creation in the same way as it would otherwise, by calling StartNextInstance.

Maybe the issue is caused by asset unloading? The Lua state resets whenever you switch levels, but the engine keeps running (to some extent, likely for asset loading/handling). An engine level crash caused by weird asset issues is

Assertion "mPurgeList.empty()" failed!
which I'm guessing is a linked list kept by the game for which assets to deallocate (possibly at the end of each main loop), and that this assert runs after the game runs through this list to clean it. This might be the same linked list you saw when debugging the game code, which would suggest the issue is actually in unloading assets. But this assertion failure has always been strange. I've seen it several times, for several very distinct reasons without any clear connection to preventing assets from being deallocated (or requesting their deallocation in the "wrong time", if that's at all possible).

Maybe you have a build or bank you didn't rename, and that's causing an internal override causing the original asset to not be properly deallocated? This is just a wild guess, of course; and I don't see how MemSpikeFix would be particularly relevant to this scenario (except for changing the moment when the mod assets are loaded).

 

 

Well, since the code, when it crashes, executes at the beginning before level loading, and can be delayed up to past the actual level/graphics/etc load when on breakpoint, and if my conclusion that it never crashes when delayed by breakpoints, it can be that whatever it is responsible for works proper only if it executes past the 'other parts' of release code, I would say the moment when it runs matters.

 

And since it clearly depends on the assets loaded at the level you leave, and does not even come to the point where next level is relevant, the thing is likely zone specific. And if Kraken's adv mode crash is related it implies that 'something' is spawning on survival too (tho I have never had a crash on survival->anything else transition).

 

 

EDIT and yes there are more animations that aren't fully renamed.... I swear I'm never leaving the original animation names again.... fixed what I saw, which 'seems' to have fixed, or helped, the adventure crash, tho I'm not too sure about the cause of said thing.

Edited by DeathDisciple
Link to comment
Share on other sites

EDIT and yes there are more animations that aren't fully renamed.... I swear I'm never leaving the original animation names again.... fixed what I saw, which 'seems' to have fixed, or helped, the adventure crash, tho I'm not too sure about the cause of said thing.

Any effects on the goblin dungeon crash?

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