PDA

View Full Version : 2.x vs 3.x



Tamamo
06-22-2016, 10:26 AM
I've decided to take it upon my shoulders to start acting as an ambassador between 3.x developers and the 2.future fork.

Here are the 3.x threads
Gleeoks Original Proposal (http://armageddongames.net/showthread.php?97159-Next-Gen-ZC-(Otherwise-known-as-ZC3-0))
Angelscript Proposal (removed for now) (http://armageddongames.net/showthread.php?97457-Plans-for-the-future-part-1-AngelScript)
Saffith's current goals (http://armageddongames.net/showthread.php?97589-So-what-are-the-plans-for-3-x)
What Gleeok has been working on (http://armageddongames.net/showthread.php?97512-Script-Drawing-Improvements)

Here are the plans for 2.x (http://armageddongames.net/showthread.php?97486-ZC-2-future-Development-Plans-To-Do)

Important: All of this is quoted from saffith here (http://armageddongames.net/showthread.php?97516-FFC-jumps-into-a-changer&p=911583&viewfull=1#post911583).

My only goal right now is to clean up the code so that it's possible to make bigger changes without everything falling apart. Anything else comes after that. Even the AngelScript integration was meant to be to that end.

I don't consider backward compatibility optional. I don't want to put out 3.0 and have it be unable to play a large subset of quests, especially recent ones. If it goes into 2.x, it goes into 3.x.

I don't even see PMs here half the time. vB isn't so good with the notifications.

Seems... mhm "We have come to terms"

Dimentio
06-22-2016, 09:21 PM
Not to be rude, but have there not been issues between you and Zoria in the past? Not to mention you kept dismissing a bug most of us though was a bug as "not a bug" simply because it could be worked around. Are you sure that you can handle being an ambassador?

Anyways, I'm neutral on whether to continue 2.X or 3.X. 2.X has everything set up, so it would probably be faster, and more people would be more comfortable with the familiarity. However, 3.X would give us a lot more room to work with, and would be easier, as we'd know what each and every variable would do. So whatever the majority feels, I guess. Maybe a rewrite of 2.x? :P

Tamamo
06-22-2016, 09:42 PM
Dimentio
If you are depressed, you are living in the Past. If you are anxious, you are living in the future. If you are at peace you are living in the moment. – Lao Tzu
That is all I have to say about the matter. And you assume I'm the only person whose had problems with ZoriaRPG in the past. I assure you I am not.

ZoriaRPG
06-22-2016, 09:45 PM
It would be nice, but in reality, it means holding off making anything new, or useful, for two years, or more. There's no reason that changes can't be reintegrated, if the changes are logged. In fact, most of what I've been doing should be reusable as-is, either way.

It cames down to:

1. New functions, tied into the ZScript bytecode tables.
1a. Drawing related.
1b. System-environment related.
2. Bison/Flex improvements and expansions.
3. Class object->Property additions.

By the time we get 'round to doing some of the things on the list, if there's a cleaner basecode, we'd use that, but there's no valid reason to put what we're doing on hiatus for an indefinite duration, nor does any one of us want to sit down and rewrite all of the enemy, or Link, collision, or weapon handling at present.

FFC improvements, as I mentioned, should in theory be a drop-in replacement for either branch.

In fact, in the process of expanding various components, it is possiblethat they'll be cleaned up. I'd like to make the process of adding ZScript instructions clearer, too.

You also need to keep in mind that the rewrites might fail. There is no way to determine hw long it will take for a 3.x rewrite to be stable, at all, if ever. I was around for the 2.11/2.5 rewrite. It was a period of eight years of darkness, and I eventually gave up feeling that it was vapourware.

A fair amount of what I'm doing, is finishing features that were planned, or intended for 2.5, and left unfinished.

You also need to pay attention to the general lethargy in the userbase. We really have had little to no influx of new users, since 2.50 was released. New releases, even if imperfect, revitalise the community, by drawing interest of new users, and by reigniting interest of present users; as they try to top one-another in 'showing off' what they can do with the new/updated widgets.

I'm watching every day as users fade out, and no-one replaces them; the general activity tapers off, and interest wanes. In two or three years, with nothing new or exciting to offer, there won't be anyone left to use or appreciate a cleaner codebase. People want features to compete with other tools, and without them, they'll just use other software. Once that happens, good luck getting them back.

Dimentio
06-22-2016, 09:48 PM
Oh no, I never said you were the only one. I'm just hoping that there won't be any biases or such.

Anyways, I think a rewrite would be the best thing so far, if only becauseit would allow us to get out of the mess that 2.5 is. However, I think we should keep most of the things 2.5 has, like ZScript. If we were to remove ZScript, that could turn off plenty of people.

Again, though, 2.5 would make a new update faster, without turning off anybody. I think that cleaning up 2.5 would be a rather nice goal.

Tamamo
06-22-2016, 10:14 PM
It would be nice, but in reality, it means holding off making anything new, or useful, for two years, or more. There's no reason that changes can't be reintegrated, if the changes are logged. In fact, most of what I've been doing should be reusable as-is, either way.

It cames down to:

1. New functions, tied into the ZScript bytecode tables.
1a. Drawing related.
1b. System-environment related.
2. Bison/Flex improvements and expansions.
3. Class object->Property additions.

By the time we get 'round to doing some of the things on the list, if there's a cleaner basecode, we'd use that, but there's no valid reason to put what we're doing on hiatus for an indefinite duration, nor does any one of us want to sit down and rewrite all of the enemy, or Link, collision, or weapon handling at present.

Yeah I can understand that. It's a pain in the ass to work with. >_>


FFC improvements, as I mentioned, should in theory be a drop-in replacement for either branch.
My thoughts exactly.


In fact, in the process of expanding various components, it is possible that they'll be cleaned up. I'd like to make the process of adding ZScript instructions clearer, too.
Definitely needs to be made clearer. I refuse to touch that stuff.


You also need to keep in mind that the rewrites might fail. There is no way to determine how long it will take for a 3.x rewrite to be stable, at all, if ever. I was around for the 2.11/2.5 rewrite. It was a period of eight years of darkness, and I eventually gave up feeling that it was vapourware.
Yeah it's sad but true. It's going to be a long tunnel, but it's sure in hell gonna be worth it.


A fair amount of what I'm doing, is finishing features that were planned, or intended for 2.5, and left unfinished.
This is also my one of my goals as well. So I agree that this stuff needs to be done. Have you taken a look at my Mirror Shielded Enemies code yet?


You also need to pay attention to the general lethargy in the userbase. We really have had little to no influx of new users, since 2.50 was released. New releases, even if imperfect, revitalise the community, by drawing interest of new users, and by reigniting interest of present users; as they try to top one-another in 'showing off' what they can do with the new/updated widgets.
Speaking of widgets; Saffith, at least I think it was him anyways, has been replacing the allegro GUI with GTK. Now isn't that fancy, Now quest rules have tabs!


I'm watching every day as users fade out, and no-one replaces them; the general activity tapers off, and interest wanes. In two or three years, with nothing new or exciting to offer, there won't be anyone left to use or appreciate a cleaner codebase. People want features to compete with other tools, and without them, they'll just use other software. Once that happens, good luck getting them back.
I agree with you there, more of the reason we need somebody willing to call you all to a round table and have a cup coffee and talk things over.


Oh no, I never said you were the only one. I'm just hoping that there won't be any biases or such.
Hahaha, I do not discriminate don't worry I treat everyone fairly. I work with ZoriaRPG more then you think. ;)
Speaking of which ZoriaRPG I'm planning on rewriting weapons next month to make it less of a mess. I'm going to add inheritance. In otherwards their will now be a class for each weapon type. Their might be some Parser changes so I'll get together with you on that later on.


Anyways, I think a rewrite would be the best thing so far, if only because it would allow us to get out of the mess that 2.5 is. However, I think we should keep most of the things 2.5 has, like ZScript. If we were to remove ZScript, that could turn off plenty of people.

Again, though, 2.5 would make a new update faster, without turning off anybody. I think that cleaning up 2.5 would be a rather nice goal.
We will cross the bridge of removing ZScript when we get their. Most likely it isn't gonna happen. In fact I would be against it.

ZoriaRPG
06-23-2016, 05:34 AM
This is also my one of my goals as well. So I agree that this stuff needs to be done. Have you taken a look at my Mirror Shielded Enemies code yet?


I did. I'm not sure why you didn't just set a flag for what it can reflect, and then just treat reflected weapons exactly as shielded enemies treat boomerangs, except that you replace the weapon with a ew type. (i.e. kill the lw, make an ew, set its dir to reverse.) That method is already there, so, why not re-use it?

It would be nice if weapons returned if they were blocked, or reflected by a shield (for ew and lw) though. That should be a unique deadstate across the board.



Speaking of widgets; Saffith, at least I think it was him anyways, has been replacing the allegro GUI with GTK. Now isn't that fancy, Now quest rules have tabs!


We really need to stop using QRs, and make any new rule a quest setting, that isn't tied to these old values. As I said, what I was thinking, is that we make a Game->Settings[] array, with each setting using one index (easier to parse in iteration than binary flags in one index). Read that array in functions that (at present) read quest rules. Thus, the old rules will turn into boolean values in that array, and can be read, and set by script. This means that we can do things, such as changing scrolling methods at different points in a quest.

I'm not sure what shifting to GTK will do, but it should potentially fix some display concerns.



I agree with you there, more of the reason we need somebody willing to call you all to a round table and have a cup coffee and talk things over.


Well, you pretty much said you were disinterested in what we're planning, which is why you weren't involved. The rest of us discuss these things regularly, and we pass on ideas, and our plans, to Gleeok; but it's all based on 2.5/2.6, and as you've said multiple times that you had no interest in working on that, ...

You also refuse to use Skype, which is where we tend to congregate. I wouldn't mind if the SysOps added a 2.6 board as a subforum though.



Hahaha, I do not discriminate don't worry I treat everyone fairly. I work with ZoriaRPG more then you think. ;)
Speaking of which ZoriaRPG I'm planning on rewriting weapons next month to make it less of a mess. I'm going to add inheritance. In otherwards their will now be a class for each weapon type. Their might be some Parser changes so I'll get together with you on that later on.


If I wrote the new setter/getter stuff right, that'll make a good example on adding new ZScript instructions.

You'll need to detail what you want to accomplish with this, and what you're changing. You're pretty much saying that you'd need me to write a unique class interface for each type, which would be pretty redundant, and time-consuming to create, so tell me what advantages separating *weapons into unique classes would have. I think it'll make a huge mess, as it means that we'd need a specific type for each class, so instead of eweapon and lweapon, we'd need 20+ classes for each in ZScript. That is a whopper, in terms of adding it, and I don't see the practicality of making a user remember all of that; plus, it'll break things LRC.

I'm not sure that anyone is too distressed over these sharing a class, otherwise. It's convenient. The main problems seem to stem from using script types, and some properties of other classes that can't be changed; and of course the ypes that are part of the Link class. I'd suggest giving priority to those, so that swords, hookshots, staves, wands, and whatnot can be created, and modified. Making the ladder an lweapon, might be extremely amusing; but it would be more painful than almost anything else I've mentioned to date. Hah. )

Unless you mean that you're making them properties of the main class, and giving them their own properties. That might work, but again, I try not to overly muck with the things that do work at present. This is the sort of thing that I'd push to 2.6 or later, and not 2.55, as it'd require a lot of rewrites, and testing. Our main objective is to push out a new, stable release, with features that hve been repeatedly requested, or that those of us in the group want pretty badly.



We will cross the bridge of removing ZScript when we get their. Most likely it isn't gonna happen. In fact I would be against it.

(We'll burn those bridges when the enemies are at the gate.) I've given some thought to using flex/bison to con vert ZScript to AS at some point, but if AS has an in-build ability to write parsing defs, which I believe it does, it could be done more elegantly. The main thing, is that you'd need to add the ZScript types to AS, grandfathering them (old_float, old_int, old_bool, old_sring), then tell the AS interpreter how to handle them. The rest of the syntax should otherwise be identical.

Gleeok
06-23-2016, 06:18 AM
Speaking of which ZoriaRPG I'm planning on rewriting weapons next month to make it less of a mess. I'm going to add inheritance. In otherwards their will now be a class for each weapon type. Their might be some Parser changes so I'll get together with you on that later on.

The problem with the complexity of ZC isn't actually because some things are hidden behind layers of needless abstractions or shitty virtual functions, or, other things are just plain data where runaway procedures are free to alter anything and everything they feel like. The problem is more because of state. ZC is a ginormous twisted mass of wires and circuits that breaths fire on elephants and then eats their burning flesh before laughing at you and then exploding. Simply put, everything is already doing too much. Whether you have a switch or a vtable it's not going to change much. More abstractions never actually solve any real problems, they simply abstract them further, making them even harder to deal with later. I would argue that any reasonable improvement to a problem of 'too much' (state, bloat, special cases, years of bug-fixes, etc) is simply less code, not more. Sounds simple, but it took me years to figure it out.

Tamamo
06-23-2016, 08:19 AM
The problem with the complexity of ZC isn't actually because some things are hidden behind layers of needless abstractions or shitty virtual functions, or, other things are just plain data where runaway procedures are free to alter anything and everything they feel like. The problem is more because of state. ZC is a ginormous twisted mass of wires and circuits that breaths fire on elephants and then eats their burning flesh before laughing at you and then exploding. Simply put, everything is already doing too much. Whether you have a switch or a vtable it's not going to change much. More abstractions never actually solve any real problems, they simply abstract them further, making them even harder to deal with later. I would argue that any reasonable improvement to a problem of 'too much' (state, bloat, special cases, years of bug-fixes, etc) is simply less code, not more. Sounds simple, but it took me years to figure it out.

You're going to like this Gleeok, trust me. Something needs to be done with that convoluted mess. And it matches Saffith's goal on making the codebase more manageable. So everyone wins.

ZoriaRPG
06-23-2016, 04:57 PM
You're going to like this Gleeok, trust me. Something needs to be done with that convoluted mess. And it matches Saffith's goal on making the codebase more manageable. So everyone wins.

One thing to note, is that even if it doesn;t make the cut for 2.,5x, or 2.6x, or even 3.x, you can always make a custom fork that uses it, and if people like it, or want it in a main version, we can add it. This is the type of thing, that I'd want user opinions on, before committing it, anyhow; and of course, I'd need to know how it will change the interface (ZScript instructions) for handling the objects. If it's transparent to the user, and only adds options for them, that would be fantastic.
Gleeok: Ypu forgot, that it explodes into inverted butterflies, made of smoggy rainbows.

Tamamo
07-08-2016, 09:29 AM
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?

Saffith
07-08-2016, 02:55 PM
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.


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.

Gleeok
07-08-2016, 09:14 PM
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.

ZoriaRPG
07-11-2016, 01:53 AM
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.

Gleeok
07-11-2016, 04:26 AM
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.

ZoriaRPG
07-11-2016, 04:56 AM
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.

Tamamo
07-11-2016, 10:46 AM
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."

Tamamo
07-11-2016, 05:24 PM
edit: Fixed

Tamamo
07-12-2016, 01:38 PM
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?

ZoriaRPG
07-12-2016, 02:59 PM
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.

Tamamo
07-12-2016, 04:22 PM
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
07-12-2016, 05:40 PM
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
07-12-2016, 06:36 PM
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
07-13-2016, 12:43 AM
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
07-13-2016, 01:18 AM
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
07-13-2016, 02:06 AM
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... ? :odd: 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. :P Ha...jk.

No, but seriously I'm not sure.

Tamamo
07-13-2016, 02:15 AM
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
07-13-2016, 02:44 AM
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
07-13-2016, 03:02 AM
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
07-13-2016, 03:45 AM
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?

Gleeok
07-13-2016, 04:24 AM
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?

Oh. Well, npc is already the uid, not the pointer. So for example; npc->isValid() is exactly the same as calling guys->isValidUID(*(long*)&npc_as_seen_by_script);

refInfo are just ids:




class refInfo
{
public:
dword pc; //current command offset

long d[8]; //d registers
long a[2]; //a regsisters (reference to another ffc on screen)
byte sp; //stack pointer for current script
dword scriptflag; //stores whether various operations were true/false etc.

byte ffcref, idata; //current object pointers
dword itemref, guyref, lwpn, ewpn;


refInfo();
void Clear();
};


Also, I have no idea why the refs stuff are not a union. As a general rule never ask me such things. :P

Tamamo
07-13-2016, 10:32 AM
Here's Plan A why Plan A didn't come before Plan B i have no Idea.

1. Add a reasonable amount of comments to the weapons file to make it easier to read.
2. qr_WPNANIMFIX: This allows animated weapons to be offset correctly. It was never implemented)
3. ewFLAME2TRAIL: Current issue is that this weapon is like ewFLAME2 it does not die after a set amount frames.
4. ewICE: Link knockback should be disabled when link is frozen.

This stuff is low priority right now however.

Tamamo
07-13-2016, 04:47 PM
Gleeok
sprite_list::swap isn't broken, It just isn't implemented. :p
Not going to bother commiting this Saffith since it's most likely wrong. But I tried to fix it.


bool sprite_list::swap(int a,int b)
{
// Re-added for now, but stil unimplemented.
return false;

sprite *c = sprites[a];
sprites[a] = sprites[b];
sprites[b] = c;
uids[a] = sprites[a]->getUID();
uids[b] = sprites[b]->getUID();
// checkConsistency();
return true;
}

Gleeok
07-13-2016, 07:47 PM
That would only work if you changed lookups to be O(n), which kind of defeats the purpose. The reason swap even exists is because some enemies try to change the draw order of thiings, so it's actually pretty trivial. I just haven't looked at the exact behavior of this to confirm that children uids are always greater than the parent (which I would assume). If that's the case swap would simply be:



void sprite_list::swap(int a, int b)
{
swap(sprites[a], sprites[b]);
swap(sprites[a]->uid, sprites[b]->uid);
}

Tamamo
07-13-2016, 08:39 PM
That would only work if you changed lookups to be O(n), which kind of defeats the purpose. The reason swap even exists is because some enemies try to change the draw order of thiings, so it's actually pretty trivial.

You're mistaken my dear It has less to do with drawing order and more with keeping the sprite list organized the dead arms of manhandla are pushed to the end for example that way their are no gaps.

Gleeok
07-14-2016, 12:02 AM
Which is even more silly - swapping around dead enemies instead of removing them when sprtie->animate will end up just deleting them. Anyway, it's not that it's difficult to put in swap, I'd just rather get rid of it altogether which is why I haven't fixed it yet.

Saffith
07-14-2016, 12:31 AM
Best I can tell at the moment, they do it because the dying segments hang around for several frames, and that's how they avoid counting them repeatedly. That should be very easy to fix.

Tamamo
07-14-2016, 08:42 AM
Which is even more silly - swapping around dead enemies instead of removing them when sprtie->animate will end up just deleting them. Anyway, it's not that it's difficult to put in swap, I'd just rather get rid of it altogether which is why I haven't fixed it yet.

It's sillier then you think. Patras and Manhandlas are broken solely because this is missing. Fucking enemy code. Once I get to rewriting it, we shouldn't need it anymore. How do you like them apples.

ZoriaRPG
07-14-2016, 02:56 PM
It's sillier then you think. Patras and Manhandlas are broken solely because this is missing. Fucking enemy code. Once I get to rewriting it, we shouldn't need it anymore. How do you like them apples.

I certainly do. Please remember to ensure that you have a specific flag or something for an enemy 'core' for manhandlas, gleeoks and such. The core needs to be an npc with all the normal attributes and properties, so it's possible to get its x/y and apply things to it.

Gleeok bodies with a flipping hitbox would be nice.
Gleeok How big is your hitbox?