2,424,802 events, 1,238,648 push events, 1,943,648 commit messages, 148,573,728 characters
Merge branch 'master' of github.com:Limeahd/test828 fuck you
Getting annoyed with the stupid framework shit.. Will look at it tomorrow.
added pac-bar and hooked up all the gif changes, god bless hooks. I am too tired and cavemaned that shit hard.
Attention
Hi Ass Hole Scammer Give Back our money i fuck Callisto shitcoin this project completely scam
give back my money
yohan give back my money i buy 10 million callisto shitcoin in 500 satoshi price now callisto price is 6 satochi give back my money i fuck your project and not cant to be continiue scam asshole scammer
Waterworks: Plumbing enabled sinks, tanks, plant trays, and showers. (#52865)
https://cdn.discordapp.com/attachments/326831214667235328/740812723956482118/2020-08-06_02-04-14.mp4 For everything in this PR working at the same time, watch this video!
Alright, from the top: Sinks now need plumbing to pump out liquids.
All sinks now has a demand-only plumbing pipe face the opposite direction of the sink itself. A standard iron sink will hold 100 units of water, and must be constructed from a sink frame. To complete the frame, a new stock part, the water recycler must be applied to the frame. Once the sink is constructed, it will only hold those 100 units of water until new water is piped in. This however doesn't extend just to water, as a result. Any reagent can be piped into the sink, and will be used 5 units at a time per use. This means water isn't just an infinite resource, and will need to be resupplied to the station if, somehow, you're using a metric ton of water somehow. image A basic sink setup with water being plumbed in. Showers now need plumbing to wash you off.
Want to dispense reagents faster on your Patients Victims Friends Coworkers? Well, you may also construct a shower frame, in a similar fashion to a sink frame, and pipe in your own reagents into the loop. The shower drains reagents much faster than the shower, and also preforms vapor and touch reagent reactions, resulting in a constant stream of chemicals being processed. This can lead to horrible situations, like a chemical heater hooked up to a vat of cooking oil being pumped into a shower. Additionally, showers will display the reagents they're pumping out visually based on the color of their chemical contents. As a result, dangerous or unique showers are going to look noticeably different if their contents are dangerous looking. image A safe shower. image A very unsafe shower. Wait what was that bit about cooking oil?
So, reagent dispensers, like water/fuel tanks, Virus Food, Cooking Oil Vats, Pepperspray, and the like, can now be converted into a stationary tank of reagents by using a sheet of metal on it, allowing it to behave as a simple supply of their respective contents, and can be pumped into a plumbing network. This means rolling water tanks can be used to resupply sinks and showers, as well as allow for inventive uses of otherwise unused chemicals located all around the station. Pump welding fuel into a resupply line to fight a blob! Pump pepper spray into the dorms showers! Create a deep fryer shower! The possibilities are LIMITED (Because we have very few reagent dispensers)! Still, this will prevent sinks and showers from being completely unfix-able should all the water run out, as cargo can purchase many of these chemical tanks at will. Hydroponics is now also plumbing enabled.
So there I was, thinking, have I gone mad? Is the barking I hear in my noggin my own dogs rattling and raging against the eternal ocean tide, or are these the hounds of tindalos come to finally rip me to shreds within the sea of causality? The answer to this is quite simple: I added plumbing simple-demand components to hydroponics. Now, the trays will accept a pumping input, which can provide the plants themselves a reagent input for their nutrients, and SHOULD (current not fixed yet) also contribute to refilling the trays water. As a check to this horrible decision, there are very few plumbing chems that don't suffer from some kind of downside if exclusively pumped into the trays, so this should be done delicately and with forethought applied, or you'll have a row of plants with dead stats because they OD'd on ammonia. image Holy damn why are you doing this
I'm thinking this pr is probably in need of some serious trimming and will probably be closed as a result of the need to atomize this down, but this way I can start to get some feedback and ideas on which aspects would be better suited towards the current design direction of plumbing/bio-chem/reagent heavy jobs. As far as I'm aware, this is all in accordance with the relevant design docs, but this way I'll know for sure 🤷♂️ To-do before being 100% sparkly and clean
Fix hydroponics trays adding water to the nutrient reagents slot (NOT A TRUE FIX, SEE COMMENTS BELOW PLEASE) Make disconnected sinks/showers slowly regenerate water so that a stationwide plumbing net isn't required so Anturk doesn't snap my kneecaps off Make water/fuel tanks use their snowflaked stationary tank sprites instead of the custom overlay version
Yeet out the existing psudo-plumbing from hydroponics
Why It's Good For The Game
We've discussed adding plumbing into the game for forever now, and with all the new and tangentally related plumbing content we have, almost everything we have now perfectly enables servers to properly create a station-wide plumbing network.
Sinks and showers provide an infinite supply of water all shift long, and since they can be produced with any material, anywhere, practically for free, that was the first and foremost reason why I made this PR, to make water slightly more precious on station, to justify the 20+ water tanks mapped across every station. Plus, no more meatsink spam in the middle of the hallways.
Hydroponics has a built in feature that was intended to work similar to plumbing, before we had plumbing, for sharing resources/water, but it was pretty rough and is still exceptionally difficult to make look very pretty on live servers. By integrating them with actual plumbing pipes, this enables one step closer to integrating chemistry and botany to merge going forward, and give them an incentive to include each other in their supply chains each shift.
On the reagent tank conversion, That's just an interesting feature I felt the need for while testing everything else, and found pretty great success in. Being able to pipe in large supplies of a single reagent that ordinarily would just sit on a wall or in mait somewhere proved extra useful, and would be beneficial for refilling plumbing heavy areas like bathrooms/medbay, etc.
add zone restrict hack tools
similar to the layer zoning tools I just rolled out!
not thrilled about the outfit state hacks here bc of how we cache restrict on the appearance rather than the item, but oh well! this escape hatch is pretty easy and solid, and it's a cleanup for another day
Also did a code split here, now that this file is getting larger, to only load this for support users. I don't actually care about restricting console stuff to support users (I'd honestly rather not), but saving the bytes is worth it I think, since support mode is pretty easy to enter when we need to
UV MAPPING map01
Goddamn man, like, seriously. I’m proud of myself for figuring out UV stuff but jeez it was frustrating. I did finally get it figured out though. I will painstakingly go through and replace the models in each map that require intricate texture mapping. I wish Substance Painter had non-uniform paint layer transform, that would have made this easier.
Sorcery A19 - Fire Public Release
Play 7 Days to Die as a balanced post apocalyptic zombie vanquishing Sorcerer. Through training and discovery, you'll learn how to deport the undead straight back to hell by casting elemental spells of Fire, Ice and Lightning. • Vanilla game 100% untouched, add-only policy! • Balanced around vanilla gameplay, you must train to gain and sustain your power! • Unique animations, art, effects and sounds for spells and items • New Spells: Craft, Master and Upgrade 5 Spells per element! • New Enemies: Touched, Fallen (Champion), Awakened (Boss), Ancient (Raid) • New Attributes: Sorcery, Fire, Ice, Lightning • New Resource: Spirit (mana required to perform all Sorcery) • New Dual Skill Tree and Perks: Arcane, Fire, Ice, Lightning • New Crafting: Armor, Weapons, Mods, Spells, Potions, Scrolls, Stations, Blocks, Resources • New Armor Sets: Arcane, Fire, Ice, Lightning • New Masteries: Alchemy, Runesmithing, Spirit, Essence, Arcane, Fire, Ice, Lightning • Play-style: Sorcerer (Spellcaster) • Play-style: Alchemist (Potions, Bombs) • Play-style: Archer Mage (Spell Arrows) • Play-style: Gun Mage (Spell Ammo) • Play-style: Melee Mage (Spell Weapons) • Weapon Abilities: Primary, Secondary, Passive and Charge abilities • Rune Mods: Harness the power of Runes to augment your weapons, armor and gear! • Alchemy: Craft Potions, Elixirs and Bombs • Sexy Loot: Item Sets, Armor, Weapons, Mods, Spells, Potions, Scrolls and more!
Plain text editors: nano in basic, emacs and vim in high-level
While a project is under development, the raw analysis software are not the only necessary software in a project. We also need tools to all the edit plain-text files within the Maneaged project. Usually people use their operating system's plain-text editor. However, when working on the project on a new computer, or in a container, the plain-text editors will have different versions, or may not be present at all! This can be very annoying and frustrating!
With this commit, Maneage now installs GNU Nano as part of the basic tools. GNU Nano is a very simple and small plain text editor (the installed size is only ~3.5MB, and it is friendly to new users). Therefore, any Maneaged project can assume atleast Nano will be present (in particular when no editor is available on the running system!). GNU Emacs and VIM (both without extra dependencies, in particular without GUI support) are also optionally available in 'high-level.mk' (by adding them to 'TARGETS.conf').
The basic idea for the more advanced editors (Emacs and VIM) is that project authors can add their favorite editor while they are working on the project, but upon publication they can remove them from 'TARGETS.conf'.
A few other minor things came up during this work and are now also fixed:
-
The 'file' program and its libraries like 'libmagic' were linking to system's 'libseccomp'! This dependency then leaked into Nano (which depends on 'libmagic'). But this is just an extra feature of 'file', only for the Linux kernel. Also, we have no dependency on it so far. So 'file' is not configured to not build with 'libseccomp'.
-
A typo was fixed in the line where the physical core information is being read on macOS.
-
The top-level directories when running './project shell' are now quoted (in case they have special characters).
"3:05pm. I needed that break. Let me do a little bit more. I am thinking whether to read Her Majesty's Swarm as well, but let me do some work here as I feel like it. I'll leave the 3 chapters I am behind on for later.
First of all, let me get the tedious stuff out of the way. I need to print function for T. Then I will do the print function for type errors.
I'll leave the value restriction for last.
...No actually, no. Let me do the value restriction first. That will allow me to get it out of the way as yet another error. I'll want to have a special value restriction type error, and I do not want to do it after I am done with the print.
So it is decided.
let rec has_metavars x =
let f = has_metavars
match visit_t x with
| TyVar _ | TyConstraint _ | TyHigherOrder _ | TyB | TyPrim _ | TySymbol _ -> false
| TyForall(_,a) | TyInl(_,a) | TyArray a -> f a
| TyApply(a,b,_) | TyFun(a,b) | TyPair(a,b) -> f a && f b
| TyRecord l -> Map.exists (fun _ -> f) l
| TyMetavar(x,_) -> trueAh, this is all I need for value restriction. Lucky me.
type_application |> Seq.iter (fun x -> if has_metavars x.Value then errors.Add(range_of_expr x.Key, ValueRestriction x.Value))Wow this was easy. This is all I needed for the value restriction.
3:20pm. Ok, the next thing on the list is the type show function.
One troublesome thing is that I do not have the names for higher order functions. Let me put the uri and the name in the higher order dictionary.
type HigherOrderCases =
| HOCUnion of Var list * Map<string,T>
| HOCNominal of Var list * T
open FSharpx.Collections
type TopEnv = {
hoc : HigherOrderCases PersistentVector
ty : Map<string,T>
term : Map<string,T>
}I need to change this.
type HigherOrderCases =
| HOCUnion of name: string * Var list * Map<string,T>
| HOCNominal of name: string * Var list * T3:20pm. Ok, I've added the name and did the necessary extensions. Eventually I'll have to extend it with the uri as well, but for now this is fine.
3:35pm.
| TyVar x ->
let n =
match x.kind with
| KindType -> x.name
| _ -> sprintf "(%s : %s)" x.name (show_kind x.kind)
if Set.isEmpty x.constraints then n
else sprintf "%s %s" n (show_constraints x.constraints)Hmm, instead of having this here, it might be better to put this in the forall.
3:45pm.
let rec show_t (env : TopEnv) x =
let f = show_t env
let show_var (a : Var) =
let n = match a.kind with KindType -> a.name | _ -> sprintf "(%s : %s)" a.name (show_kind a.kind)
if Set.isEmpty a.constraints then n
else sprintf "%s %s" n (show_constraints a.constraints)
match x with
| TyVar a -> a.name
| TyMetavar(_,{contents=Some x} & link) -> f x
| TyMetavar _ -> "?"
| TyHigherOrder(i,_) -> match env.hoc.[i] with HOCNominal(name,_,_) | HOCUnion(name,_,_) -> name
| TyB -> "()"
| TyPrim x -> show_prim x
| TySymbol x -> sprintf ".%s" x
| TyForall(a,b) -> sprintf "∀ %s. %s" (show_var a) (f b)
| TyInl(a,b) -> sprintf "%s => %s" (show_var a) (f b)
| TyArray a -> sprintf "array %s" (f a)
| TyApply(a,b,_) -> sprintf "%s %s" (f a) (f b)
| TyFun(a,b) -> sprintf "%s -> %s" (f a) (f b)
| TyPair(a,b) -> sprintf "%s, %s" (f a) (f b)
| TyRecord l -> sprintf "{%s}" (l |> Map.toList |> List.map (fun (k,v) -> sprintf "%s : %s" k (f v)) |> String.concat "; ")This is mostly right, but in addition to this I need to fold in the things on the right side.
3:50pm. Shit this is annoying. To print this properly I need eliminate the parentheses. And to do that I need to keep track of the precedence.
3:55pm. Ok, I think I get it. This is not too hard.
4pm.
| TyForall _ ->
let a, b =
let rec loop = function
| TyForall(a,b) -> let a',b = loop b in (a :: a'), b
| b -> [], b
loop x
let a = List.map show_var a |> String.concat " "
sprintf "∀ %s. %s" a (f 0 b)This is the right way to do the forall.
| TyInl _ ->
let a, b =
let rec loop = function
| TyInl(a,b) -> let a',b = loop b in (a :: a'), b
| b -> [], b
loop x
let a = List.map show_var a |> String.concat " "
sprintf "%s => %s" a (f 0 b)Here is the inl.
| TyArray a -> sprintf "array %s" (f 29 a)
| TyApply(a,b,_) -> sprintf "%s %s" (f 30 a) (f 29 b)
| TyFun(a,b) -> sprintf "%s -> %s" (f 20 a) (f 19 b)
| TyPair(a,b) -> sprintf "%s, %s" (f 25 a) (f 24 b)Now when deciding whether to put parenths or not I need to take note of the precedence here.
let p prec' x = if prec < prec' then x else sprintf "(%s)" xHmmm, but...
| TyArray a -> p 30 (sprintf "array %s" (f 30 a))
| TyApply(a,b,_) -> p 30 (sprintf "%s %s" (f 29 a) (f 30 b))
| TyFun(a,b) -> p 20 (sprintf "%s -> %s" (f 20 a) (f 19 b))
| TyPair(a,b) -> p 25 (sprintf "%s, %s" (f 25 a) (f 24 b))Did I get the tuple right here, or should it be lower than the function?
Yeah, this is the right precedence.
a,b -> c is parsed as (a,b) -> c as it should be.
4:10pm.
let show_t (env : TopEnv) x =
let show_var (a : Var) =
let n = match a.kind with KindType -> a.name | _ -> sprintf "(%s : %s)" a.name (show_kind a.kind)
if Set.isEmpty a.constraints then n
else sprintf "%s %s" n (show_constraints a.constraints)
let rec f prec x =
let p prec' x = if prec < prec' then x else sprintf "(%s)" x
match x with
| TyVar a -> a.name
| TyMetavar(_,{contents=Some x} & link) -> f prec x
| TyMetavar _ -> "?"
| TyHigherOrder(i,_) -> match env.hoc.[i] with HOCNominal(name,_,_) | HOCUnion(name,_,_) -> name
| TyB -> "()"
| TyPrim x -> show_prim x
| TySymbol x -> sprintf ".%s" x
| TyForall _ ->
let a, b =
let rec loop = function
| TyForall(a,b) -> let a',b = loop b in (a :: a'), b
| b -> [], b
loop x
let a = List.map show_var a |> String.concat " "
p 0 (sprintf "∀ %s. %s" a (f 0 b))
| TyInl _ ->
let a, b =
let rec loop = function
| TyInl(a,b) -> let a',b = loop b in (a :: a'), b
| b -> [], b
loop x
let a = List.map show_var a |> String.concat " "
p 0 (sprintf "%s => %s" a (f 0 b))
| TyArray a -> p 30 (sprintf "array %s" (f 30 a))
| TyApply(a,b,_) -> p 30 (sprintf "%s %s" (f 29 a) (f 30 b))
| TyPair(a,b) -> p 25 (sprintf "%s, %s" (f 25 a) (f 24 b))
| TyFun(a,b) -> p 20 (sprintf "%s -> %s" (f 20 a) (f 19 b))
| TyRecord l -> sprintf "{%s}" (l |> Map.toList |> List.map (fun (k,v) -> sprintf "%s : %s" k (f 0 v)) |> String.concat "; ")
f 0 xThis is promising.
Now I have to implement show_prim, show_constraints and show_kind.
let show_primt = function
| UInt8T -> "u8"
| UInt16T -> "u16"
| UInt32T -> "u32"
| UInt64T -> "u64"
| Int8T -> "i8"
| Int16T -> "i16"
| Int32T -> "i32"
| Int64T -> "i64"
| Float32T -> "f32"
| Float64T -> "f64"
| BoolT -> "bool"
| StringT -> "string"
| CharT -> "char"This one I mostly pasted from the previous version. What I need to do is deal with the last two.
4:15pm.
let show_constraint = function
| CNumber -> "number"
let show_constraints x = Set.toList x |> List.map show_constraint |> String.concat "; " |> sprintf "{%s}"That is one thing down.
Now I need show_kind.
4:20pm.
let show_kind x =
let rec f prec x =
let p prec' x = if prec < prec' then x else sprintf "(%s)" x
match x with
| KindMetavar {contents'=Some x} -> f prec x
| KindMetavar _ -> "?"
| KindType -> "*"
| KindConstraint -> "/"
| KindFun(a,b) -> p 20 (sprintf "%s -> %s" (f 20 a) (f 19 b))
f 0 xThis should do it.
4:25pm.
| TyRecord l -> sprintf "{%s}" (l |> Map.toList |> List.map (fun (k,v) -> sprintf "%s : %s" k (f -1 v)) |> String.concat "; ")
f -1 xActually, the starting value here should be -1.
p 0 (sprintf "∀ %s. %s" a (f -1 b))The same for this here.
p 0 (sprintf "%s => %s" a (f -1 b))And here.
I am pleased by all of this.
Everything is nice now.
Without a doubt, I have show_t.
4:35pm. Let me commit here. I want to take a break. The next thing on the list are printing of type errors, but I want to chill for a bit first.
https://medium.com/@hajinlee/impact-of-go-ai-on-the-professional-go-world-f14cf201c7c2
Let me read this."
Factor out bip buffer functionality, make things work... more properer, but still fucking broken to shit. Cool job me, thanks man.
Updated Ost Hanover bc Game said Fuck you your german now
Bug 1646794 - Add basic infrastructure for collecting data on the performance of individual build actions r=mhentges,froydnj
This, hopefully, begins to address an ongoing global problem where we have few, if any, insights into the performance of individual build tasks (compilations, calls into Python scripts, etc.) At most we have aggregated statistics about how long tiers last, combined with sccache aggregates across the entire build (which don't cover non-compilation tasks). This has a few implications:
-
It's impossible to identify bottlenecks, except by going out of your way to notice and reproduce them. e.g. no one, to my knowledge, was aware that
make_dafsa.pywas a bottleneck until someone happened to notice and report it in bug 1629337. We could have systems that automatically detect this sort of thing, or at least that make it easier to do so than by CTRL-C'ing in the middle of the build several times to try to reproduce the problem. -
It's impossible to detect regressions, unless the regression is so pronounced and severe that it has an immediate impact on the overall build time and triggers build time alerts.
-
It's impossible to identify that you have fixed regressions, except by doing ad-hoc timing measurements by building individual
maketargets. This is error-prone and annoying.
Here we propose a low-friction system wherein individual build tasks log their build own perf info. For now, that's a write to stdout consisting of the string BUILDTASK followed by a simple JSON object with a start time, end time, the argv of the task, and an additional "context" key (I anticipate this could be used to annotate the task with relevant per-task for later aggregation, for example: was this an sccache cache hit or not? For now, it's empty everywhere). The build controller then collects this data, validates it, and writes out the entire list of build tasks as a JSON file after the build has completed, similarly to what we already do with build_resources.json. We already parse some make output to do stuff like tracking when we switch tiers, so this isn't a huge architectural shift or anything.
In my opinion this "should" happen at the build system, or make, level, but make doesn't expose anything resembling this information to my knowledge, so this has to be implemented outside of make. One could implement something like this at the sccache level but that doesn't touch anything but C/C++/Rust compilation tasks; an ideal solution would support other generic build tasks. We could also fork make to add this feature ourselves, but for several reasons I don't think that's tractable. :)
Of course, this approach has downsides:
-
We depend on parsing the
stdoutofmake, and processes can unfortunately sometimes trample on each other, leading to data loss for individual build tasks occasionally. This is a necessary limitation of the model to my knowledge, and I don't know that it can be fixed generally. In my testing, not much data tends to be lost usually. -
Dumping arbitrary data to
stdoutisn't always possible or desirable. If you're not careful about it this can also result in noisier-than-necessary tasks, especially when those tasks are not invoked by a parent process that knows how to handle the specialBUILDTASKlines. -
This data is raw enough where aggregation is not completely trivial.
-
This functionality has to be added for any new kind of build task whose performance we'd like to track; it doesn't come "for free" due to not being able to be implemented at the build system level.
-
The data isn't awfully small due to the
argv's (at this point, not nearly big enough where we need to be concerned about it IMO, but maybe that will change in the future?)
One can imagine a couple other architectures that could avoid the first two problems, namely: 1) we could use a "real" database that would not dump info to stdout and wouldn't lose data, like sqlite3; or, 2) we could set up another server, similar to sccache, that collects this data from subprocesses and aggregates it, making sure not to lose any along the way. Both of these have enough overhead, in terms of engineering effort or actual impact on latency, where I dont know that they make any sense to even attempt implementing. The remaining continue to be real issues, however.
After this is landed there are a few ways forward. We can start uploading these files as build artifacts in CI to allow us to reason about performance impacts of changes in central. We can easily add this functionality to the sccache client to start tracking those builds as well. We already have a very simple visualization of build tier timing in mach resource-usage; we could join that data against the BUILDTASK data to produce a very clear visualization of build bottlenecks, i.e., "why is the export tier taking so long", etc.
Differential Revision: https://phabricator.services.mozilla.com/D80284
Correct tests
1 Peter 3 contains the following USFM in the committed ulb file:
\v 9 Do not pay back evil for evil or insult for insult. On the contrary, continue to bless, because for this you were called, that you might inherit a blessing.
\s5
\q
\q \v 10 "The one who wants to love life and see good days
\q should stop his tongue from evil and his lips from speaking deceit.
\q
\v 11 Let him turn away from what is bad and do what is good.
The old parser does not properly parse the \q so verse 10 is missing. There are 4 notes and 1 question related to 1 Peter 3:10, accounting for 8 note links and 2 question links.
This and the previous commit address that.
(and 1 verse being off explains 33103 vs 33104)
Fix more stupidity crashes related to enemies ceasing to exist the instant they die (I really wish some modders weren't fucking stupid doing that, yes, you can guess what kind of mod triggered this).
Attempting to fix SN's bullshit fucking up my repo. Scoped apps really suck, SN. Get it together.
Add Mlioglotl, a new Lugonu-themed unique.
The vision for Mlioglotl is to add a new unique with a strong flavour themed around Lugonu and the Abyss. In-game description:
"A demon prince once betrayed his realm through a dark ritual to Lugonu. Becoming the twisted mass of corruption known as Mlioglotl was his reward.
Seeing such a powerful acolyte of Lugonu within the mortal plane is a rare sight indeed, and one should fear the denziens and horrors of the Abyss that are never far behind."
Gameplay flavour vision: A hulking mass ("unique thrashing horror" wouldn't be far off the mark visually speaking) charging after the player whilst tearing open rifts between the dungeon and the abyss.
Gameplay design vision: The player is torn between wanting to focus damage onto Mlioglotl to stop him casting further instances of corruption, and needing to deal with anything too nasty that is spawned. This is similar to the dynamics between the player and many of the monsters with summoning spells in the game, however, as Mlioglotl's corruption is transferring monsters to the mortal plane rather than summoning them, monsters that appear as a result of Mlioglotl's corruption are durably summoned, which adds a relatively novel additional angle to the interplay between player and 'summoner'. Of course Mlioglotl is no pushover himself either, and is positioned via depth marker to show up only later in the game.
The mechanics of Mlioglotl corrupting the dungeon are handled though a new monster spell 'corrupt_locale'. This effectively triggers a customised version of the Lugonu corruption player ability with a vastly toned down duration and toned down monster set.
One concern with any kind of level-altering effect of course would be that a player could kite the monster around and use them to 'shatter' open difficult geometry. Mlioglotl is fast, and hits relatively hard, which perhaps is enough to deter this tedious behaviour, however I'd welcome feedback on other potential methods to disincentivise this such as preventing Mlioglotl from using stairs (he has a large tile currently, so this would fit the visual-language-precedence set by the Royal Jelly).
Anyway, this is my first time digging into the source code of crawl beyond vaults and tiles, so apologies in advance for any convention breaking that I'm not aware of. Always happy to tidy up, make suggested changes, and generally take my submissions in a direction that others feel is most healthy for the game.
Thanks,
aMcNicky
More sensible compiler (#33)
- Cleanup Compiler
This basically just removes a bunch of "Gotta make it work" style hacks I did previously.
- Map First
This normalizes the oneOfs that exist, which make it marginally less awful.
- Reduce OneOf Nesting
This basically adds a very stupid check to ensure you never have a oneOf within a oneOf.
- Fix how Nullable Works
This is because we started using symbols for primitive types instead of strings to avoid weird modify-the-string bugs.