2.x vs 3.x

@Saffith ,
How come you rolledback your changes to the item logic. Specifically the hookshot for example.
With the changes to UID handling that means the patra and manhandla bugs are broken because the new code isn't in yet.
As for FFC flags that have come to my concern.

• ffSWAPNEXT seems bugged btw. I think it's if condition statement is checking for the wrong flag, it checks for ffSWAPPREV. Also yeah we should probably change it so they only effect speed. Ugh... probably gonna need a quest rule for it though.
• ffCHANGESPEED: We could still get that implemented, but i personally think it's way too much trouble unless people seriously want to have that feature. It's still up in the air and you probably agree.
• ffSOLID: Not happening, I'm not going through that hell again, god only knows wtf it would break if not ZC itself.

@ZoriaRPG
That sounds like a LSD trip actually, mhm....

@Gleeok
If I was to ask you kindly to rewrite ffc so we can 64 for per screen would you do it?

Quote:

---

How come you rolledback your changes to the item logic. Specifically the hookshot for example.

---

The goal for the existing objects should be to move them out of the way without making major changes to their behavior. A bit of cleanup is okay, but those went too far. And they weren't really a great way of doing things in the first place.

Quote:

---

If I was to ask you kindly to rewrite ffc so we can 64 for per screen would you do it?

---

As they are now, that's a lot of additional memory usage - about another megabyte per map. Maybe if they're reworked a bit.

Quote:

---

Originally Posted by Tamamo

@Gleeok
If I was to ask you kindly to rewrite ffc so we can 64 for per screen would you do it?

---

No. Too much other stuff gets priority. I'd never get around to it.

Quote:

---

Originally Posted by Tamamo

@Saffith ,
How come you rolledback your changes to the item logic. Specifically the hookshot for example.
With the changes to UID handling that means the patra and manhandla bugs are broken because the new code isn't in yet.
As for FFC flags that have come to my concern.

• ffSWAPNEXT seems bugged btw. I think it's if condition statement is checking for the wrong flag, it checks for ffSWAPPREV. Also yeah we should probably change it so they only effect speed. Ugh... probably gonna need a quest rule for it though.
• ffCHANGESPEED: We could still get that implemented, but i personally think it's way too much trouble unless people seriously want to have that feature. It's still up in the air and you probably agree.
• ffSOLID: Not happening, I'm not going through that hell again, god only knows wtf it would break if not ZC itself.

@ZoriaRPG
That sounds like a LSD trip actually, mhm....

@Gleeok
If I was to ask you kindly to rewrite ffc so we can 64 for per screen would you do it?

---

Giving up on ffSOLId already, are we? Not that I blame you.

Without some kind of general memory management, ffcs can't be increased like that. They are the single biggest RAM sink in all of ZC. Note that nobody wants to rewrite them... We'd be better off making a new class of objects that behaves like them, but is called only on demand.

Quote:

---

Originally Posted by ZoriaRPG

Giving up on ffSOLId already, are we? Not that I blame you.

Without some kind of general memory management, ffcs can't be increased like that. They are the single biggest RAM sink in all of ZC. Note that nobody wants to rewrite them... We'd be better off making a new class of objects that behaves like them, but is called only on demand.

---

There's a few ideas for them. I'm probably just leaning towards a simple FFCMemoryPool since the total number of ffcs is known at quest load time, and then a single ScreenFFC object. Naively, mapscreen would then need 64 bytes of indices to ffcs instead of whatever it is now; you can get rid of that also but it's already going to be a pain in the ass updating ZQuest so I'd call 64 bytes a big win.


I suppose allowing 256 FFCs on screen at a time isn't that difficult either, provided that FFCs 32 - 255 can only be created directly with scripts... although I'll have to double-check the workings of ffc stuff because I can't remember atm.

Quote:

---

Originally Posted by Gleeok

There's a few ideas for them. I'm probably just leaning towards a simple FFCMemoryPool since the total number of ffcs is known at quest load time, and then a single ScreenFFC object. Naively, mapscreen would then need 64 bytes of indices to ffcs instead of whatever it is now; you can get rid of that also but it's already going to be a pain in the ass updating ZQuest so I'd call 64 bytes a big win.


I suppose allowing 256 FFCs on screen at a time isn't that difficult either, provided that FFCs 32 - 255 can only be created directly with scripts... although I'll have to double-check the workings of ffc stuff because I can't remember atm.

---

255, I suppose you mean, as ffc 0 is NULL. I'm perfectly fine with them being script-created, as the general application for them is for script-created objects. Sounds quite good, in fact.

For ffc solidity, i was thinking that giving ffcs a (separate) hitbox, and adding hitwidth, hitheight, hitoffset, and such, would allow setting ffSOLID as a simple flag, treating the hitbox of the ffc as a solid object. That would allow the user some freedom in making the ffc partially solid, without turning ffc solidity into a disaster.

Keeping this separate from EffectWidth/Height and such would be critical.

Quote:

---

Originally Posted by ZoriaRPG

Giving up on ffSOLId already, are we? Not that I blame you.

Without some kind of general memory management, ffcs can't be increased like that. They are the single biggest RAM sink in all of ZC. Note that nobody wants to rewrite them... We'd be better off making a new class of objects that behaves like them, but is called only on demand.

---

It's more so how much stuff require the 8x8 grid to function correctly. Link, certain weapons, enemies, a couple combos (none of which actually work as ffcs) rely on the grid to function correctly.

addendum...
About the fCHANGESPEED flag, since that is the default we could make the flag do the opposite actually that is to say, prevent it from happening. That way you can simply change the combo/cset when it touches a changer and not have to keep track of it's speed. "Which would be good for a ffc that decelerates."

edit: Fixed

@ZoriaRPG
I think ffcs are almost done, all that is left to do is figure out what to do about the Change Speed flag.
@Saffith
IIRC Link's tile is determined when he is drawn. Since that is the case, we could just abstract (more layers of that shit. Just what we don't need) Link's drawing code into it's own file. Thoughts? Also have we decided how we're going to handle the UIDs yet? Manhandla and Patra are still broken lol.
@Gleeok
So I've been thinking of refining the weapons so they're object-oriented and don't make use of a bunch of damn switch statements. That was a terrible idea btw. The code for weapons however is such a clusterfuck I'm about ready to just rewrite them from scratch. You okay with this?

Quote:

---

Originally Posted by Tamamo

@ZoriaRPG
I think ffcs are almost done, all that is left to do is figure out what to do about the Change Speed flag.
@Saffith
IIRC Link's tile is determined when he is drawn. Since that is the case, we could just abstract (more layers of that shit. Just what we don't need) Link's drawing code into it's own file. Thoughts? Also have we decided how we're going to handle the UIDs yet? Manhandla and Patra are still broken lol.
@Gleeok
So I've been thinking of refining the weapons so they're object-oriented and don't make use of a bunch of damn switch statements. That was a terrible idea btw. The code for weapons however is such a clusterfuck I'm about ready to just rewrite them from scratch. You okay with this?

---

I'm also going to need a breakdown of the new UID system.

I was thinking of adding OriginalTile to Link so that we can change his tile reliably. Does that sound fair?

ffcs almost done... I wish. If Gleeok manages to add that memory pool stuff, hell yes. Not sure how to resolve grid issues. I think we'd need a whole extra set of CanWalk and other checks just for ffc solidity, and I still want to add hitboxes.