Continuous Build

Triggered on 2023/10/21, 23:50 UTC by commit 970d655 (@shitwolfymakes)
This is an automated build of the latest source. It includes ESMB and all the unit test binaries. It may be unstable or even crash, corrupt your save or eat your kitten. Use with caution!
https://github.com/shitwolfymakes/Endless-Sky-Mission-Builder/actions/runs/6600332006

Beta 0.4.1: Stable Release

This version of ESMB solves the notorious "No module name 'src'" bug that has been an issue since the beginning. Anyone should now be able to download and run from source. I have tested this on MacOS, Win10, and Ubuntu 20.04. Thank you so much @Harald-Berghoff!

The following is a copy of my reddit post here

ESMB Year 2 Review

It’s been a relatively quiet year for ESMB. The last release was Beta 0.4 on 15 November 2019. It finalized the architecture of the design and code of ESMB that will be used going forward. I began developing functionality for NPC creation and editing, and mostly completed the GUI for that part during the lockdowns. Most development slowed or stopped as my classes moved online, but in May I graduated with my B.S. in Computer Science, concentration in Software Engineering. Since then development stopped entirely as I packed everything up and moved across the country to start working full time.

What is ESMB?

Endless Sky Mission Builder (ESMB) is a click and type mission building tool to create content for Endless Sky. It’s aim is to give anyone a quick and easy way to create missions for the game

ESMB is not dead

After the move I had no place to set up my desktop and development environment. I didn’t have a desk until a couple months ago, but now that I do, I’m looking forward to getting back to work on this. I love this project, and I’ve gotten to learn and practice new technologies that I never got to try during college.

Coming Soon

1. Carrying forward the design and architecture of ESMB already created, I am going to be rewriting everything in C++, using Qt for the GUI framework. The single biggest limitation for further development of this project was Tkinter. Not only is the framework hard to work with, resizing the window tends to break things, every widget has to be built from scratch, and Tkinter is unreliable for MacOS because of how python and the TCL library are organized on that OS. Best of all: Qt looks gorgeous, supports themes a lot better, and has a drag and drop widget creator that will speed up development appreciably. Finally, the C++ codebase will hopefully attract more PRs and help from the pool of people interested in working on Endless Sky.
2. To facilitate this I am upgrading my PC, using the old parts to build a server box that will host the Jenkins build server for this project. This will allow me to build a free, professional CI/CD pipeline for ESMB, in addition to bringing back MacOS support. Executables will be appended to each release, and I may switch that to installers later if that’s a possibility.
3. Documentation will be moved to its own repository, potentially as a GitHub Site. The wiki features are okay, but no one seems to use them, and you can’t PR the wiki. This will allow anyone to PR tutorials, better documentation, etc.
4. A new C++ conversion branch will be created in the current repository, and once the conversion is done will be merged onto master, replacing the current code and bringing the version number to Beta 1.0. The NPC code I created was just for the GUI, so it will not be included.

Thank You!

Thanks to everyone who has downloaded and given feedback, opened PRs, and helped make Endless Sky and ESMB what it is today. I look forward to working with you all next year. Stay safe, stay healthy, and let’s make 2021 Endless Sky’s best year yet!

Where We Are Now

The build server has been assembled, and is almost ready for use. Once I have some storage in there I can configure Jenkins, and then it's off to the races! If you want to follow the progress, the repo now has a project page, located here

Beta 0.4: Stable Release

This is the largest update yet, and there's a lot to go over! Everything about ESMB has changed in one way or another. Once again, huge thanks to @MCOfficer for taking the time to update the build system after the architecture change. I wouldn't have been able to get this building into executables without their help.

Changes

Code

• Completed PEP8 conversion
• Restructured the code base, 1 class per file
• Classes are grouped at varying levels within one source folder
• GUI and data model code is now completely separate. The GUI no longer stores a list of missions(yuck)
• Created a new application architecture (See UML)
• PARTIAL handling for non-mission data (see below)

GUI

• Each frame in the GUI (optionFrame, centerFrame, and missionFrame) have been moved into their own classes
• Feature request #2 has been added. Now you can find out what each of the sections mean simply by hovering over it's label!

Testing

• Added unit tests for data model parsing system
• Added unit tests for mission file parsing system
• Added miscellaneous other unit tests

Misc

• Added UML diagrams to aid people in understanding the code
• Completed some more user documentation
• Build scripts updated to handle the new architecture

Architecture and Codebase

Due to the original, rushed-semester-project nature of ESMB, the code base was originally a loose collection of files, with nary a src folder in size. That has changed. Everything needed to run ESMB, be that code or text data, is inside the src directory where it belongs, or within subdirectories of it. All source files now contain only one class per file, and are grouped logically. The exact locations of each file may change in the future, but should remain in the same general area from here on out. I have added UML diagrams to help aid people in the understanding of how ESMB works, and will keep them as up to date as possible

In terms of the architecture of the project, the GUI no longer sees or contains the data model. What was originally the missionList is now stored in a single MissionFileItems class, found in MissionFileItems.py, which will support every kind of data that can appear in one of Endless Sky's mission files. Each data type (mission, event, phrase, etc.) will be viewable and editable thanks to the GUI changes. More on that below.

To divorce the gui and data model from each other, I had to learn how to make a global in python. This global data store comes in the form of config.py, found in the src directory. It contains references to important parts of the data model, the toolips used by #2, the debugging state, and the GUI. From here in, if the code needs to reference any of this stuff, it needs to go through config.

GUI

The GUI has changed in several major ways. First, each section of the GUI: the optionFrame, centerFrame, and missionFrame have been removed and moved into their own classes. These new classes: OptionPane, MissionEditorPane, and ItemTextPane, respectively. Each of these inherit from the class GUIPane. This is important because now that the only location where the user is changing mission data is in the MissionEditorPane, it can be swapped out without affecting the rest of the GUI. So in the future, when a user adds or edits an Event(for example), the MissionEditorPane will be swapped out for an EventEditorPane, and so on for NPCs, Phrases, and others.

This, combined with the fact that the parsing and compiling systems have been moved to a "one for each type" design, means that to add support for a specific type of file data, all you have to do is create an editor pane, a compiler, a data and file parser, and update a method to take advantage of the new functionality.

Eventually, ESMB will be able to add support for the following, the same way missions are done now.

• Adding/editing Events
• Adding/editing Phrases
• Adding/editing NPCs
• Adding/editing Governments

Testing

A lack of unit testing is unacceptable for a project of this size. The serious bugs that 0.3.1 and 0.3.2 addressed would never have made it into production had there been unit testing. As of right now, the majority of the parser systems now have unit tests written for them. The compiler system will get a set of tests in the coming weeks, and I'm looking into ways of unit testing GUI components.

Conversations

The biggest request I've been hearing for ESMB was to add support for adding and editing conversations. At this time ESMB can read in files with conversations and print them back out without deleting them like all the other data types. I may have figured out a way to handle conversation editing without writing a new tool, and if that's the case, then ESMB will eventually support it.

Beta 5 TODO List

• As promised, Beta 5 will include Conditions
• Unit testing for all classes and systems, sans GUI
• Updated user documentation
• Store all data found in files (copyright, event, phrase, etc.) and print out when saving the same way conversations are currently handled

#48

Fix appveyor deployment (#17)

* reenable windows builds

* Rewrite windows build script to be more verbose & elegant

- Consistently use .\ for folders and files
- More comments
- Prefer verbose parameter names unless explicitly explained
- Centralize paths to python installation
- Prefer explicit windows command names in over shorthand aliases

* let nuitka choose its compiler freely

* compatibility patches in the code

* adjust windows build script

* adapt for linux, remove nuitka compilation

* fixup PyInstaller package calls

* ubuntu: install python3.7 explicitly

* call pip from python3.7, not as pip3

* remove python version check, restructure comments

Beta 0.3.2: Stable hotfix

This update includes several critical bug fixes, and the implementation of a logging via the python logging library

Changes

• Added logging to replace all the print statements
• Fixed a bug where on <action> inside a trigger would not persist if the trigger was opened up for editing, and then immediately closed without any interaction taking place
• Fixed that same bug, only this time it was happening when trigger conditions were being opened up.
• Fixed a bug in trigger conditions where data was being stored improperly, causing the data to be reset to default

Beta 4 Road Map

Given that these bugs should have been found, and were missed due to a lack of any unit tests or integration tests whatsoever, that will be the new priority for Beta 4. However, I still plan to tackle issue #2. Conditions will have to take a backseat for a while, but ideally I'll cover them in Beta 5, along will events.

Binaries/Executables

Due to the fact that the only MacOS binaries I can build crash my laptop when run, I am dropping executable support for MacOS. However, the code still runs fine from source, given that you have Python 3.7+ installed. If anyone knows how to get executables working on MacOS without using pyinstaller or py2app, please let me know.

Beta 0.3.1: Stable hotfix

This release fixes a critical problem in the Windows 10 version of ESMB. Mac and Linux users are unaffected, so feel free to keep using Beta 3 on those platforms

Changes

• Fixed issue #10
• Converted code to PEP8 format
• Documented code

Beta 0.3: Stable release

Okay, so there's a fair bit going on in this release. I didn't add new mission feature handling, instead taking the time to clean up the code to improve user experience.

GUI Refactor

I finally fixed the problem everyone was having with the center frame! It was a massive pain in the ass, but now I'll never have to touch it again. Special thanks to Brian Oakley on Stack Overflow for helping me out so much.

Besides the issue with ScrollingCenterFrame, I completely overhauled how the GUI draws the widgets onto the center frame. Originally, I was placing, linking, and populating data to and from every goddamn widget by hand. Yeah, it was bad, but Beta 1 was a semester project so I didn't have the time or intelligence to do it cleanly until now.

But now that I have vastly more experience with tkinter I was able to create a frame that:

1. automatically creates a number of entries based on user input,
2. creates BooleanVar() and StringVar() variables based on said user input,
3. hooks all of these variables together,
4. draws and formats them, and
5. handles population and saving of data

Most of this code was moved out of GUI.py, where it shouldn't really be, and into guiutils.py, where it should be. Most of the code that only AggregatedTriggerFrame uses was also moved from guiutils.py into AggregatedTriggerFrame.py, where it belongs.

Code changes by # of lines:

Filename	Beta 2	Beta 3	delta
GUI.py	972	496	-476
guiutils.py	979	500	-479
AggregatedTriggerFrame.py	132	883	751
Total delta			-204

While in the end I did write more code than I expected, the result is a vastly cleaner and more concise codebase, which will make further modification easier.

Binaries/Executables

Special shout-out to @MCOfficer for this. Adding the binaries was his idea, and I didn't even know that it could be done until he showed me how. Now, whenever I post a new release like this one, the third party service(Appveyor, in this case) sees it, creates windows and linux executables, and attaches them to this post. Once the user downloads and unzips them, it's the usual double-click to run that happens with any other app. We weren't able to leverage it to create executables for macOS, so I wrote a script to do it on my end.

Themes

Another shout-out to MCOfficer, he took the lead on adding this. I settled on using plastik for the theme, because it was the only one that didn't look like Harambe's rotting corpse. Eventually I'd like to make a custom theme, but that will be at the bottom of the to-do list for a while.

Documentation

I have started work on user documentation and how-to's, keep an eye out for them on the wiki for this project.

Beta 4 to-do list

• Help: I plan on tackling Issue #2. I think it would be a nice challenge and I'd get to apply some of the stuff I learned while I was making the custom widgets for Beta 3.
• PEP8: I also plan on converting the code to PEP8 format, which I have kinda totally ignored so far. But I want this to look professional-ish so I'm gonna subject myself to that.
• I may take a look at Conditions depending on how much work that takes.
• Complete User Documentation

Beta 0.2: Stable release

Beta 2 is comprised mostly of Endless Sky v0.9.9 compliance and Triggers.

v0.9.9 compliance

With the release of the v0.9.9, several changes were made to the way missions are formatted. The only ones that affect ESMB are illegal and stealth. Both of these are now in the proper place, no longer children of cargo. From here on in, all missions made with ESMB are usable with Endless Sky v0.9.9 and later!

Triggers

can now be added to your missions. To do this, scroll to the bottom of Mission Options and select "Add Trigger". From there you will be able to add almost all the options a trigger can have.

Not included with Triggers:

• on event has not been added. I spent that time creating a set of widgets that will make it easier to add later.
• Conversations: these are a big enough problem domain that they will get their own tool, once ESMB has enough of a feature set. For the time being, conversations will not be included in ESMB.

Other Changes:

QoL

• backticks ` are now standard where they can be used

Bugfixes

• squashed some bugs in opening a file and elsewhere

Beta 0.1: Stable release

This is the first working prototype. Expect bugs and severely limited functionality. Requires Python 3.7+ and tkinter. If you get tkinter errors, try reinstalling py-tk. Launch ESMB from the command line.