Print

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

[lethosor]

My best guess is that something about the network request seems suspicious to antivirus programs (possibly the single header, although I'm not sure how best to work around that).

Code: [Select]

   734                  req = Request(
   735                      self.config.get_string('updates/checkURL'),
   736                      headers={'User-Agent':'PyLNP'})
   737                  version_text = urlopen(req).read()


[Pidgeot]

My best guess is that something about the network request seems suspicious to antivirus programs (possibly the single header, although I'm not sure how best to work around that).

Code: [Select]

   734                  req = Request(
   735                      self.config.get_string('updates/checkURL'),
   736                      headers={'User-Agent':'PyLNP'})
   737                  version_text = urlopen(req).read()


If that triggered it, then any Python-based download would likely trigger it; the only difference between the generated request with and without that parameter is that Python fills in a default User-Agent without it.

It's *far* more likely to be a false positive because the executable uses UPX compression to minimize the file size, and that is absolutely down to a bad signature file.

[lethosor]

Agreed. I assumed the network traffic on startup was triggering the antivirus program, but those appear to be two separate issues.

[salithus]

Quick question since I cannot wrap by brain around Python development (I've got a background in C/C++/C#/Java/VB.NET and it's been over a decade since I touched C/C++)...

I plan to do some ~things~ that I see long-term benefiting PyLNP. Is there any advantage to me making sure my libraries are cross-platform? I can look into Mono compatibility, but only if it's worth the time.

[Pidgeot]

Whatever you have planned, I'd suggest you wait a little while longer - there's some restructuring of code coming up as soon as I have time to finish it, which is hopefully within the next week.

Other than that - without knowing what you have planned, it's kind of hard for me to say much, so the best answer I can give is "...maybe?". Throw me a PM or e-mail (michael, then an @, then birdiesoft.dk) if it's too long or complicated for the forums; I'm very familiar with C# etc., so feel free to get technical if it helps you explain.

[salithus]

Whatever you have planned, I'd suggest you wait a little while longer - there's some restructuring of code coming up as soon as I have time to finish it, which is hopefully within the next week.

Other than that - without knowing what you have planned, it's kind of hard for me to say much, so the best answer I can give is "...maybe?". Throw me a PM or e-mail (michael, then an @, then birdiesoft.dk) if it's too long or complicated for the forums; I'm very familiar with C# etc., so feel free to get technical if it helps you explain.

Excellent. I'm going to sleep on the ideas I've got brewing after the discussions in the Starter Pack and DFHack threads, so I'll hit you up tomorrow morning with what I've got in mind.

[lethosor]

I plan to do some ~things~ that I see long-term benefiting PyLNP. Is there any advantage to me making sure my libraries are cross-platform? I can look into Mono compatibility, but only if it's worth the time.

If you're planning on including them in PyLNP, then they should be cross-platform to avoid the need to maintain separate branches for other platforms. If you're talking about an external service that integrates with PyLNP (such as the utility information repository you mentioned in the wiki board), I don't think it would matter.

[salithus]

I plan to do some ~things~ that I see long-term benefiting PyLNP. Is there any advantage to me making sure my libraries are cross-platform? I can look into Mono compatibility, but only if it's worth the time.

If you're planning on including them in PyLNP, then they should be cross-platform to avoid the need to maintain separate branches for other platforms. If you're talking about an external service that integrates with PyLNP (such as the utility information repository you mentioned in the wiki board), I don't think it would matter.

Preface: If I need to take this to a separate thread, let me know.

Re: lethosor's comments - that's what I'm not sure about. I definitely plan to expose an API that PyLNP could consume, but can see the advantage of having some of these libraries ready to roll in if it's also something Pidgeot et al see themselves wanting to do down the road.

Ok, first task is structuring how things relate to each other. Here's my starting point:

Spoiler: UML diagram (click to show/hide)

I plan to have a website with an admin interface for managing this data (initially - hopefully some automation comes in down the road). First Component would be Dwarf Fortress itself, which has no Dependencies and I can populate all the releases that are available. Then my desktop app would notify (via checking the server API) when a new release has been posted.

Spoiler: Thoughts on detecting/processing DF updates (click to show/hide)

I know there's an RSS for releases, but there's nothing I saw that points directly to a download link. I could scrape for it, but don't want to do that quite yet, so the update process on my end will still be manual although I can set up something to send me an email when RSS changes.

From there, you have to download/unpack the new DF (user-initiated, app just notifies it's available). This involves

• Archive the current DF folder
• Download the zip
• Unpack it
• Automatic processing of settings (migrate what we know works from user prefs, which are stored outside of init/d_init
• Manual settings (notify user if there's a new setting detected or if something couldn't be migrated because ~reasons~
• Install Components that can be (either no dependencies OR dependencies on DF with a Maximum Version "wildcarded")
• Notify user of "disabled" (not reinstalled) Components.

There should be a "test run" version of this that would spit out a summary of what tools you'd end up with, so you can decide whether you're ready to upgrade yet.

From there, Graphics Packs are next - one of the reasons for limiting the number of packs listed in PE's Starter Pack is that he doesn't have a good way of handling conflicts/installing/etc in the SP. I want to just have a list of all of them on the site, with functionality in the app to "download and install", as though you were choosing themes for Chrome or whatever. Admittedly, I don't know the first thing about how they work other than a vague assumption that it's image files that go in /data/art and some raws that get changed. If it's that easy, I should be ok, otherwise I'll be posting for help in the graphics area to understand just wtf I'm doing.

After that, looking to do utilities such as DT and QuickFort next. Hopefully by then it'll be pretty straight forward.

After that, I tackle DFHack and god help us all.

[PeridexisErrant]

Good luck!  After DF itself, the easiest option is probably utilities - practically all of them you just drop into a folder under LNP/Utilities/ and you're done. 

[salithus]

Good luck!  After DF itself, the easiest option is probably utilities - practically all of them you just drop into a folder under LNP/Utilities/ and you're done.

Agreed that they're next in difficulty,  but in my mind unless I can tackle at least the complexities of graphics, I'm not improving on the existing starter packs enough to make the effort worthwhile.

[Pidgeot]

So basically a package manager for Dwarf Fortress? That sounds like a great idea, and it certainly seems like it could fit in with PyLNP somewhere down the line.

If you can stick to using things natively supported by Python, that will of course be ideal, but for now, it sounds like it'll be best if you just try to make *something* work. We can always look at what (if anything) needs to change later.

(Of course, you could just use this as a reason to learn Python... )

[PeridexisErrant]

A starter pack release is coming - with all the issues raised and fixed in the last round, are there plans for a PyLNP v0.5 soon?

[Pidgeot]

If all goes well, V0.5 will be up within 24 hours. I need to do a little more testing, then it's ready to go.

[Pidgeot]

And it's ready! 0.5 makes updating non-mandatory, adds missing options compared to the previous Starter Pack Launcher, prevents double-launching the same program, and various other things.

[Pidgeot]

(Sorry for the triple post...)

fricy discovered an issue which prevented OS X 10.7 from launching certain programs; I fixed this and released an updated version (0.5.1) as a result.

The Windows version doesn't use this piece of code, so only OS X and Linux builds are changed. For Windows, keep using 0.5.

EDIT: If you downloaded the OS X version prior to September 21, 22:46 UTC, re-download it. Something was apparently wrong with the build, so it didn't fix the issue it was supposed to; a rebuild took care of it.