Jump to content

Photo

Screens remember which enemies are killed


  • Please log in to reply
7 replies to this topic

#1 Mitchfork

Mitchfork

    no fun. not ever.

  • Contributors
  • Real Name:Mitch
  • Location:Alabama

Posted 15 November 2020 - 03:32 PM

The current ZC behavior is that screens remember how many enemies are killed, but not which ones in particular, so enemies are always spawned starting at the top of the list.  Depending on how the enemy list for the screen is ordered, this can result in weird behavior where powerful enemies will respawn if weaker enemies are left alive, or where screens can be cheesed by killing weaker enemies and reloading the screen to despawn powerful enemies.

 

I think it would be a great quest rule for screens to remember which enemies were killed and selectively spawn them instead of going through the list in order.


  • Nathaniel, Sheik, Avaro and 4 others like this

#2 Bagu

Bagu

    Fandomizer

  • Members
  • Real Name:A.I. Bot Bottomheimer
  • Location:Germany

Posted 15 November 2020 - 03:43 PM

I love this idea



#3 Emily

Emily

    Scripter / Dev

  • ZC Developers

Posted 16 November 2020 - 10:49 PM

Not likely to happen. The reason it only remembers the number is because that's easier to store- to store which, would require more data be stored per screen. Even if it only meant adding 8 bits, that then is 8 bits per screen for 134 screens (there are 6 in the screen 80 row, right?). 8 bits per screen for 134 screens for 255 maps means adding 273360 bits of data to memory / save files - that's 34.17 kilobytes.

 

Now, that's just for adding 8 bits. It would likely require 16 bits for this - so double that to 68.34 kilobytes.

 

Adding anything to screens is difficult, as it means using a lot of memory.


  • Twilight Knight and Mitchfork like this

#4 bigjoe

bigjoe

    Apprentice

  • Members

Posted 17 November 2020 - 07:13 PM

Depending on if you have some Screen->D registers available, you could probably script this.



#5 Mitchfork

Mitchfork

    no fun. not ever.

  • Contributors
  • Real Name:Mitch
  • Location:Alabama

Posted 18 November 2020 - 05:30 PM

Depending on if you have some Screen->D registers available, you could probably script this.

Probably, but you'd have to have some system to set when enemies should normally respawn, handle events that should reset spawning, etc.  Ideally this would interface with the standard editor flags for enemy spawning rules and enemy placement flags, etc. etc.

 

Since I haven't looked into this I don't even know if ZScript has access to things like "how many monsters are supposed to spawn on a a screen right now" or if you can interrupt the engine spawning with your own system easily.

 

I think you could do it with a single Screen->D register and bitwise compares (ints support up to 32 bits of binary data), so that's not necessarily a problem, it just seems like a lot of work to get something that works better than the default system.


Edited by Ebola Zaire, 18 November 2020 - 05:36 PM.


#6 NoeL

NoeL

    Legend

  • Members
  • Real Name:Jerram

Posted 18 November 2020 - 07:43 PM

Now, that's just for adding 8 bits. It would likely require 16 bits for this - so double that to 68.34 kilobytes.

It's 2020. Why are we bothered about adding a measly 68kb to a save file?
  • Mitchfork likes this

#7 Emily

Emily

    Scripter / Dev

  • ZC Developers

Posted 19 November 2020 - 06:58 AM

It's 2020. Why are we bothered about adding a measly 68kb to a save file?

Not just to the save file, but also to the loaded memory. Which has a hard limit that, if reached, will cause ZC/ZQ to instantly crash. ZC is still a 32-bit program, so it has a 32-bit memory page limit. Until such a time as we upgrade to 64bit (which is a REALLY BIG process), we have to be very careful about memory.


  • NoeL likes this

#8 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 20 November 2020 - 07:27 PM

Memory isn't the issue here. Engine logic for enemies would need a major rewrite for this to work, and that is well outside of the present scope of the software. 

 

A script that writes to Screen->Enemy[] would solve this if you want to have greater control over it. Note that enemy spawning ends when a list hits an index with a value of 0. So, if you have a list like this:

 

67

68

0

69

 

Enemy 69 will not spawn.

 

If the list starts with 0, then nothing will spawn. This is why the engine rearranges the enemy lists every time something dies, shifting everything downward to an empty slot. 




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users