• Announcements

    • Anapsi

      Logging in   05/10/2017

      If you had an account and can't log in as of 5/9/17, this may be because of a change in logins with new forum software. You can log in using your publicly displayed name (not your username) or your email address and the password you used before.   If you have problems with this, please ask any of the mods or admins. 
Sign in to follow this  
Followers 0
sylae

Development
Environmental SDFs

4 posts in this topic

Having SDFs that auto-populate to relevant info could make it easier to make more dynamic special node chains. Some ideas I have:

 

  • SDF_CURR_COORD_X: The party/active PC's current X coord
  • SDF_CURR_COORD_Y: The party/active PC's current Y coord
  • SDF_CURR_TERRAIN: The terrain type currently being stood on by the party/active PC
  • SDF_LAST_RESULT: For SDF logic, the last returned answer (1=true/0=false)

 

Obviously there are more potential ideas here, I just vomited out some off the top of my head.

Share this post


Link to post
Share on other sites

I think I was going to use reserved pointers for accessing these values; for example, -10 (placed in any slot in a special node) might be substituted with the party's x coordinate while -11 is their y coordinate. Pointers do reference SDFs, so there might be a real SDF underlying the reserved pointer (in the 300+ range), but I think it might be better for the reserved pointers to access such values more directly. I think it depends whether we'd want to use the values in SDF calculations; though, if we do, we could have a special case for pointers whereby SDF coordinates -x,-x refers to the value of pointer x (so, -10,-10 is the pseudo-SDF containing their x coordinate).

 

There's at least a partial implementation of these pointers in the code; I'm not sure if it's actually being used in the special node logic yet.

 

 

I personally don't think it's a particularly great idea to be using reserved SDFs to store any sort of information. The game already uses SDFs with x-values in the range 300..310 to store settings, information about a split party, and possibly other data, but I think it would be better to move this data into a dedicated area so that the range 300..310 (and more!) can be freed up for use by scenario designers. Though of course, we can expand the SDF array in the other dimension too, which is probably more than enough for most uses you could imagine; but expanding in both directions may be better for SDF organization.

 

Other ideas for info to be made available:

  • The current coordinate could in some situations be populated with the coordinates of a monster, for example if a node is called when the monster dies or when the party sees the monster. Or there could be a separate place for this information, if you think there might be cases when both details are useful.
  • We could have special items (maybe even ordinary items) that, when used, require the player to target a space; then the targeted space would be made available in this way.
  • The currently active creature (for "Affect PC" nodes).
  • Current town and outdoor section?

Share this post


Link to post
Share on other sites

that special pointer idea is pretty nifty.

 

i knew about the 300-310 range SDFs being internal use, but are they just used like that because jeff couldn't be bothered to give those settings their own construct in the save file, essentially? If so yeah, it would probably make sense to reserve the whole Stuff Done array to designers, and maybe add another array for internal stuff.

 

hell, just copy-paste and make an "Internal Stuff Done" or something. I mean it's probably not ideal but i don't think filesize/memory limits are really a concern at the current state of computing, especially at the level of resources BoE uses right now :p

Share this post


Link to post
Share on other sites

i knew about the 300-310 range SDFs being internal use, but are they just used like that because jeff couldn't be bothered to give those settings their own construct in the save file, essentially?

Yeah, I think that's the only reason for it.

 

hell, just copy-paste and make an "Internal Stuff Done" or something. I mean it's probably not ideal but i don't think filesize/memory limits are really a concern at the current state of computing, especially at the level of resources BoE uses right now :p

Eh, I don't think it'd be hard to actually give each of those things its own special place in the party record. And while it's true that filesize/memory limits aren't much of a concern, I think I'd like to eventually turn the SDF array into a sparse array. (It's already saved that way, incidentally.)

 

Actually, I'm a little worried about BoE's performance at the moment, though that's more related to graphics than memory usage.

Share this post


Link to post
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
Sign in to follow this  
Followers 0