Jump to content

The C.A.N.S. (Cooperative Algebraic Node Sizing) Framework


Recommended Posts

View File

Honored members of the LoversLab forums, without further ado I present to you

The C.A.N.S. Framework


(Cooperative Algebraic Node Sizing)


By Feliks, Conceptual Design by @IronRose

 

 

 

 

 

 

 

1.0.0.0 IS OUT

 

 

 


Overview
What does it do?
The C.A.N.S. Framework was developed to solve the conflicts that arise when multiple mods attempt to change the sizes of a single node. Most frequently this occurs in mods related to pregnancy, in which the belly and breast nodes are expanded. Historically, when more than one mod attempted to change the scale they would fight over said scale and it would fluctuate between the two sizes set by separate mods as they demanded a size or one of the two would simply be ignored. But no longer.

 

But what does it actually do?
Simply put C.A.N.S. should handle calls to change node scales, take all the requested sizes, find the size the node should be set to in a variety of ways (configurable by the user, defaults to highest value only)

 

Now at the moment it requires compatibility patches for each mod changing node scales but the beauty of the C.A.N.S. design is that there won't need to be serious revisions, just modified code files with updates. Feliks is currently at work creating patches for several of the more popular mods.
For the moment, the framework does nothing, and will do nothing by itself.

 

Requirements:
An updated copy of Skyrim.
Probably the XP32 Maximum Skeleton Extended by Groovtama. (Theoretically if you're running these mods with another skeleton it would work, but beware).
IF YOU'RE HAVING BUGS BE SURE TO TEST WITH THE LATEST XPMSE
RaceMenu (or NiOverride)
SkyUI (Built with v5, not tested with older versions)
SKSE (Latest version, for SkyUI)

 

Bugs:

 

MCM May not display immediately, saving and reloading fixes it in every test so far, cause unknown.
Errors from MCM script in papyrus log, seem to be related to retrieving data from NiOverride, do not affect functionality, unsure of cause.
Disclaimers:
This will do nothing without patches other than add the effect to the player.
This will do nothing without patches other than add the effect to the player
The Framework is in beta for the time being. See plans for more info.

 

 

 

DEVELOPMENT PLANS
ModEvent implementation of a basic feature for easy soft dependency
Possible expansion of which nodes are supported

 

Implementation (for modders and scripters) or "how you learned to stop worrying and write the code"

 

 

Moved to this blog post as of 1.0.0.0
Note: All current updates maintain backwards compatibility with older versions of API

 

 

Changes in latest version:

 

Version 1.0 is rewritten from scratch (again) except for the MCM.
Everything should work now, and provided there are no crippling bugs as I test to see if mods will actually work with it now, this will be the final major release.

 

1.0.0.1 is an update only needed for modders who actually take the advice I wrote in the API post, it corrects a missing return function on the registration function. Currently making sure I didn't forget any others. Expect 1.0.0.2 soon if I prove that I am terrible at this.


  • Submitter
  • Submitted
    07/13/2015
  • Category
  • Requires
    SKSE, PapyrusUtil, SkyUI(For the MCM), Mods that modify node scale.
  • Special Edition Compatible

 

Link to comment

Question is, how did you implement the averaging?

 

Is it a weighted averaging system, or just a simple straight average?

 

Because visually imo, a straight average isn't going to look so well. The increments of different types of mods should be different, like a pregnancy belly would have max increments in belly/breast vs. something like darkconsole's mana tanks mod. 

 

Edit: Or have limit ranges for certain types of mods etc...

Link to comment

what about a build up system? like if my dark elf is preggo with a child and has been in planted with chaurus eggs the belly might expand a little bit like take the biggest number and maybe add a third of the next biggest and a 1/6th of the next and so on and so forth you might have to play with that system but you get the general idea

Link to comment

Since almost all mods increase size shouldn't this just use the largest size given to it and ignore other values OR use the use the largest value and increase it by the average OR add up all the values together and have the player set his mod settings so they don't get too ridiculous?

Link to comment

OH! This looks interesting, a very nice way for the mods I love to finally agree with each other. I have suggestions on mods...

Fill Her Up, Soul Gem Oven, Milk Mod Economy, Egg Factory (because they don't allow the disabling of belly node scaling), I don't know if Hentai Pregnancy still functions, honestly, but that's there.

 

Thank you for your work!

Link to comment

Question is, how did you implement the averaging?

 

Is it a weighted averaging system, or just a simple straight average?

 

Because visually imo, a straight average isn't going to look so well. The increments of different types of mods should be different, like a pregnancy belly would have max increments in belly/breast vs. something like darkconsole's mana tanks mod. 

 

Edit: Or have limit ranges for certain types of mods etc...

 

 

what about a build up system? like if my dark elf is preggo with a child and has been in planted with chaurus eggs the belly might expand a little bit like take the biggest number and maybe add a third of the next biggest and a 1/6th of the next and so on and so forth you might have to play with that system but you get the general idea

 

 

Since almost all mods increase size shouldn't this just use the largest size given to it and ignore other values OR use the use the largest value and increase it by the average OR add up all the values together and have the player set his mod settings so they don't get too ridiculous?

 

 

OH! This looks interesting, a very nice way for the mods I love to finally agree with each other. I have suggestions on mods...

 

Fill Her Up, Soul Gem Oven, Milk Mod Economy, Egg Factory (because they don't allow the disabling of belly node scaling), I don't know if Hentai Pregnancy still functions, honestly, but that's there.

 

Thank you for your work!

 

 

This framework is sorely needed, but I wish it wasn't an average. A near full-term pregnancy offset by a fresh impregnation of chaurus eggs shouldn't make my character look like her baby's shrunk...

 

Most of what I'm seeing here are new ways to do the math. Good to know, wanted the feedback. As soon as I've got an MCM I'll implement as many ways to do this as I can. For now though, there actually is an additive instead of average version already implemented. 

 

So right now there are two versions managed by a global variable (CANSmode, 0 for average, 1 for additive) that flips between straight average and just piling them all together.

 

Things that will actually be implemented ASAP: Max sizes for nodes within CANS itself (so the mods can do all they want, but if you've got them on additive and a max of 15 they cant go past that.) and a few different ways to handle sizing.

 

The issue with weighting the average by what type of mod it is is that that would require me to rewrite the framework every time a new mod is released to recognize them categorically. I may implement a way to pass categories to the updates in the next release though if y'all think it's a good idea. Weighting based off of the largest size seems like a fairly straightforward idea and Will be implemented as soon as I can come up with a method that won't kill your computers with lag.

 

Gonna get to work on the MCM in force tomorrow. Keep the feedback rolling in guys, it's gonna shape the mod.

 

 

Edit: What do y'all think of letting the player configure the weights of individual mods themselves for the weighted average?

 

Edit 2: pretty much all of these alternatives quoted should be implemented and fully customizable by the player for the 1.0 release.

Link to comment

the 128 limit is a severe and crippling problem. i code all my mods with unlimited everything in mind, and i know a few of my SGO players probably pushing that 128 with ease. array length and max alias count are not excuses in this case, as neither should really be used for general purpose mass-npc-effecting things.

 

also, magic effects will fall off of npcs when they are not in the same zone, so thats probably going to cause lots of headache in the future.

Link to comment

Are there any plans on making mods that get "compatibility patches" react to the state of the node they are trying to update?

 

Say I have a pregnancy mod (like SGO) and Fill Her Up. To me it would be most immersive if, when both are at 50%, the belly is at its maximum. However, then FHU would have to trigger it's hardcore effects and further SGO pregnancies would have to be disabled (or some hardcore effects like forced birthing added), but that only works if those mods don't just track their own progress and update the nodes through CANS, but are actually aware that other mods conflict.

 

On the other hand, if you use the average, when will CANS become aware of a mod? If I configure FHU to only scale the belly to factor 2 and SGO to factor 6, does that result in the maximum visible inflation to be (6+2)/2, i.e. 4? And if I also use Estrus Chaurus, which is triggered rarely, is it always included (i.e. lowering the maximal visible inflation) or only when an actual Estrus impregnation happened?

 

PS: is it possible to make mods updating nodes via CANS to first "register" with the framework (like, with a name and which nodes they want to update), so you can then list those mods in an MCM to allow some configuration (like applying weights for weighted average etc)? That way, if kept abstract enough, you don't have to rewrite CANS for every mod that wants to use the framework.

 

PPS: I'm looking forward to a time when node conflicts are a thing of the past, and hope CANS can tackle the challenges.

Link to comment

 

Are there any plans on making mods that get "compatibility patches" react to the state of the node they are trying to update?

 

Say I have a pregnancy mod (like SGO) and Fill Her Up. To me it would be most immersive if, when both are at 50%, the belly is at its maximum. However, then FHU would have to trigger it's hardcore effects and further SGO pregnancies would have to be disabled (or some hardcore effects like forced birthing added), but that only works if those mods don't just track their own progress and update the nodes through CANS, but are actually aware that other mods conflict.

 

On the other hand, if you use the average, when will CANS become aware of a mod? If I configure FHU to only scale the belly to factor 2 and SGO to factor 6, does that result in the maximum visible inflation to be (6+2)/2, i.e. 4? And if I also use Estrus Chaurus, which is triggered rarely, is it always included (i.e. lowering the maximal visible inflation) or only when an actual Estrus impregnation happened?

 

PS: is it possible to make mods updating nodes via CANS to first "register" with the framework (like, with a name and which nodes they want to update), so you can then list those mods in an MCM to allow some configuration (like applying weights for weighted average etc)? That way, if kept abstract enough, you don't have to rewrite CANS for every mod that wants to use the framework.

 

PPS: I'm looking forward to a time when node conflicts are a thing of the past, and hope CANS can tackle the challenges.

Also, somewhat similarly to this, could there be a patch made that would make BeeingFemale and FillHerUp cooperate in a way that when the player is not pregnant, FillHerUp would function normally, but as the player progresses through a pregnancy, FillHerUp would accept less cum, as the belly would already be inflated?

 

So let's say the FHU limit is 3 and the temporary overfill limit is 10%, while also belly size at the end of the third trimester is 3. Could a patch mess with FHU values so receiving cum when in the last stage of pregnancy would directly fill the overfill buffer instead of piling up to another "base 1.00 + 2" on top of BF's scale of 3?

 

So

no pregnancy - FHU would have full cum "stowage" capacity

first and second trimester - FHU would gradually have to work with a decreased maximum fill size

beggining of third trimester - belly already at scale 2, FHU only gets +1 and the buffer zone to work with

end of third trimester - belly already at scale 3, FHU only has the 10% overfill buffer zone to work with

Link to comment

 

Most of what I'm seeing here are new ways to do the math. Good to know, wanted the feedback. As soon as I've got an MCM I'll implement as many ways to do this as I can. For now though, there actually is an additive instead of average version already implemented. 

 

So right now there are two versions managed by a global variable (CANSmode, 0 for average, 1 for additive) that flips between straight average and just piling them all together.

 

Things that will actually be implemented ASAP: Max sizes for nodes within CANS itself (so the mods can do all they want, but if you've got them on additive and a max of 15 they cant go past that.) and a few different ways to handle sizing.

 

The issue with weighting the average by what type of mod it is is that that would require me to rewrite the framework every time a new mod is released to recognize them categorically. I may implement a way to pass categories to the updates in the next release though if y'all think it's a good idea. Weighting based off of the largest size seems like a fairly straightforward idea and Will be implemented as soon as I can come up with a method that won't kill your computers with lag.

 

Gonna get to work on the MCM in force tomorrow. Keep the feedback rolling in guys, it's gonna shape the mod.

 

 

Edit: What do y'all think of letting the player configure the weights of individual mods themselves for the weighted average?

 

Edit 2: pretty much all of these alternatives quoted should be implemented and fully customizable by the player for the 1.0 release.

 

 

For weighting, you could use the square root of the sum of squares of all numbers.

 

Example:

 

Node Values of 2, 4 and 10.

 

22 +42+102 =

 

4+16+100 = 120

 

sqrt(120)= 10.95...

 

Opposed to the average

 

(2+4+10)/3 = 5.3...

 

This would guarantee that you are always at least bigger than your largest value unless something is decreasing the node size for some reason. In which case it weighs it towards the larger value or cancel each other out if they are the same. Just make sure to set up your maths correctly.

Link to comment

Hookmmerse is the biggest crap I have ever seen...

 

Why not use NiOverride? NetImmerse is pointless when it doesn't run fast, and when you want compatibility NiOverride is superior to draging scaling calls through a whole papyrus framework..

 

To be honest, i haven't started looking into NiOverride.  Looks like there are a lot of things it can do... therefore a lot of ways i can screw things up.  Hookmmerse was just a very basic way to fix the issue of multiple mods trying to override each other for boobs/bum/belly nodes.  I don't doubt that someone with a lot more skill can do it more efficiently and/or effectively.

 

I hope i did not come across dismissive of the C.A.N.S. framework, as i am anything but.  I'm really hopeful that it will be a more integrative way of dealing with this issue.

Link to comment

 

Hookmmerse is the biggest crap I have ever seen...

 

Why not use NiOverride? NetImmerse is pointless when it doesn't run fast, and when you want compatibility NiOverride is superior to draging scaling calls through a whole papyrus framework..

 

To be honest, i haven't started looking into NiOverride.  Looks like there are a lot of things it can do... therefore a lot of ways i can screw things up.  Hookmmerse was just a very basic way to fix the issue of multiple mods trying to override each other for boobs/bum/belly nodes.  I don't doubt that someone with a lot more skill can do it more efficiently and/or effectively.

 

I hope i did not come across dismissive of the C.A.N.S. framework, as i am anything but.  I'm really hopeful that it will be a more integrative way of dealing with this issue.

 

NiO is more than just transforms, transforms are just a part of it.

 

Hookmmerse is a shitty workaround, it does not fix anything, it just screws more up, you can believe me on this I know more then enough screnarios it will just make the mod fail.

 

A lot more skill? efficiently/effectively? ...sounds like expired who did NiOverride that does the whole scaling management in native code, that means outside of that slow papyrus vm.

 

I my eyes people who try to fix NetImmerse mods don't understand that NetImmerse was not designed for multiple mods to acess and change the same node indepentent of each other.

 

@Feliks

This is noting against your work or so, coding work and so is solid, but NetImmerse is a dead horse, and pretty much any mod that still uses NetImmerse not for the sake of speed or because the data is thrown away anyway like the Sanguine scaling in SD+. NetImmerse is just a fail to use in the first place.

Link to comment

the 128 limit is a severe and crippling problem. i code all my mods with unlimited everything in mind, and i know a few of my SGO players probably pushing that 128 with ease. array length and max alias count are not excuses in this case, as neither should really be used for general purpose mass-npc-effecting things.

 

also, magic effects will fall off of npcs when they are not in the same zone, so thats probably going to cause lots of headache in the future.

 

I'd already be very happy, if my mods worked correctly with each other for the PC. The mods also working on NPCs correctly would be a really nice bonus, but not my priority. So, I'm still pretty excited about this project.

 

 

 

 

 

Most of what I'm seeing here are new ways to do the math. Good to know, wanted the feedback. As soon as I've got an MCM I'll implement as many ways to do this as I can. For now though, there actually is an additive instead of average version already implemented. 

 

So right now there are two versions managed by a global variable (CANSmode, 0 for average, 1 for additive) that flips between straight average and just piling them all together.

 

Things that will actually be implemented ASAP: Max sizes for nodes within CANS itself (so the mods can do all they want, but if you've got them on additive and a max of 15 they cant go past that.) and a few different ways to handle sizing.

 

The issue with weighting the average by what type of mod it is is that that would require me to rewrite the framework every time a new mod is released to recognize them categorically. I may implement a way to pass categories to the updates in the next release though if y'all think it's a good idea. Weighting based off of the largest size seems like a fairly straightforward idea and Will be implemented as soon as I can come up with a method that won't kill your computers with lag.

 

Gonna get to work on the MCM in force tomorrow. Keep the feedback rolling in guys, it's gonna shape the mod.

 

 

Edit: What do y'all think of letting the player configure the weights of individual mods themselves for the weighted average?

 

Edit 2: pretty much all of these alternatives quoted should be implemented and fully customizable by the player for the 1.0 release.

 

 

For weighting, you could use the square root of the sum of squares of all numbers.

 

Example:

 

Node Values of 2, 4 and 10.

 

22 +42+102 =

 

4+16+100 = 120

 

sqrt(120)= 10.95...

 

Opposed to the average

 

(2+4+10)/3 = 5.3...

 

This would guarantee that you are always at least bigger than your largest value unless something is decreasing the node size for some reason. In which case it weighs it towards the larger value or cancel each other out if they are the same. Just make sure to set up your maths correctly.

 

 

This sounds like a pretty good solution for the math problem to me. It's very likely this would be my favorite selection. Followed by simply adding up values. The average thing doesn't seem to make much sense to me.

Link to comment

OH! This looks interesting, a very nice way for the mods I love to finally agree with each other. I have suggestions on mods...

 

Fill Her Up, Soul Gem Oven, Milk Mod Economy, Egg Factory (because they don't allow the disabling of belly node scaling), I don't know if Hentai Pregnancy still functions, honestly, but that's there.

 

Thank you for your work!

 

yes hentai pregnancy still functions I use it in my game

Link to comment

Hookmmerse is the biggest crap I have ever seen...

 

Why not use NiOverride? NetImmerse is pointless when it doesn't run fast, and when you want compatibility NiOverride is superior to draging scaling calls through a whole papyrus framework..

 

From what I understand NIOverride requires the mod author to use it instead of netimmerse, and that just hasn't happened for some mods? Or am I missing something.

 

If so, Hookmmerse helps me, as a user, to actually use those mods together (and has been for a while now).

Link to comment

 

Hookmmerse is the biggest crap I have ever seen...

 

Why not use NiOverride? NetImmerse is pointless when it doesn't run fast, and when you want compatibility NiOverride is superior to draging scaling calls through a whole papyrus framework..

 

From what I understand NIOverride requires the mod author to use it instead of netimmerse, and that just hasn't happened for some mods? Or am I missing something.

 

If so, Hookmmerse helps me, as a user, to actually use those mods together (and has been for a while now).

 

You miss the fact that Hookmmerse manipulates other people scripts to replace Netimmerse function calls with hookimmerse, and in some cases breaks them, because the Hookmmerse functions do not behave like netimmerse functions do.

Link to comment

 

 

Hookmmerse is the biggest crap I have ever seen...

 

Why not use NiOverride? NetImmerse is pointless when it doesn't run fast, and when you want compatibility NiOverride is superior to draging scaling calls through a whole papyrus framework..

 

To be honest, i haven't started looking into NiOverride.  Looks like there are a lot of things it can do... therefore a lot of ways i can screw things up.  Hookmmerse was just a very basic way to fix the issue of multiple mods trying to override each other for boobs/bum/belly nodes.  I don't doubt that someone with a lot more skill can do it more efficiently and/or effectively.

 

I hope i did not come across dismissive of the C.A.N.S. framework, as i am anything but.  I'm really hopeful that it will be a more integrative way of dealing with this issue.

 

NiO is more than just transforms, transforms are just a part of it.

 

Hookmmerse is a shitty workaround, it does not fix anything, it just screws more up, you can believe me on this I know more then enough screnarios it will just make the mod fail.

 

A lot more skill? efficiently/effectively? ...sounds like expired who did NiOverride that does the whole scaling management in native code, that means outside of that slow papyrus vm.

 

I my eyes people who try to fix NetImmerse mods don't understand that NetImmerse was not designed for multiple mods to acess and change the same node indepentent of each other.

 

@Feliks

This is noting against your work or so, coding work and so is solid, but NetImmerse is a dead horse, and pretty much any mod that still uses NetImmerse not for the sake of speed or because the data is thrown away anyway like the Sanguine scaling in SD+. NetImmerse is just a fail to use in the first place.

 

 

I honestly didn't know there was a better way to it. I've never made a mod that plays with scales and I generally don't use them. I just looked through the source code for a few plug ins to see how they did it. 

So I'll change from NetImmerse to NiOverride for the next release. Time to do some research.

On that note, I'm assuming you've read my code, any other issues you notice that I should fix?

 

 

 

For weighting, you could use the square root of the sum of squares of all numbers.

 

Example:

 

Node Values of 2, 4 and 10.

 

22 +42+102 =

 

4+16+100 = 120

 

sqrt(120)= 10.95...

 

Opposed to the average

 

(2+4+10)/3 = 5.3...

 

This would guarantee that you are always at least bigger than your largest value unless something is decreasing the node size for some reason. In which case it weighs it towards the larger value or cancel each other out if they are the same. Just make sure to set up your maths correctly.

 

 

Yeah, the straight average was honestly a very foolish way to go about doing this. I'll add this to the methods implemented in the 1.0 release.

 

 

 

Are there any plans on making mods that get "compatibility patches" react to the state of the node they are trying to update?

 

Say I have a pregnancy mod (like SGO) and Fill Her Up. To me it would be most immersive if, when both are at 50%, the belly is at its maximum. However, then FHU would have to trigger it's hardcore effects and further SGO pregnancies would have to be disabled (or some hardcore effects like forced birthing added), but that only works if those mods don't just track their own progress and update the nodes through CANS, but are actually aware that other mods conflict.

 

On the other hand, if you use the average, when will CANS become aware of a mod? If I configure FHU to only scale the belly to factor 2 and SGO to factor 6, does that result in the maximum visible inflation to be (6+2)/2, i.e. 4? And if I also use Estrus Chaurus, which is triggered rarely, is it always included (i.e. lowering the maximal visible inflation) or only when an actual Estrus impregnation happened?

 

PS: is it possible to make mods updating nodes via CANS to first "register" with the framework (like, with a name and which nodes they want to update), so you can then list those mods in an MCM to allow some configuration (like applying weights for weighted average etc)? That way, if kept abstract enough, you don't have to rewrite CANS for every mod that wants to use the framework.

 

PPS: I'm looking forward to a time when node conflicts are a thing of the past, and hope CANS can tackle the challenges.

Also, somewhat similarly to this, could there be a patch made that would make BeeingFemale and FillHerUp cooperate in a way that when the player is not pregnant, FillHerUp would function normally, but as the player progresses through a pregnancy, FillHerUp would accept less cum, as the belly would already be inflated?

 

So let's say the FHU limit is 3 and the temporary overfill limit is 10%, while also belly size at the end of the third trimester is 3. Could a patch mess with FHU values so receiving cum when in the last stage of pregnancy would directly fill the overfill buffer instead of piling up to another "base 1.00 + 2" on top of BF's scale of 3?

 

So

no pregnancy - FHU would have full cum "stowage" capacity

first and second trimester - FHU would gradually have to work with a decreased maximum fill size

beggining of third trimester - belly already at scale 2, FHU only gets +1 and the buffer zone to work with

end of third trimester - belly already at scale 3, FHU only has the 10% overfill buffer zone to work with

 

 

Theoretically this should be possible. I'd have to look at how those mods are coded exactly to give you any more information though.

 

Are there any plans on making mods that get "compatibility patches" react to the state of the node they are trying to update?

 

Say I have a pregnancy mod (like SGO) and Fill Her Up. To me it would be most immersive if, when both are at 50%, the belly is at its maximum. However, then FHU would have to trigger it's hardcore effects and further SGO pregnancies would have to be disabled (or some hardcore effects like forced birthing added), but that only works if those mods don't just track their own progress and update the nodes through CANS, but are actually aware that other mods conflict.

 

On the other hand, if you use the average, when will CANS become aware of a mod? If I configure FHU to only scale the belly to factor 2 and SGO to factor 6, does that result in the maximum visible inflation to be (6+2)/2, i.e. 4? And if I also use Estrus Chaurus, which is triggered rarely, is it always included (i.e. lowering the maximal visible inflation) or only when an actual Estrus impregnation happened?

 

PS: is it possible to make mods updating nodes via CANS to first "register" with the framework (like, with a name and which nodes they want to update), so you can then list those mods in an MCM to allow some configuration (like applying weights for weighted average etc)? That way, if kept abstract enough, you don't have to rewrite CANS for every mod that wants to use the framework.

 

PPS: I'm looking forward to a time when node conflicts are a thing of the past, and hope CANS can tackle the challenges.

 

The bit about two mods talking to and working with each other, should be fairly straightforward to make in the compatibility patches, but you'd have to wait until the other patches were out to see what the handle the mod is using within CANS is.

The averaging definintely needs an overhaul, that's the general consensus here. Mods actually do have to register to start influencing things and then they remove themselves when they're done. This is so temporary things like EC won't constantly bring your average down.

I hope this tackles the challenges too, that was the plan.

 

the 128 limit is a severe and crippling problem. i code all my mods with unlimited everything in mind, and i know a few of my SGO players probably pushing that 128 with ease. array length and max alias count are not excuses in this case, as neither should really be used for general purpose mass-npc-effecting things.

 

also, magic effects will fall off of npcs when they are not in the same zone, so thats probably going to cause lots of headache in the future.

 

Honestly arrays seemed like the best way to handle the pointers, but my knowledge is based mostly on other languages. The 128 limit came from the max array size, but that's really simple to work around, it just didn't seem like a pressing issue considering nothing actually talks to C.A.N.S. yet but I will be extending that in the next release. If you look through my code you'll notice there's some weird set up with the node size array too, that's all getting changed too to run from separate arrays with the extended limit as well.

Would you happen to know a good way around the magic effect's falling off the NPC's? 

 

Most of the suggestions I've seen so far are better ways to implement sizing, at least math is easy to code though.

Link to comment

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
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use