2.x vs 3.x

[Tamamo]

@ZoriaRPG
Please explain what you mean by the memory pool stuff.
FFCs don't need hit boxes although they could use Drawing and Effect offsets. Which would achieve a similar effect that and the ability to increase the size of ffc effect range from 1 to 64 regardless of ffc size. And no @Moosh , I'm not giving you bigger ffcs. :tard:

[Gleeok]

@ZoriaRPG
UIDs might change again internally. You shouldn't even have to know how they are managed; that's kinda the whole point. Before, an UID was a dynamically allocated node kept sorted using a self balancing tree. Now they use contiguous blocks of memory, are stored in order, and retrieval by a simple 'divide and conquer' algorithm. Later, they might be something else entirely. I sorta broke enemy::swap already, so we'll see.

I would actually prefer it if all the OOP cruft could be removed from the sprite-entity stuff.

[ZoriaRPG]

@ZoriaRPG
UIDs might change again internally. You shouldn't even have to know how they are managed; that's kinda the whole point. Before, an UID was a dynamically allocated node kept sorted using a self balancing tree. Now they use contiguous blocks of memory, are stored in order, and retrieval by a simple 'divide and conquer' algorithm. Later, they might be something else entirely. I sorta broke enemy::swap already, so we'll see.

I would actually prefer it if all the OOP cruft could be removed from the sprite-entity stuff.

Well, I was hoping that at some point, users would be able to reference an npc by its UID, as that shouldn't change as long as it remains valid, and might be useful for specific effects targeting; but I can see how that could be a problem if this is in flux.

@ZoriaRPG
Please explain what you mean by the memory pool stuff.
FFCs don't need hit boxes although they could use Drawing and Effect offsets. Which would achieve a similar effect that and the ability to increase the size of ffc effect range from 1 to 64 regardless of ffc size. And no @Moosh , I'm not giving you bigger ffcs. :tard:

@Gleeok mentioned the memory pool stuff the other day; and he mentioned dynamic ffc creation by script, and I approve of this mightily.

The advantage of a hitbox is that you can have an ffc with an EffectWidth and EffectHeight, that is entirely unlinked to its hitbox. That allows more freedom without any great sacrifice. I'm not sure that I see a problem with enlarging the maximum ffc size (combos) either, except that it's more work. We certainly don;t need any of these things in the next main build, but they might be interesting for the future.

[Tamamo]

@Saffith
Committed the ffc changes.
@Gleeok
Gleeok with all do respect, the object-oriented programming has a purpose. When it's used fucking correctly that is. Eventually most of the core entities will be replaced with angelscript anyways. This is just an inbetween to make that easier to do in the future. Cause doing it straight from point A to B is not going to happen, trust me on that one. So yeah, that's all I have to say on that response. You have your opinions. I have mine. We'll just agree to disagree I guess.

[Tamamo]

@ZoriaRPG @Grayswandir @Dimentio @Gleeok
Updated First Post, and for good reason. @Saffith broke it down for us in another thread. Not sure why though?

[Gleeok]

@Saffith
Gleeok with all do respect, the object-oriented programming has a purpose. When it's used fucking correctly that is. Eventually most of the core entities will be replaced with angelscript anyways. This is just an inbetween to make that easier to do in the future. Cause doing it straight from point A to B is not going to happen, trust me on that one. So yeah, that's all I have to say on that response. You have your opinions. I have mine. We'll just agree to disagree I guess.

I don't know what I'm disagreeing with, but okay.

Well, I was hoping that at some point, users would be able to reference an npc by its UID, as that shouldn't change as long as it remains valid, and might be useful for specific effects targeting; but I can see how that could be a problem if this is in flux.
.

But npcs are already referenced by UIDs... ? I think I must be misunderstanding you somehow. If you want to give me the short version of what you were trying to do that might help. If you mean to make it so pointers are always valid that's actually easy enough but then you'll have to convince Tamamo that inheritence as an object model over data layout through inheritence makes it implausible. Ha...jk.

No, but seriously I'm not sure.

[Tamamo]

@Gleeok
Let's make sure we're on the same page.
I want to make the weapon types into classes that inherit from the weapon class.
Currently there is only one class for weapons, and a bunch of spaghetti code switch statements of course. You should know by now how much I hate it when people abuse those. When we have multiple functions and need to run the same switch statement every damn time it kind of defeats the purpose of c++ supporting inheritance, you know what I mean.

Actually Enemies UIDs are broken, someone broke enemy::Swap, wait I think it was you actually lol. The sprite list code is next on my my todo list followed by guys code. The enemy code is terrible (just look at the wizzrobe code for example) so I'm holding off as long as possible.

Also, we might as well change this thread topic to "ZC Development Discussion'"

BTW I'm in chat pretty late into the mornings EST if you ever want to talk about ZC stuff feel free to message me.

[Gleeok]

Yeah, I know what you mean. I'm just skeptical that anything can actually be "simplified' simply by adding abstract methods and moving existing logic into them. I'm all for single-responsibility, composition, sane API design etc. and all that jazz, but from experience I don't think I've ever been able to take any higher level gameplay or logic code and turn it OO in the past and feel like I've been even remotely productive somehow. :/ But maybe it's just me.


UIDs are my list of stuff to look over, I just haven't had the time yet.

[Tamamo]

Yeah that's the problem I'm facing too. ZC was written by PM during the dark ages when a lot of people where still pretty loyal to C Style programming making rewriting this thing a bitch and a half. Which is why I want to gut the weapon code and start from scratch.

So let me ask you this, if you we're to restructure the weapon code, what would you do differently? It would be nice to see it from your perspective.

[ZoriaRPG]

Yeah that's the problem I'm facing too. ZC was written by PM during the dark ages when a lot of people where still pretty loyal to C Style programming making rewriting this thing a bitch and a half. Which is why I want to gut the weapon code and start from scratch.

So let me ask you this, if you we're to restructure the weapon code, what would you do differently? It would be nice to see it from your perspective.

@Tamamo The only major thing I'd do differently, is rip the Link class weapons into standard *weapons, so that users can create, and manipulate them. I don't have a qualm with how weapons work at present, and I think that adding npcdata and flushing out itemdata are far more valuable to the user.

I have to agree with @Gleeok here. I think this is unwise. Better to make a wholly new class of object and allow people to use it. It also comes off to me as convoluted, not simplified, and the way you've been describing it, would break all compatibility with existing scripts, which is just a 'no'.

Keep in mind that if you write a new weapon system, it won't make it in before 2.6x. I'd write it as a side-by-side, keeping what we have, and adding a new system, especially if I have to make it work with Zscript, as every present aspect needs to be retained, including every bleeping quirk, to avoid breaking lots of stuff. From the sound of this, is is entirely incompatible with the present stuff, and even if it was compatible, the weapon changes will alter their behaviour, which is also a 'no' unless you want to make a huge pile of QRs to ensure quests don't break. (Again, a 'no'.)

If this is purely for 3.x AngelScript 'whatever', then remember that we're doing 2.53 right now, so while it'll be god to prepare some of that 3.x stuff, you're making something that we won't integrate for quite a while, so it'll sit in its own branch and be tested until the time comes to do something with it.

A new object type, we can add support for that in the bytecode, and tables...but until you outline exactly how these new weapon objects would work, and detail the point of them, it's just sounding like lots of extra work for a theoretical performance boost, or easier reading for people used to wacky cpp stuff instead of C-stuff.

Tell us please, exactly what your goals are, other than nt using big case-switch blocks, that we use everywhere anyway. I don't object to a new system for 3.x. I don't even object to an additional system for 2.x, but implementing both the present *weapon stuff, and whatever you're doing side-by-side doesn't have a pleasant flavour.


@Gleeok : I mean to reference an npc via its UID with something akin to LoadNPC(). At present, we can only affect an npc, by using its screen index, which changes. I also need to add typecasting so that a user can read an npc pointer as an int, unless you want to do that. I'm not sure if npcdata will need UIDs, ut I know of no way to write to, or read from any npc data without using the screen index ID.

Being able to do something like uid->X without needing to load the npc from its screen index into a pointer would be wicked useful.

Did you review the files?