Printable View
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
Angelscript Proposal (removed for now)
Saffith's current goals
What Gleeok has been working on
Here are the plans for 2.x
Important: All of this is quoted from saffith here.
Seems... mhm "We have come to terms"Quote:
Originally Posted by Saffith
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
@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.
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.
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.
Yeah I can understand that. It's a pain in the ass to work with. >_>Quote:
Originally Posted by ZoriaRPG
My thoughts exactly.Quote:
FFC improvements, as I mentioned, should in theory be a drop-in replacement for either branch.
Definitely needs to be made clearer. I refuse to touch that stuff.Quote:
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.
Yeah it's sad but true. It's going to be a long tunnel, but it's sure in hell gonna be worth it.Quote:
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.
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?Quote:
A fair amount of what I'm doing, is finishing features that were planned, or intended for 2.5, and left unfinished.
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!Quote:
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 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.Quote:
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.
Hahaha, I do not discriminate don't worry I treat everyone fairly. I work with ZoriaRPG more then you think. ;)Quote:
Originally Posted by Dimentio
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.
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.Quote:
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.
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?Quote:
Originally Posted by Tamamo
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.
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.Quote:
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 not sure what shifting to GTK will do, but it should potentially fix some display concerns.
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, ...Quote:
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.
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.
If I wrote the new setter/getter stuff right, that'll make a good example on adding new ZScript instructions.Quote:
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.
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'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.Quote:
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.
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.Quote:
Originally Posted by Tamamo
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.Quote:
Originally Posted by Gleeok
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.Quote:
Originally Posted by Tamamo
@Gleeok : Ypu forgot, that it explodes into inverted butterflies, made of smoggy rainbows.
@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?
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:
How come you rolledback your changes to the item logic. Specifically the hookshot for example.
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:
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
Giving up on ffSOLId already, are we? Not that I blame you.Quote:
Originally Posted by Tamamo
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.Quote:
Originally Posted by ZoriaRPG
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.Quote:
Originally Posted by Gleeok
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.
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.Quote:
Originally Posted by ZoriaRPG
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?
I'm also going to need a breakdown of the new UID system.Quote:
Originally Posted by Tamamo
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.
@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:
@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.Quote:
Originally Posted by Gleeok
@Gleeok mentioned the memory pool stuff the other day; and he mentioned dynamic ffc creation by script, and I approve of this mightily.Quote:
Originally Posted by Tamamo
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.
@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.
@ZoriaRPG @Grayswandir @Dimentio @Gleeok
Updated First Post, and for good reason. @Saffith broke it down for us in another thread. Not sure why though?
I don't know what I'm disagreeing with, but okay.Quote:
Originally Posted by Tamamo
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.Quote:
Originally Posted by ZoriaRPG
No, but seriously I'm not sure.
@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.
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.
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.Quote:
Originally Posted by Tamamo
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?
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);Quote:
Originally Posted by ZoriaRPG
refInfo are just ids:
Also, I have no idea why the refs stuff are not a union. As a general rule never ask me such things. :PCode:
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();
};
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.
@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.
Code: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;
}
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:
Code:void sprite_list::swap(int a, int b)
{
swap(sprites[a], sprites[b]);
swap(sprites[a]->uid, sprites[b]->uid);
}
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.Quote:
Originally Posted by Gleeok
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.
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.
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.Quote:
Originally Posted by Gleeok
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.Quote:
Originally Posted by Tamamo
Gleeok bodies with a flipping hitbox would be nice.
@Gleeok How big is your hitbox?