General Development


debugman18
 Share

Recommended Posts

I feel so sneaky. Grab the latest version of the U&A code, run any save with it enabled, Save & Quit, disable U&A and try loading that save.


Secondly, wormholes seem to break if they are moved. I'm not sure what's up with that, because persistdata is working.

Wormholes have some tight integration with worldgen and engine-level map properties, which may lead to several issues (probably the case here). I think it's best to keep them unmovable. It would be quite OP to be able to use the white staff for this anyway.

Link to comment
Share on other sites

I feel so sneaky. Grab the latest version of the U&A code, run any save with it enabled, Save & Quit, disable U&A and try loading that save.


Wormholes have some tight integration with worldgen and engine-level map properties, which may lead to several issues (probably the case here). I think it's best to keep them unmovable. It would be quite OP to be able to use the white staff for this anyway.

That's impressive. Dragons, indeed.

 

65214c8c4ef6c1057295f4c9b734d71fd1fc5fe6

  • Like 1
Link to comment
Share on other sites

:razz:

Feel free to call me arrogant, but I'm truly amazed with myself for figuring out a way to run code with a mod disabled.

I don't feel the urge to at all. That's definitely nothing to scoff at. I'm surprised you even tried, actually. :p

 

 

Wormholes have some tight integration with worldgen and engine-level map properties, which may lead to several issues (probably the case here). I think it's best to keep them unmovable. It would be quite OP to be able to use the white staff for this anyway.

True enough. There would definitely be shenanigans to be had with that. On that account, is there anything that should be excluded from the white staffs abilities? It's fun going around moving things (not to mention transporting things from the cloudrealm down) but I'm sure there are some things that have no business being moved. It should be noted that it currently moves entities as well. Perhaps that could be stripped from the white staff, and applied to a different one. I'm not sure. It feels kind Ghostbusters-ish being able to box up enemies.

Link to comment
Share on other sites

True enough. There would definitely be shenanigans to be had with that. On that account, is there anything that should be excluded from the white staffs abilities? It's fun going around moving things (not to mention transporting things from the cloudrealm down) but I'm sure there are some things that have no business being moved. It should be noted that it currently moves entities as well. Perhaps that could be stripped from the white staff, and applied to a different one. I'm not sure. It feels kind Ghostbusters-ish being able to box up enemies.

Only wormholes come to mind. Maybe creatures should be excluded, but it does sound fun moving them in boxes :razz:.

Link to comment
Share on other sites

Do you can make a link to page with updating version of U&A for ppl as me? Please? It would be great. Also I found problem: U&A + other mods when loading save after making it and re-opening it overloads RAM... Checked it. I turned off U&A and then my mods worked. And vice versa.

Edited by Minik435
Link to comment
Share on other sites

Do you can make a link to page with updating version of U&A for ppl as me? Please? It would be great. Also I found problem: U&A + other mods when loading save after making it and re-opening it overloads RAM... Checked it. I turned off U&A and then my mods worked. And vice versa.

 

Wow. Never had that happen.

 

As for an updating version of U&A, you could always just clone out git repo, however, it isn't guaranteed to work for you. Only the packaged builds are appropriate for distribution, and even they aren't up to alpha yet, which is when we plan on uploading a stable, playable version of the mod. We're getting there, don't worry. We've made a lot of progress in the last couple of weeks.

 

Anyways, here's the most recent packaged version of the mod. If there's any bugs, just report them here, with a pastebin link of your log.txt, and if you can, tell us how to replicate it.

 

@simplex

I managed to get item names to work with the packages, however, it's still not quite there. For example, if I package a closed sinkhole, it doesn't give me the name. (I'm sure there are other examples.) If I package an object that has no name, it does the same thing. (Which makes sense, I guess.) Any tips for that? I managed to get the item name to show by changing the prefab name through string.upper and getting the value for the key (from the STRINGS.NAMES table) if the key matches the uppercased prefab name.

 

Hmm, and I still need to add onload and onsave.

UpAndAway-prealpha.zip

Edited by debugman18
Link to comment
Share on other sites

Also I found problem: U&A + other mods when loading save after making it and re-opening it overloads RAM... Checked it. I turned off U&A and then my mods worked. And vice versa.

 

If you're referring to this, I think you're just running out of memory. U&A is a big mod.

I managed to get item names to work with the packages, however, it's still not quite there. For example, if I package a closed sinkhole, it doesn't give me the name. (I'm sure there are other examples.) If I package an object that has no name, it does the same thing. (Which makes sense, I guess.) Any tips for that? I managed to get the item name to show by changing the prefab name through string.upper and getting the value for the key (from the STRINGS.NAMES table) if the key matches the uppercased prefab name.

 

Hmm, and I still need to add onload and onsave.

I'll work some on them.

Link to comment
Share on other sites

 

If you're referring to this, I think you're just running out of memory. U&A is a big mod.

I'll work some on them.

 

I actually got most of them to work (moleworms, for instance), as well as implemented onsave and onload, but now I'm fighting with the sinkhole status. I'll finish up what I can and push.

 

Edit: And done. As far as I know, everything should have a name, unless it's unnamed, in which case it is a "Mysterious Package". I haven't made it so the things you package maintain their anims, though (mainly the new tree type) so if you still want to improve it, there's that. Also, the new RoG prefixes aren't implemented in it either. I'm pretty content with it as is, though.

 

@simplex

It seems the beanstalk sapling bug is back. I don't know why it isn't consistent, though.

Edited by debugman18
  • Like 1
Link to comment
Share on other sites

@simplex

It seems the beanstalk sapling bug is back. I don't know why it isn't consistent, though.

Yeah, the issue is here (in main.lua):

local function OnUnlock(inst)    local tree = SpawnPrefab("beanstalk_sapling")    if not inst.components.lock:IsLocked() and tree and inst then        tree.Transform:SetPosition(inst.Transform:GetWorldPosition())        print "Unlocked"    end    --_G.DeleteCloseEntsWithTag(inst, "mound", 2)    --inst:Remove()    --print("Mound deleted.")    --print "Locked"end
If inst.components.lock:IsLocked() returns true, then you are not setting a position to tree, but you have already spawned it (and you don't remove it), so it gets placed in the map origin.

The thing is you shouldn't be calling inst.components.lock:IsLocked() at all. You're already setting this function up as an unlock callback. If you check the lock component, you'll see that Lock:SetLocked (called within Lock:OnLoad) first calls the callbacks, and then sets self.islocked. So in this case the callback is running, but since the test if failing the entity doesn't get a position.

Also, the vanilla lock component is bugged. Inside Lock:SetLock, it's accessing self.locked, instead of the correct self.islocked. But this shouldn't be an issue for our current use of it.

In any case, even with this issue fixed, whenever the save loads another sapling will be spawned, so I'm removing the mound after the unlock.

I just pushed the changes. The issue should be fixed now.

Link to comment
Share on other sites

I actually got most of them to work (moleworms, for instance), as well as implemented onsave and onload, but now I'm fighting with the sinkhole status. I'll finish up what I can and push.

I implemented the changes to packages/white staff, though currently you can pack pretty much everything (including other packages).

dZWPj2u.png

jKRdZN7.png

Wormholes currently can be packaged, but this doesn't work all too well. You can successfully pack and unpack them during the same session, but Save & Quitting the game with a wormhole package makes it unusable (the wormhole can still be unpacked, it just doesn't work anymore). But anyway, things like Wormholes should be excluded anyway.

Now I'm unsure about how to approach the packing. Should we really allow almost anything to be packaged, only disallowing a select few (like wormholes and ancient altars)? Or should we be more restrictive and only allow some things? I'm thinking the first approach may lead to a bunch of unforeseen unwanted scenarios.

Currently you can disallow packing in two ways (I implemented a Packer component): adding the "unpackable" tag to an entity or setting a custom function, i.e.

inst:AddComponent("packer")inst.components.packer:SetCanPackFn(function(target, inst)    return target.prefab ~= "wormhole"end)
EDIT:

@debugman18

I renamed the tag I mentioned above from "unpackable" to "nonpackable", for clarity and, well, accuracy of meaning. :razz:

(damn it, English does need some associativity rules)

Edited by simplex
  • Like 1
Link to comment
Share on other sites

Other things I think should not be able to be packed using the white staff: pig king and shopkeeper. And I'm not too sure either way about things like sinkholes, walrus camps, maxwell door and the wooden thing.

We should also keep in mind that, at the expense of a white staff charge, it allows storing a full backpack inside a container, such as another backpack, by packing the first one.

Opinions on how the packing mechanic should behave are appreciated.

Link to comment
Share on other sites

Other things I think should not be able to be packed using the white staff: pig king and shopkeeper. And I'm not too sure either way about things like sinkholes, walrus camps, maxwell door and the wooden thing.

We should also keep in mind that, at the expense of a white staff charge, it allows storing a full backpack inside a container, such as another backpack, by packing the first one.

Opinions on how the packing mechanic should behave are appreciated.

So, so far on our blacklist is: Walrus camp, pig king, shopkeeper, sinkhole, maxwell door, wooden thing, and wormhole.

 

I think these should be added to that list: Rope (caves), beanstalk (and exit),  and hound mounds. Not sure what else to add.

 

Oh, and things with the staticchargeable component crash if moved from the cloudrealm. :razz:

 

Balance-wise, I think that the uses should be brought down to 3, from 5, and there should be a health cost equal to one or two attacks (based on the entities attack damage) to use the staff on a live entity. That way, you're not tempted to package the deerclops if it's about to smash you into pieces (as an example).

Edited by debugman18
  • Like 1
Link to comment
Share on other sites

Balance-wise, I think that the uses should be brought down to 3, from 5, and there should be a health cost equal to one or two attacks (based on the entities attack damage) to use the staff on a live entity. That way, you're not tempted to package the deerclops if it's about to smash you into pieces (as an example).

The health cost would also apply to non hostile mobs like Beefalo and Pigs? Or should they just aggro after being released because they are pissed from being packaged?

Link to comment
Share on other sites

The health cost would also apply to non hostile mobs like Beefalo and Pigs? Or should they just aggro after being released because they are pissed from being packaged?

Hmm. It could probably be applied only if their target is the player. I like the idea of being able to move mobs, but it's tricky to do right, because people will use things like this in ways we may not expect.

Link to comment
Share on other sites

but it's tricky to do right, because people will use things like this in ways we may not expect.

That is the salt in the soup of developer and gamer interaction! :grin:

 

 

Edit: Has anybody else the problem that if you follow a topic you actually don't get an info for being quoted in that thread anymore?

Edited by MilleniumCount
Link to comment
Share on other sites

That is the salt in the soup of developer and gamer interaction! :grin:

 

 

Edit: Has anybody else the problem that if you follow a topic you actually don't get an info for being quoted in that thread anymore?

I had that issue for some time, but it seems to have resolved itself.

 

Edit: Which is odd, actually, because I just noticed I'm not following this topic. o.o I guess since I started the thread, it gives me notifications.

Edited by debugman18
Link to comment
Share on other sites

So, so far on our blacklist is: Walrus camp, pig king, shopkeeper, sinkhole, maxwell door, wooden thing, and wormhole.

I think these should be added to that list: Rope (caves), beanstalk (and exit), and hound mounds. Not sure what else to add.

What about obelisks, and the Epilogue items?
Link to comment
Share on other sites

What about obelisks, and the Epilogue items?

 

I don't see the harm in obelisks. There's only so many in a world, and really, they keep you in if you try to use them as walls. I mean, what's the potential for abuse?

 

As for the epilogues items, if you can get to them with a white staff, go for it. ;)

 

Remember, adventure mode starts you off with nothing, and there is no beanstalk in adventure mode, therefor no white staff.

 

  • Like 1
Link to comment
Share on other sites

So, so far on our blacklist is: Walrus camp, pig king, shopkeeper, sinkhole, maxwell door, wooden thing, and wormhole.

 

I think these should be added to that list: Rope (caves), beanstalk (and exit),  and hound mounds. Not sure what else to add.

 

Oh, and things with the staticchargeable component crash if moved from the cloudrealm. :razz:

 

Balance-wise, I think that the uses should be brought down to 3, from 5, and there should be a health cost equal to one or two attacks (based on the entities attack damage) to use the staff on a live entity. That way, you're not tempted to package the deerclops if it's about to smash you into pieces (as an example).

 

What about making hostile entities non-packagable? I'd prefer the staff to be used to help avoid threat long-term, not short-term. I also feel that the varied health damage on certain things might confuse the player if they don't understand what's going on, and that they may fear using the staff. We at least want the players to use everything we create, and I'd worry that this may confuse them enough to put them off using it. 

  • Like 1
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