C'est les soldes Steam, et du coup Energy Island Corp est à ~3€ !
C'est un petit jeu de gestion de réseau électrique un peu niche qu'on a sorti (Spirkop) en 2022.
Venez on a des bonnes reviews :D.

https://store.steampowered.com/app/1241710/Energy_Island_Corp/
#indie #indiedev #haxe #games

Save 50% on Energy Island Corp. on Steam

Build and manage an electric grid ! At the start of the day, build new infrastructure and plan your day. Once ready, start the day then watch electricity production / consumption in real time to adjust your buildings settings. The growth of the islands depends on you !

finally looking into the Haxe hxb format.

I'm guessing it's idempotent and based on the same thinking as HashLink.

#DevLog #Haxe

This is just nice code to write, and have around. I just upload the interpreter in the context, and invoke functions from the Dockerfile.
Immutable references, OS independent API, macros, type hints, schemas, repl with code completion etc etc.

I've got Haxe from source on windows, and Neko and Hashlink on Arch.

The architecture is fine, I think.

#DevLog #Babashka #Haxe

Oh Yay Oh Yay

#DevLog #DevOps #Haxe

Haxe’s codebase just hit a record high: 2.29B bytes total (up from 2.27B last month). #Haxe #github

My new Ryzen H 255 does chug through those builds quite well.
Did my Haxe dockerfile, which is Ubuntu base plus Ocaml setup plus Haxe from source and it shifted through it.

Don't know what's going on with devpod at the minute.

I'm going to be applying Babashka to some things, notably building shit because fuck me isn't it janky at the moment.

I wanted to try haxe-manager, and it requires Neko be installed, I made a fork of it and added Neko source as a submodule, and added the cmake to the install script. The haxelib calls the Neko in such a way as the libneko.so.2 can't be found, even though the built-from-source Neko works alright.

Add to that the build of haxe-manager requires a couple of Haxe libraries aren't included and I wanna rampage.

Podman is behaving better on Arch now, so there's that.

#DevLog #Haxe

Haxe 5.0.0-preview.1 - Lemmy.World

Lemmy

Because it's there for error passing style rather than throwing, the construction of Exceptions is lazy so as not to incur the penalty of building the callstack under normal circumstances, and it happens via the class hierarchy `fn.Reply` so that you can macro build it and/or serialize.

Error now assumes no typed value by default, and the only penalty of going from `E` to `Unit` to `EE` is that you wind up with islands of call tree information that can´t be typefully unified without reflection.

typed invocation looks like:
`__.stx().fail().of(typed_value);`

where 'fail()' quietly takes the position info, and passes it to the error constructor.

untyped, where 'f' is a hook for static extensions:
`__.stx().fail().blame((f:Faults) -> f.e_undefined())`

wrapping exceptions happens via
`__stx().fail().except(Reply.fromThunk(e))`

`Loc` has become `Callsite` and exists to allow some annotation for methods running in certain macro contexts where position information hasn't been determined.

#DevLog #Haxe

I've got an abstraction of `flat_map` that I call `through_bind` which I use to faff with the error type hole along with the main generic type, but it gets really hairy because the return of `Work<E>' has been `Iterator<Work<E>>` and I can't unify `E` and `EE` in sequencing without weird, possibly infinitely recursive code.

I've now gotten to `Activity = Iterator<Work<Unit>>` meaning the typed values of Error aren't used, and as this happens in the execution phase, there's no assembly of call trees happening anyway so `Task#reply` becomes something like
`Void->Null<Iterator<Work<Unit>>>`, so the iterator can become a fast track in the scheduler core.

This needs support upstream in `stx.fail` which provides the error abstractions so I took the opportunity to pretty drastically simplify the vocabulary.

The error system allows for is tagged tree building, which is super useful for debugging, and it also handles untyped and typed error information

1/n

#DevLog #Haxe

I can FINALLY post a new update of my #indiedev passion project #QuestOfRaziya!

All of this is possible thanks to the #Armory3D engine but mighty soon I'll be looking into the #Pyrite64 engine for an #N64 port!

#b3d #blender3d #3dmodeling #3Danimation #haxe #gamedev #gameart #pixelart #retrodev