Closed deonix37 closed 5 years ago
Please be more specific. What engine bugs? What did you do to cause them? And did you ask for modding help and share your code first to make sure you're not doing anything unintended?
Remember what happened last time, when most of your "engine bugs" were just you not using Lua properly :V
No u
1) Arena's black area (the inside) and the arena's white borders are located on different layers.
Screenshot
2) Changing an enemy sprite's layer breaks it's binding to arena, i.e. it stops following it.
monster['monstersprite'].layer = 'Top'
3) BindToArena
's second argument doesn't affect anything. Setting it to false is supposed to keep a monster's sprite above the arena.
monster.Call('BindToArena', true, false)
4) The way sprite pivot works. In docs it says all sprites have xpivot and ypivot set to 0.5 by default. But in fact ypivot is set to 0, because sprites rotate relative to their bottom. Changing pivot 0.5 does the job, but then the sprite shifts to bottom for no reason.
What I've found within 10 minutes in CYF. Btw, Alt+Enter is broken again.
What else do we have?
Oh, and at that time I failed to properly report the ppcollission bug that I struggled with, but it seems to be fixed now. But because of that everyone still thinks that I am a brain damaged guy, who sucks at lua and wastes everyone's time, somehow.
arena_border_outer
is the white border that actually moves and arena
is the black rectangle. If you share the code that led to your screenshot then I'll gladly look into it with you.
A2. This is indeed true. In the above screenshot, LuaEnemyEncounterGO
is where the enemy would be placed by default in the list of Game Objects. Hence it would be parented according to the Arena. If we really need to fix this, my first guess would be to add a hacky exception to sprite.layer
that keeps track of a variable if the sprite is specifically an enemy sprite, then force 100% of Arena movements to loop through a list of enemies that have had their sprite layer altered this way and apply the same movement. Quite a workaround. You could instead program something via a script you'd put in every Wave script (or one single wave script you add to the end of nextwaves
every time the Defense round starts)...but it's up to you.
A3. Keep in mind that BindToArena
may or may not function if you change the monster sprite's layer like in A2. In my screenshot, using BindToArena
would move the enemy game object to just inside of arena_container
rather than arena_border_outer
. The second argument of BindToArena
applies whenever the first argument is false
- so when the enemy is not parented to the Arena. It controls whether the enemy game object is above or below arena_border_outer
in the list.
A4. Sprite pivot is absolutely 0.5 by default. Given that your other 3 queries are about monster sprites, I'm assuming you tested this on the monster sprite, which actually is 0 by default. This has been the case since Unitale so you can use enemypositions
to position your enemies by their feet. The sprite moves whenever you change ypivot because that's the way Unity works - it keeps the coordinates the same but moves the pivot.
A sprite spawned at (320, 240)
will appear to be in the absolute center of the screen (pivot is (0.5, 0.5)
), but using SetPivot(0, 0)
will move the pivot to the bottom left, right? The sprite's coordinates will still be (320, 240)
- except that now, they refer to the bottom left of the sprite instead of the center.
* It's important to note that this has always been the case since Unitale and changing it will break EVERY mod made in the past 3 years. And I do mean every one, because this change would apply to monster sprites as well.
Also, you say "Alt+Enter" is not working? Please explain. Are you on Mac? Do you have Blurless fullscreen enabled or disabled? And do you have a monitor that's portrait rather than landscape? I can tell you right now that the last one is one I've made a fix for that will be in next CYF.
B1. Rhen's said a few times that he's ashamed of the Overworld because this was his first real coding project and how he got into programming. If you must know, an Overworld rework is in the conceptual phase right now and we're considering adding it in the future. And of course it would be better documented.
B2. That's more of a thing with MoonSharp rather than with us. If you've used Roblox before, you may know that all of its scripts support a wait
function. Roblox's Lua scripts are asynchronous, whereas MoonSharp's simply are not. The solution to this is to use Lua coroutines or some other form of timing - maybe even by making a library to help with it. I've worked with another user before who wrote such a library - you create a bullet with it, provide a list of times and movement patterns, put them in a table on as little as one line, and the bullet will do all that stuff as long as the library is updated.
B3. Yes, I agree that most of the existing tutorials aren't the best. The truth is that's because there aren't as many people making mods as I would like there to be. As you may or may not be aware a vast majority of new users coming to Unitale and CYF are children and teenagers - especially immature ones who don't want to or can't understand that this engine requires serious coding knowledge and effort. They give up before they make anything meaningful or impactful. So most of the only content really published and visible is horrible re-skin mods and mods that are boring, lackluster and buggy. Thankfully there are a ton of wonderful mods out there and they are continuing to be made - and if CYF becomes more popular, there will be more good modders out there who can not only help you learn to make a mod but even write more tutorials.
Listen, this is nothing against you. We aren't brigading you here. But you came here and told us we should bury our own engine because it "has a bunch of problems", and then you didn't provide anything concrete until we asked about it. The ppcollision/rotational arena thing is in the past, and the reason that went down was because of lots of miscommunication, hostility, and refusal to try or even acknowledge anyone's support or ideas, jumping straight to "the engine is broken and it's your fault".
We don't want another flame war here. We want to maintain this engine and make it the best it can be. There is no way we're just wiping it from the face of the Earth after a few small bug complaints. I am genuinely sorry that the Unitale/Create Your Frisk community and you got off on the wrong foot. But when force and hostility is applied, that's all we can do. I hope you understand and we can stop with the ruderies and start to actually talk things through before jumping straight to accusations towards the engine and its contributors. All right? What do you say?
Just by starting programming an encounter, I've ran into a dozen of engine bugs. It's painful to look at this largely untested mess. Somebody should take notes for future projects.