This is a collection of Windows scripts to make it easy to setup Windows. This includes application installation, taskbar settings, start menu changes, locale settings, default applications, and more coming soon!
Prerequisites
You may not be able to run the .ps1 script directly on the system due to your Execution Policy. You can run the start.bat file making it easy begin. It’ll only run the installApps.ps1 script by default.
Alternatively, you can run the following in an Administrator Powershell window to allow execution of scripts on your system permanently (Not Recommended).
Set-ExecutionPolicy-ExecutionPolicy Bypass
Getting Started
Download the codebase as a .ZIP.
Run start.bat OR one or both of the below commands in a regular CMD window.
The scripts accept two optional switch parameters which allow setting up ‘sets’ of programs to install and not asking the operator to confirm installation. They are -AppSet and -NoInterrupt respectively.
You can run the following command to install basic applications without prompting for the optional programs.
Alternatively, you can run the following to install basic applications, plus CustomSet1 (defined in the appCollection.ps1 file), without interruptions.
Sets of optional applications are defined in the appCollection.ps1 file. This file must be placed in the same root directory as the installApps.ps1 script is being run. The format of the file must be a valid Hash Table.
Defining Applications
Application names and associated chocolatey package names are located in the installApps.ps1 script. Simply add additional line or two with optional packages, the script will then ask if you want to install it on the next execution.
This script uses and depends on Chocolatey for application installations, and SetUserFTA for setting default applications.
Webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.
Everybody knows that developing runs on coffee! Thanks for your support!
Build Setup:
# Download repository:
git clone https://github.com/vedees/webpack-template webpack-template
# Go to the app:cd webpack-template
# Install dependencies:# npm install# or:
yarn
# Server with hot reload at http://localhost:8084/# npm run start# or:
yarn start
# Output will be at dist/ folder# npm run build# or:
yarn build
Project Structure:
public/*.html – HTML files
src/app – core app
src/shared – shared files
src/shared/img – images folder (! for html calls use correct path: static/img/some.jpg)
/webpack/webpack-defines.js – config for entire webpack
Main entry point:
src/app/index.ts – core entry point
Defines:
Core webpack config from /webpack/webpack-defines.js:
constPATHS={// path to the src dirsrc: path.join(__dirname,'../src'),// path to the output dirdist: path.join(__dirname,'../dist'),// path to the public files (html files)public: path.join(__dirname,'../public'),// path to output sub dir (js, css, fonts, etc.)assets: 'assets/',// path to output sub dir (img, icons, etc.)static: 'static/'}
Pages config:
Pages config from /webpack/webpack-pages.js:
constpages=[{// page titletitle: 'Home page',// template name `public/index.html`template: 'index.html',// output filename `dist/index.html`filename: 'index.html',// other options can be here},{title: 'About page',template: 'about.html',filename: 'about.html',}]
You can pass a hash of configuration options to html-webpack-plugin.
importReactfrom'react'import{createRoot}from'react-dom/client'// app stylesimport'./index.scss'// local providers:import{I18nProvider}from'./providers/I18nProvider'constcontainer=document.getElementById('app')asHTMLElementconstroot=createRoot(container)root.render(<React.StrictMode><I18nProvider>...</I18nProvider></React.StrictMode>)
File src/app/providers/I18nProvider.tsx:
importReact,{FC,PropsWithChildren}from'react'exportconstI18nProvider: FC<PropsWithChildren>=({ children })=>{// ...return<I18nlocale={detectedLocale}>{children}</I18n>}
Vue example:
Install vue:
yarn add vue
Init the app in src/app/index.ts:
// vue example (react one is above):constapp=newVue({el: '#app'})
This is the simplest possible build script setup for Cucumber using Java.
There is nothing fancy like a webapp or browser testing. All this does is to show you how
to install and run Cucumber!
Usage
Open a command window and run:
mvn test
This runs Cucumber features using Cucumber’s JUnit runner. The @RunWith(Cucumber.class) annotation on the RunCukesTest
class tells JUnit to kick off Cucumber.
Overriding options
The Cucumber runtime parses command line options to know what features to run, where the glue code lives, what plugins to use etc.
When you use the JUnit runner, these options are generated from the @CucumberOptions annotation on your test.
Sometimes it can be useful to override these options without changing or recompiling the JUnit class. This can be done with the cucumber.options system property. The general form is:
mvn -Dcucumber.options="..." test
Let’s look at some things you can do with cucumber.options. Try this:
-Dcucumber.options="--help"
That should list all the available options.
IMPORTANT
When you override options with -Dcucumber.options, you will completely override whatever options are hard-coded in
your @CucumberOptions or in the script calling cucumber.api.cli.Main. There is one exception to this rule, and that
is the --plugin option. This will not override, but add a plugin. The reason for this is to make it easier
for 3rd party tools (such as Cucumber Pro) to automatically configure additional plugins by appending arguments to a cucumber.properties
file.
Run a subset of Features or Scenarios
Specify a particular scenario by line (and use the pretty plugin, which prints the scenario back)
This is the start of a game involving some crazy technical jazz,
for the sake of magical minimalism.
The game will be a platformer,
with lots of interconnected rooms and various enemies,
taking some inspiration from Kirby & the Amazing Mirror.
(Some basics are implemented, like blocks, slopes, one-way platforms, and doors.
There are several rooms, but they’re pretty boring,
and the art is very preliminary.)
The game supports LAN multiplayer,
and the client’s world is simulated in between updates from the server,
a basic implementation of client-side prediction.
Single player is treated the same: the client hosts a server and communicates with it locally over TCP.
This might change.
When other servers are discovered,
a door is opened to another world.
Players can travel between worlds,
and you can even have two players in each other’s worlds.
(But the player’s client has to be online for their world to be available.)
You should be able to get a feel for the game in single-player,
with a substantial world to explore, but
I think multiplayer will be the real focus of the game
and I think it would be interesting to have parts of the world that you can only explore with a friend.
Oh, did I mention the worlds are gonna be procedurally generated?
That’s probably kind of important.
It might have some areas that are the same in all worlds, like a tutorial level,
or perhaps just fairly similar and functionally identical.
Both players should gain from exploring either players world.
It should be like the worlds combined make up the space to explore,
and which one to do first shouldn’t feel contentious.
There could be doors that require multiple keys, that you need to get from several people.
There could be keys that belong to random other worlds and you have to find the one player whose world contains the door.
There could be halves of items (including keys).
Keys could be 2D “pin arrays”, where locks run a game-of-life simulation for a number of iterations.
This would work well for a 1BPP game, as alternative to using color to distinguish keys.
There could be portals that you can pick up and place, including between worlds.
There should be limits on the viewport,
maybe fixed but not necessarily;
it could have a maximum viewport size, and the ability to look in a direction,
and then the total amount you could look could be fixed
while allowing for a range of screen sizes on handheld systems etc.
The game runs in nw.js (so it can include both client and server),
but the final game.exe is a wrapper.
The wrapper currently built with nexe,
although this essentially means distributing two Node.js runtimes,
which is a considerable amount of overhead which could ultimately be avoided.
It downloads the nw.js runtime (on first load)
and extracts a zip file from a resource in the executable containing the main application.
Then it launches the game, passing in the path to the executable.
It does all this so it can read and write game state from the end of the exe file.
(At the moment this functionality is disabled.
I did a tech demo of this first, but there are no persistent elements to the world yet.)
Open Doors to Other Worlds
Local multiplayer
Discovers other clients through tiny JSON files stored with ports and PIDs.
Discovers other clients through SSDP
TODO:
Manage input methods for multiple players.
You should be able to play with two people on one keyboard,
without some program to send input to two windows at once.
Could try to do single window splitscreen (“normal” local multiplayer) instead.
FIXME:
There is a race condition when going back and forth between rooms
where you can get viewing a room that you aren’t in.
Entering a door involves sending a command to the server
but you switch the room you’re viewing instantly.
TODO:
Remove the need for client-side prediction on the client’s own server;
maybe merge the client and the server so they use one World
TODO:
Use random seeds to render the exact same blades of grass etc. as another client for the same world.
(Also, with pixi.js, it’ll probably be fast enough to render the grass dynamically, so there could be wind and stuff,
rustling through the grass as you move,
explosions sending waves of air…)
Install
Final builds of the game will be standalone executables,
but there’s not much of a point yet to trying to release builds.
You’ll need Node.js. Clone the project
and then, in a terminal/command prompt in the project’s directory,
run:
npm install ; cd game ; npm install ; cd ..
Run
After installing, you can run the game with:
npm start
On the first run, it’ll download the nw.js runtime.
There are also scripts to run multiple instances of the game:
npm run start-secondary
npm run start-tertiary
These only work on Windows, but I could make a CLI script that works cross-platform,
and allows any number of instances,
plus other options like --enable-logging.
Build
The game implements hackily saving game data directly to the executable binary,
which is rather platform specific.
This is only implemented for Windows so far,
but it should be feasible on at least some other systems.
Core provides the functionality necessary to couple the individual SCINE
modules together. It is vital for the correct functioning of all SCINE
modules, but it does not directly provide any functionality for end users.
Therefore, only developers of SCINE need to directly interact with Core.
License and Copyright Information
For license and copyright information, see the file LICENSE.txt in this
directory.
Installation and Usage
As a user of one of the SCINE modules (such as Sparrow), you do not need
to set up Core yourself. Instead, this is done as part of the installation
process of the respective SCINE module. Therefore, the following instructions
are only necessary for developers of SCINE, or those implementing the
interfaces defined here.
Dependencies
Required software, minimum required versions in brackets, for this SCINE project are:
A C++ compiler supporting the C++17 standard
CMake (3.9)
Boost (1.65.0)
Installation
In order to compile this as a SCINE developer, execute the following
commands:
git submodule init
git submodule update
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=../inst ..
make -j 4
make CoreDocumentation
make test
make install
Usage
The main usage guidelines can be found in the part of the developers documentation
that is shared across all projects associated with SCINE.
How to Cite
When publishing results obtained with any SCINE module, please cite the following paper:
T. Weymuth, J. P. Unsleber, P. L. TΓΌrtscher, M. Steiner, J.-G. Sobez, C. H. MΓΌller, M. MΓΆrchen,
V. Klasovita, S. A. Grimmel, M. Eckhoff, K.-S. Csizi, F. Bosia, M. Bensberg, M. Reiher,
“SCINEβSoftware for chemical interaction networks”, J. Chem. Phys., 2024, 160, 222501
(DOI 10.1063/5.0206974).
Support and Contact
In case you should encounter problems or bugs, please write a short message
to scine@phys.chem.ethz.ch.
Third-Party Libraries Used
SCINE Core makes use of the following third-party libraries:
