Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[txtsd]

I saw it after I made this. It's just ui files right now. There's no code involved yet.
Do you know why Dricus has been MIA since the middle of the year?
Should I fork his branch and pick it up from there?

MIA? Me? I'm here . I'm still following the PyLNP development, but it's just that time again when real life kicks in. Holiday, new job, lots of courses to follow, stuff like that...

As for your UI prototype: For me, it was a very deliberate decision to show much less information on the screen than the current UI does. In my humble opinion, your prototype (just like PyLNP and the old LNP launcher) looks sort of haphazardly thrown together. I mean, why should FPS, sound, save related stuff, process priority, embark, etc all be visible on one single tab? Why should the installation of graphics packs be on the same tab as modifying display settings like varied ground and liquid depth? Sure, to the trained DF player it does make a little bit of sense, but (again, IMHO) it does not do a very good job of making all these settings easy to find in the UI. Especially for newbies, these kinds of UI's can be a bit intimidating.

I'm not saying my attempt is perfect, but to me, it's a step in the right direction.

Fair enough. I think I'll stick with yours and try slimming it down a bit.
I've been trying to get your branch to work with python 3. I got the downloads bit to work, but I'm having trouble getting the init editor to show. Could you take a look at it?

[PeridexisErrant]

MIA? Me? I'm here . I'm still following the PyLNP development, but it's just that time again when real life kicks in. Holiday, new job, lots of courses to follow, stuff like that...

I'm not saying my attempt is perfect, but to me, it's a step in the right direction.

Yeah, I know that feeling.  It would be great to get a build with the new GUI in the next few months though, so I'm pretty excited by @txtsd's work.

FYI all - Meph has expressed interest in using PyLNP as the launcher for a new version of Masterwork mod; basically we just need a more logical UI and better mod-merging support (eg via BAMM or PyDwarf).

[Dricus]

FYI:

IIRC one of the reasons (if not the reason) for sticking with Python 2.7 was because pyinstaller did not support Python 3 yet. I just found out that pyinstaller 3 has been released last october, which adds support for Python 3.

[Pidgeot]

For reference: I do now have my computer back and all that, but there are a few more things I need to take care of before I can really start looking at PyLNP again. I currently expect to get started again sometime next week.

[burned]

I've seen a specific creature tileset issue come up in a few posts under the DF Gameplay Questions and in the Tilesets and Graphics subforums.

Whether it cropped up with people who were not using the LNP or people who just left out the fact they were using the LNP - the issue is currently present in the most recent DFgraphics repo for 42.04 which the LNP uses.

To the point, creature_savage_tropical.txt was removed in 42.04. With the exception of the giant desert scorpion all were moved to other files AND renamed (e.g. LION_GIANT was changed to GIANT_LION, etc.). In addition a giant toad became a "giant cave toad" and a new giant toad was added. In other words, TOAD_GIANT became TOAD_GIANT_CAVE and a GIANT_TOAD was created. I believe the only thing Toady forgot to mention in the auxiliary file changes was TIGERMAN changed to TIGER_MAN.

While it's not common for Toady to change creature definition names - he did change them in 42.04. Demonstrably you can install a 40d graphic set in 42.04 without issue, but your definition file(s) would be out of date. You will NOT get an error with outdated definitions, but you will get one if you are transferring a save file that was created for a previous version. The save is compatible - barring your standard compatibility issues for doing such a thing - you just have to update the definition of the creatures in question.

I skimmed the DFGraphics repo and even the most recent Gemset for 42.04 has definitions that are 2 months old and I visibly see a graphics definition text named "graphics_savage_tropical.txt" in the set that was posted today by fricy.

To be clear, I am not faulting fricy. While he is nuts for trying to maintain all of those sets at once, I think everyone in the LNP community would commend him for his contributions. Just dealing with the Pheobus set alone - multiple graphics with multiple definition files from various authors using various organization . . .  what a nightmare!

As an aside, I did take into consideration that graphic sets may work a bit differently in the LNP than the supported method, because I noticed a few odd things on the repo (like every set has it's own object and data folder . . . ??). I also recall fricy having issues last summer with a save file related to graphic sets "raws," but I honestly don't recall the specifics because I dropped the investigation back in September 2015.

Regardless . . .

tl;dr Your graphic set repo has outdated definitions that will create FATAL ERRORS in transferred saves and will ignore parts of the set without error in 42.04 and forward when generating new worlds.

I hope that helps.

Edit: I didn't see a DFgraphics repo thread, so I thought this was the best place to post something that addressed all LNP packs.

[PeridexisErrant]

IIRC one of the reasons (if not the reason) for sticking with Python 2.7 was because pyinstaller did not support Python 3 yet. I just found out that pyinstaller 3 has been released last october, which adds support for Python 3.

And 3.1 fixes some other issues, like tracebacks keeping the path from the building computer.  However the semi-official 0.10e I built with Py3 (64bit) seems to have a variety of bugs on other people's machines, so it might not be ready for prime-time yet.

For reference: I do now have my computer back and all that, but there are a few more things I need to take care of before I can really start looking at PyLNP again. I currently expect to get started again sometime next week.

Looking forward to this - it would be great if you could provide a better build of the tag above ASAP.

<snip>
Edit: I didn't see a DFgraphics repo thread, so I thought this was the best place to post something that addressed all LNP packs.

Yeah, this is a decent place to report it.  I can't speak much to fricy's graphics packs (though @fricy it would be good to have a thread for them, hint hint), but on the PyLNP end the idea is to declare compatibility in the manifest and avoid changing raws on incompatible saves.

As to the very wide compatibility of graphics:  yes, creature graphics are incredibly compatible.  The actual problem is that years ago someone (IIRC Phoebus) invented "tileset magic", where via a number of colour and transparency tricks a carefully-drawn tile could look like many different things in-game.  This required changes to the object raws, and those are what cause all the compatibility trouble - most graphics packs are an unholy combination of tileset (hence data folder), mod (hence raw/objects), creature graphics, and now TwbT/DFHack files too.

I really want to find a better (more compatible) format at some point and end this madness, but the chains of history are strong and Gemset has shown that TwbT has some issues overriding *everything* - otherwise normal raws and normal creature graphics with a square tileset would only need a touch of TwbT-override-everything to replace/rebuild existing graphics.  Alternatively DF could improve it's graphics support, but that could be a while...

[Pidgeot]

For reference: I do now have my computer back and all that, but there are a few more things I need to take care of before I can really start looking at PyLNP again. I currently expect to get started again sometime next week.

Looking forward to this - it would be great if you could provide a better build of the tag above ASAP.

Hoping to get one out within the next 24 hours.

[fricy]

I've seen a specific creature tileset issue come up.../snip

Yeah, it's not a complete clusterfuck, but still an existing problem that we're working on. Unfortunately I'm not seeing a 100% foolproof solution for this yet, but the problem has come up multiple times with mod merging and also it was more-or-less the same when the 40.13 update happened and the language files broke. As PeridexisErrant mentioned, the temporary solution is to make sure we don't break the files.

To the point, creature_savage_tropical.txt was removed in 42.04. With the exception of the giant desert scorpion all were moved to other files AND renamed (e.g. LION_GIANT was changed to GIANT_LION, etc.)

Thx, I missed the fact that they were moved, and not removed, I fixed what I could, the rest is up to the original author.

I skimmed the DFGraphics repo and even the most recent Gemset for 42.04 has definitions that are 2 months old and I visibly see a graphics definition text named "graphics_savage_tropical.txt" in the set

Unchanged files will be shown as 2 months old.
I removed savage_tropical.txt from /objects where it would have caused problems, even save breaking problems, but leaving graphics_savage_tropical.txt in place was intentional, as it's harmless, but contains useful information for completely updating the set to 42.x. Worst case scenario is some mismatched sprites. I didn't publish the link until I could confirm that I can load a game that was generated with a different set.

The set is not complete, true, but without the graphics sources, and a permission from Palatino I wouldn't start editing someone else's IP. Creatures were moved around and added, so new sprites are needed, then the sprite sheets will need to be reorganized, then the config files will need to be updated. It's a process, this is merely the first step: getting the objects folder up-to-date. On the other hand: I really should give him a notice, that more work is needed...

While he is nuts for trying to maintain all of those sets at once, I think everyone in the LNP community would commend him for his contributions.

To be fair what I do is not that hard, I'm not doing creative work, and merging the raw updates is usually ‹5 min per set, kdiff3 is an excellent tool for this kind of work. The only set where I'm contributing content is Spacefox (which I consider an abandonware), and even then a fey mood is needed. My attention span can be rather short.

Edit: I didn't see a DFgraphics repo thread, so I thought this was the best place to post something that addressed all LNP packs.

I can't speak much to fricy's graphics packs (though @fricy it would be good to have a thread for them, hint hint)

Ok, ok, I'll get on it. It will be needed anyways, since I won't have much time on my hand between April-August. I'll make a thread for the repo, and create an organization on Github with all the individual packs, so others can keep the flame going when I'm not around.

[lethosor]

I thought using the LNP organization would work (http://www.bay12forums.com/smf/index.php?topic=137096.msg6728595#msg6728595), but either way is probably fine.

[fricy]

I thought using the LNP organization would work (http://www.bay12forums.com/smf/index.php?topic=137096.msg6728595#msg6728595), but either way is probably fine.

It could work, but I don't want to clutter that org with 16 additional individual repos. I think I'll keep the recently moved DFgraphics there, and create an standalone organization for the subrepos. That way we can handle the member permissions better too.
Any other thoughts I should consider? I'm fine either way, just this way I think it's better in the long run.

[lethosor]

Yeah, it might be better for organization. I personally think keeping them in the same place as DFgraphics would be clearer, though, wherever that is.

[Pidgeot]

PyLNP 0.10e is now up, for all platforms. It fixes a bunch of issues, such as problems with hack management, and major slowdown on startup and when changing settings.

[burned]

The set is not complete, true, but without the graphics sources, and a permission from Palatino I wouldn't start editing someone else's IP. Creatures were moved around and added, so new sprites are needed, then the sprite sheets will need to be reorganized, then the config files will need to be updated. It's a process, this is merely the first step: getting the objects folder up-to-date. On the other hand: I really should give him a notice, that more work is needed...

I was previously under the impression that you (fricy) updated the DFgraphics repo to the latest version - meaning I thought you actually updated the definitions of each individual set and checked to see if everything worked with the latest DF release in non-error situations - which is why I thought you were crazy for attempting such a feat.

To reiterate my new understanding, the manifest.json file is updated as long as the set loads without error. Nothing more. The definitions remain untouched and it's up to the individual authors to actually update the set (aside from Spacefox[?]).

If so, that approach leads to confusion especially since "loading without error" does not mean there are no errors; sets still need to be updated to the latest DF version even though they are "updated" for the latest LNP.

Sets in the repo that are exclusively maintained by one person (CLA, Taffer, etc) are easy to address (like your follow up post in the Gemset thread). But, "collaborative" sets like - Pheobus and Mayday and others fall into the nightmare I mentioned earlier - mainly because it's more like a Frankenstein than any sort of collaborative effort.

Tallcastle is a good example. He is currently tackling the tremendous effort of adding a lot of new sprites to Mayday, so that people can continue to enjoy this set. I know you said, "Worst case scenario is some mismatched sprites," but that lackadaisical response ignores the efforts that Tallcastle is pouring into his work for the benefit of others and the users who stumble into problems with "updated" DFgraphics and the LNP by proxy.

Posting a DFgraphics thread to point Tallcastle and others to the relevant conversations for future reference would be beneficial. That's all I think the DFgraphics thread needs to be - a reference of what DFgraphics is and is not, possible improvements and where help is needed, especially since these aren't problems you can look up in the DF wiki.

The actual problem is that years ago someone (IIRC Phoebus) invented "tileset magic", where via a number of colour and transparency tricks a carefully-drawn tile could look like many different things in-game.  This required changes to the object raws, and those are what cause all the compatibility trouble - most graphics packs are an unholy combination of tileset (hence data folder), mod (hence raw/objects), creature graphics, and now TwbT/DFHack files too.

Understood. Thank you.

I really want to find a better (more compatible) format at some point and end this madness, but the chains of history are strong . . .

If anything, I appreciate the freedom Toady allows when it comes to the format provided for the graphic sets. Take CLA and Taffer as two examples of single author sets where there is organization. Both authors were allowed to approach it in different manners with the same format - in a way they preferred and what worked best for them.

You can argue the case for some sort of organization guide, but the madness doesn't come from not following guidelines - it's the absence of real collaboration within those sets and unfortunately the current state of the repo adds to that problem.

Alternatively DF could improve it's graphics support, but that could be a while...

I feel as if this is addressing a different issue. Maybe something related to TWBT? I'm not familiar with DFhack. In any case, I'm positive you know that more graphic support isn't going to fix disorganization and lack of maintenance by set authors when updating to the latest version. Heh.

[PeridexisErrant]

Summarising:  updating graphics packs is harder than it sounds, especially in a timely manner.  Collaboration is also tricky, and nobody likes it when things break.

I feel as if this is addressing a different issue. Maybe something related to TWBT? I'm not familiar with DFhack. In any case, I'm positive you know that more graphic support isn't going to fix disorganization and lack of maintenance by set authors when updating to the latest version. Heh.

Hard problems remain hard.  TwbT is promising, but faces performance and correctness issues when used very intensively (see: Gemset).  However if we could eg stop using "tileset magic" and replace it with TwbT, the remaining required changes to the raws might be much simpler and thus easier to collaborate on and/or automate.

Basically I'd like tilesets to be completely raw-independent again, and creature graphics as independent as practical.  I may set up a graphics project aimed at this, if Fricy doesn't get to it first...

[txtsd]

However if we could eg stop using "tileset magic" and replace it with TwbT, the remaining required changes to the raws might be much simpler and thus easier to collaborate on and/or automate.

Basically I'd like tilesets to be completely raw-independent again, and creature graphics as independent as practical.  I may set up a graphics project aimed at this, if Fricy doesn't get to it first...

That's a great idea except that TwbT typically takes way more time to be updated than dfhack does.