Auto Arrows for Gravity Apples

[ribot]

I made a program and LGRs so that you can automatically add apples with arrows to a level with gravity apples. This requires that everyone has these LGRs, and it could be implemented in the community. Nothing will change expect the gravity apples.

Download LGR and level fix software:
https://github.com/RobinManoli/ElmaAutoGravityApples



There is an old discussion of this here viewtopic.php?t=9271

Sorry to Dawid for not following your convention.

There were a number of problems with the convention:
- I couldn't find the lgr
- I used the convention of the .lev format, so that food anim number will be the same as apple gravity number
- How to use the convention wasn't explained, and nobody even knew how food anim number works.

Here is the new convention:
Make sure to use an lgr for this level that has (you can download above):
qfood1.pcx as norm apple (no gravity),
qfood2.pcx as gravity up,
qfood3.pcs as gravity down,
qfood4.pcx as gravity left,
qfood5.pcx as gravity right.

To change LGR
you rename old default.lgr to default-backup.lgr and put default.lgr there
inside lgr folder
then put ribot.lgr in lgr folder if you want to use it

Test LGR with this level (you need to see the gravity arrows in elma):
https://elma.online/levels/574599
(or download a copy of this lev in elma: ctrl-f4: gravityf)

I edited default eol LGR. Number of apple anim:
1 - normik apel
2 - left
3 - up
4 - down
5 - right

U can make levs which use my DefGrav.lgr



'special' lev for testing my lgr: http://elmaonline.net/statistics/level/296166

DefGrav.lgr

PS. I'm the master of the Photoshop
EDIT:
-updated links
-PLS accept my anim numbers as standard. So use the same anim numbers when make your own grav lgr!

[ribot]

Also, if community is interested in fixing this, any level editor could set food anim number by default to the same number as the gravity number

[ribot]

actually a better fix for this would be to have an official lgr, and then an option (checkbox) in startballe that would fix the level

[Igge]

very cool concept, im all for it)

[Hosp]

i hev this in my LGR and causes confusion sometimes because is not industry standard but too lazy to remove it

[ribot]

well the industry standard can be solved in this way:
- make startballe.exe able to automatically fix any level so it follows the standard
- have official lgrs that follow the convention
- if you have another lgr, use easy lgr to copy the qfood images from an official lgr to your own

i have provided both the code and lgrs to download on the github link on the first post, so this convention should be available as long as github remains free

anyone who wants to follow the industry standard can do it right now, no need to wait for startballe, just use the software i provided on github

[Hosp]

oh sounds very cool will look at it when have more Orcc))

[Lee]

Hey, ribot!

Cool that this is brought up again. This gravity arrow thing for default lgr has been discussed in the past and shot down as problematic. The main reason is that there are many existing levels that use food anim numbers 3+, most likely by accident. With your method, these would appear as arrowed apples, and in 99% of cases wouldn't align with the type of apple.

Here is the new convention:
Make sure to use an lgr for this level that has (you can download above):
qfood1.pcx as norm apple (no gravity),
qfood2.pcx as gravity up,
qfood3.pcs as gravity down,
qfood4.pcx as gravity left,
qfood5.pcx as gravity right.

qfood2 is already used by default.lgr. and is even used in the internal levels. You can see three instances of food2 in internal 16, and your method would falsely hint that these are gravity up apples.

Best use case for gravity arrows is in an entirely new lgr (i.e. not named Default.lgr), and occupying food anims 3-6. I agree with your ordering of up, down, left, and right as that is how it is ordered in the in-game editor and in SLE. I am currently working on such an lgr with an entirely new name and other new features.

I will post more information shortly.

[ribot]

Thanks for your reply Lee

It will be problematic with old levels, that's true, but the question is if it's really relevant. The most important is that the arrows work when playing new battles. If someone is hoyling any level seriously the arrows don't matter much, because they have already learned the level. But in new battles with little time, especially ff battles, the arrows can decide if someone is a winner or not.

There may be ways to solve backwards compability, by spending time on researching. A simple solution is that old levels on elmaonline could be updated (if creator allows it), so old times can be kept. Or a setting in elma conf that always shows arrows correctly. So the problem is solvable.

However, the most important thing is if the community actually cares.

[ribot]

Another approach to this could also be to use eolconf.

In eolconf you can choose default ground/sky, still food, pictures in background, hide taken apples... so why not have options there to show gravity arrow apples?

These options could be relevant:
- show arrowed apples for first finish battles with gravity apples
- show arrowed apples for all battles with gravity apples
- show arrowed apples for all levels

This could be solved technically in different ways:
- use an lgr for the levels selected above, naming it gravity.lgr
- or only use the relevant arrowed apples from gravity.lgr in the levels above, still keeping the normal user/level lgr for other things (this could be done either in eol.exe or by combining lgrs programatically)

Also: a reminder in eol that tells you if you dont have a suitable lgr for showing arrowed apples