Jump to content

keira
 Share

Recommended Posts

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.

Link to comment
Share on other sites

  • 2 weeks later...

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?

Link to comment
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

Link to comment
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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...