there were a lot of events recorded by gharchive.org of which 2,227,958 were push events containing 3,237,316 commit messages that amount to 242,866,359 characters filtered with words.py@e23d022007... to these 24 messages:
objects set their physics layers/masks
2 global functions: func set_world_collision_layer(body, layer) func set_world_collision_mask(body, layer) both work exactly the same way. they take 2 arguments:
- the body (object) whose layer/mask we set;
- the layer (floor) associated with the layer/mask settings. when a "layer" is set, we match its value (0, 1, or 2) and set body.z_index and target_collision based on it. (layer 0: z_index = 0, target_collision = 12; layer 1: z_index = 10, target_collision = 13; etc.) these functions are called on obects' _ready(). right now, we export the "layer" variable and set it via inspector, and then objects set up their own collision values. there needs to a system to determine which floor a Player is on before they are initialized. right now, we simply initialize the player assuming he is on layer (floor) 0. however it should be possible to have the player spawn on layer 1 or 2. this should be a value set via PlayerSpawn. oh yeah, right now, we're basically spawning the Player at the location of the Camera if the map has no SpawnPoint. SpawnPoints should exist on layers too, and pass their layer value to Player(s) it spawns. so that's done. actually just had an idea - now that that's done - to have the GameManager receive a layer value when it's initializing Player(s). currently, to initialize a Player, we call GameManager.initialize_player(self) - before we used player_name as an argument. now, we are able to call:
player = Global.layer_nodes[value.layer].get_node("Player")
this gets the player's layer value and gets the layer node associated with the layer value, and adds the Player as a child of that node, placing them on that floor. in theory - haven't fully tested yet.
ladder mechanics: Ladders' functionality involves changing a climbing Player's collision mask from the layer on which the Ladder is placed (layer) to the one above it (upper_floor = layer + 1). this means that ladders will only ever get placed on floors 0 & 1. when a Player interacts with a ladder, we call climb_start(), whose functionality hasn't changed very much from before: set velocity to 0; disable the animationTree; set the sprite.frame; play the "ClimbUp" animation; *remove world collision masks (this is new); remove enemy collision mask; disable interactHitbox; set player.state = CLIMB.
when a Player is detected to have reached the upper or lower bounds of a Ladder while climbing, we call body.climb_end(new_layer), where new_layer = either ladder.layer (if exiting to the bottom) or ladder.upper_layer (if exiting from the top). if player.layer != new_layer (meaning, you arrived at a different floor than previously), then we call Global.change_floor(body, to_layer), which sets the following:
func change_floor(body, to_layer): body.layer = to_layer body.call_deferred("reparent", layer_nodes[to_layer]) set_world_collision_mask(body, to_layer)
...setting the layer of the body, reparenting the body, and setting the body's world collision mask. all the functionality is working. now need to set collisions for different TileMap layers/floors to test that out.
[MIRROR] [MDB IGNORE] Unironically removes the atmos and black beret (#4118)
- Unironically removes the atmos and black beret (#72722)
Removes atmos berets
Berets shouldn't be thrown into every job, it's milsim circlejerking
dressup shit that creeps out of our milsim containment jobs (security)
and into other innocent jobs. There is absolutely no reason for this job
to have a beret just straight up. Can we add unique hats to the game,
not the same one recolored every way to Sunday? That's my problem. We
don't have unique clothes, we have a billion types of beret when the
BASE BERET TYPE has IS_PLAYER_COLORABLE_1 so ANYONE can color it. So
again, why do we have the atmos beret? To clog the wardrobe, a vending
machine added specifically because we couldn't stop clogging the
original locker atmos techs spawned in?
The black beret has the same problem: recolored item when you can get the item of any color
🆑 del: Atmospherics beret and black beret /🆑
- Unironically removes the atmos and black beret
Co-authored-by: tralezab [email protected]
fixes panic bunker adjacent shitcode (#769)
-
ugly as hell
-
idiot
-
think before i commit (never)
absolute insanity
unbelievable constant bugs with the tilemap. it's breaking in every imaginable way. of course, it only broke after i'd completed it. it's completely fucking mind boggling. i'd set it up so that it was working perfectly, with no errors. y-sorting on floor 0 was achieved. swapping player's collision mask when using the ladder was working perfectly. then made the resource local. and the whole thing completely fucking spazzes out. terrain disappeared, and every tile gives an error. when trying to re-paint the terrain, only the center tile is drawable??? the entire tileset is broken and will probably need to be done from 0, meaning i have once again wasted hours of my life. just now, after reverting the project, once again, the collision just disappears. it just stops fucking working for no fucking reason whatsoever. oh but running the program again, the collisions are now working. for no fucking reason. oh but every tile is throwing an error, again. the TileSet resource is fucked. it's like, completely fucked in so many unexplainable ways. live & learn but fuck this. fuck this so fucking hard. the fucking Physics category in the TileSet editor has literally disappeared for the GrassyRidge tileset. it's just not fucking there. it's there for other tilesets, as it should be! but for ours, after i fucking finished it, the fucking parameter DISAPPEARS FROM THE FUCKING NODE. NOW I HAVE DOUBLE THE ERRORS. WITH NO FUCKING CHANGES. AND THE COLLISION HAS STOPPED WORKING AGAIN. WITH NO FUCKING CHANGES. i need to stop because i've already gone fucking insane wasting my FUCKING time with this fucking piece of garbage. just tried making the tileset resource unique. collision worked again when i ran it. then the fucking editor crashes. pain in the ass. fuck this.
Converts blindness and nearsightedness to status effects, scratches some VERY dumb blindness handling that resulted in mobs becoming "incurably" blind (#72267)
- Nearsighted is now a grouped status effect.
- Blindness is now a grouped status effect.
- Eye handling of blindness has improved.
- When eyes are removed, they now cause you to become blind, rather than
handling it in
update_tint. - Being ahealed no longer blinds you for one tick, meaning that black overlay on aheal is gone.
- Temporary Blindness is now a status effect.
- Both Nearsightedness and Blindness have been exorcised from mob vars
and life chains. This means that we've finally cut 2 procs from life,
handle_status_effectandhandle_traits, and moved both to event based processing. Wooo optimizations. - Swapped pacifism status effect to use apply and set helpers.
- Removed an unused admin toggle that disabled welding helmet tint but also tint from every clothing item and also blindness from losing your eyes.
- Clothes now generally all blind their mob more consistently.
- Oculine, eye surgery, and sensory restoration are now no longer the only way to fix blindness from eye damage. If your eyes are healed through any other means, it will also heal your blindness.
- Some things that made you blind, such as ling blind sting, no longer just flat made you blind from eye damage forever. They now cause eye damage directly, which in turn makes you blind from eye damage, as expected.
- Pacifists can't eyestab anymore. Eyestabs now have a limit on the amount of blur applied.
- Refactored some
is_x_coveredprocs to accept flags rather than have a lot of arguments for some silly reason. - Unit tests for blindness.
Blindness was exceptionally poorly handled prior, primarily due to the fact that it was tied to the mob instead of separated out
On top of that the system put a LOT of faith in proper handling of blindness on the coder's end which was misplaced evidently. Many places didn't update or handle blindness correctly, or just let people perma-blind.
Deferring it to a status effect improves this a lot
🆑 Melbert refactor: Refactored blindness and nearsightedness. Important to note is that all mobs are naturally blind until their eyes are actually created. refactor: Refactored "is covered" procs fix: Less sources of blindness now cause permanent blindness. Includes the "Blind" Spell and "Blind Sting" from changelings. admin: Ahealing someone no longer flashes the blind overlay for 1 tick. admin: I removed an unused (sort of) inaccessible admin verb that allowed you to toggle the tint from all welding helmets (and clothing) (and lack of eyes) in existence, let me know if you want similar back balance: Changeling "Blind Sting" now causes eye damage (enough to blind) rather than arbitrarily forcing blindness. balance: Visionloss virus symptom now causes eye damage (enough to blind) rather than arbitrarily forcing blindness. balance: Oculine has been reworked slightly. Prior, Oculine arbitrarily healed blindness and nearsightedness from eye damage reagrdless of how damaged the eyes were, and applied blur on success. Now, Oculine just heals eye damage, and blindness / nearsightedness is restored in the process. There is now a probability every tick that eye blur is applied based on how pure the oculine is while healing very damaged eyes. balance: Pacifists can no longer eyestab. balance: Any clothing item that covers your eyes contributes to getting the bonus while sleeping, and to removing temporary blindness faster /🆑
sid.java
Who remembers back to their time in the schoolyard, when girls would take a flower and tear its petals, saying each of the following phrases each time a petal was torn:
"I love you" "a little" "a lot" "passionately" "madly" "not at all" If there are more than 6 petals, you start over with "I love you" for 7 petals, "a little" for 8 petals and so on.
When the last petal was torn there were cries of excitement, dreams, surging thoughts and emotions.
Your goal in this question is to determine which phrase the girls would say at the last petal for a flower of a given number of petals. The number of petals is always greater than 0.
INPUT 1: 1 OUTPUT 1: I love you INPUT 2: 3 OUTPUT 2: a lot
skylaunch: Make TcpLogger use select() & support multiple clients
This was really annoying to do but it's a lot better than how it was before. There's now another event loop thread which uses select() and the fdset mechanism for handling multiple clients. Far cry from any C10K awards, but it's better than accepting once and never again
This kind of breaks using the skylaunch legacy TCP logging in emulators for now though because it seems like neither yuzu nor Ryujinx support nonblocking sockets, which kinda sucks :(
The code does work on real hardware though, which at least helped me not go completely insane writing it.
it hate my life
Signed-off-by: Lasse Gaardsholt [email protected]
tools: labs: qemu: Add run-qemu.sh as alternative
TL;DR: In one window run make -j$(ncproc) console and cd to some
lab's subdirectory (skels/...). In second window cd to matching
skels/... subdirectory, edit source files and compile with something
like kmake (alias kmake='make -C "$HOME/src/linux/" M="$(pwd)"') as
needed. The skels directory is shared between the host and the guest,
thus in the first window, so you can just insmod and rmmod the
compiled modules. You can kill the VM by CTRL-a x (if you made some
writes from the VM it might be a good idea to run sync first). Samba
and QEMU are required.
Full description:
To be honest I don't like the current QEMU setup. I am sure there are things it does that I don't understand yet, because I have not yet finished all the labs, but in any case I think that the setup can be improved.
Some things in particular I don't like about the current setup:
- "Huge" opaque
.ext4images are used, even though the contents of the root file system are not that large. - While running QEMU newly built modules can't be copied to the image.
- Mounting and unmounting the
.ext4image for copying the modules requiressudo. - The networking setup seems too complex, requires
sudoand was broken (at least for me - IIRC I didn't get IP through DHCP), thus I also didn't getsshto work. I also seem to be not the only one having issues with this: linux-kernel-labs/linux#240 (comment) dnsmasqandnttctpmostly don't start correctly (they are not killed correctly by the previous run) - this isn't a problem on my end, as demonstrated by the output at https://linux-kernel-labs.github.io/refs/heads/master/info/vm.html, which shows the same issues.- Running
minicomis required to access the serial port, thus at least two terminals are required for working with the VM (not a huge problem for me personally, since I usetmux, but I know some people complain about this). The setup also seems unnecessarily complex. - I remember a lot of the
.mon.ptsfiles being left uncleaned in some cases. - I recall warnigns about some of the entries added to
/etc/inittabbeing ignored. - Even though root login requires no password I have to enter the
rootusername.
In this commit I introdoce an alternative way of running QEMU through a
new run-qemu.sh script. The setup is laregely independent and its user
interface consists of console and gui targets. I tried to make the
script parameterizable through environment variables (inherited from
Make variables), though it may be argued that the default values should
be encoded in Makefile rather than in the script like they are now. I
have no strong opinions about that, it's' just that the current state
allows running the script in standalone fashion.
What the setup brings:
- A rootfs is extracted from the official Yocto Project tarball and
kept in a directory that is shared through Samba as network
share.
The
skelsdirectory is shared as well. Thus the modules can be freely tweaked / compiled / ran from either the host or guest. - The QEMU stdio serial console setup is used (
ttyS0on the kernel side). This means that running QEMU results in the serial console being mapped directly to standard input and output of the terminal -minicomis not needed. This is the console mode (make console). - The setup allows also allows the virtual machine to be run in
graphical mode (
make gui). - Root is logged in automatically in
consolemode (though similar thing could be done for theguimode). - Although Samba (
smbd) is required,sudoor root access is not. - Networking through QEMU's default SLIRP backend. DHCP is handled by the kernel, which overcomes some problems I had with the System V init system in the Yocto images.
- The compilation can largely be done with something like this
kmakealias:alias kmake='make -C "$HOME/src/linux/" M="$(pwd)"'(customize as needed). Though this is not enough for some labs (I no longer remember the details, but I think it was some of the earlier labs which had dependencies between modules, I think I used the classicmake buildfor that.
Known issues:
- SSH support is currently missing. This both requires more featureful
Yocto images and is IMO unnecessary, since it wouldn't bring much
benefit over the console mode. Though it can be easily achieved by
using QEMU option like
-nic user,hostfwd=tcp::2222-:22, which would allow SSH'ing into the guest by something likessh -p 2222 root@localhost. - I used a slightly less advanced setup while doing the labs, so the lab workflow with this particular setup is largely untested. There may be problems with file permissions due to the samba share.
- The guest seems to fail to shutdown correctly in a timely manner. I
just took the habbit of killing qemu with
CTRL-afollowed byx, potentially runningsyncfirst to ensure my work is saved (though rarely did I actually modify anything on the guest side).
The former setup
I used contains some details of the SSH setup if anyone is interested in
that. It was the basis for this PR, so some ideas can be seen there
(Samba share for skels), but I didn't take particular care with the
kernel config
and the automounting didn't really work (the init would try to mount
the filesystem before networking was up).
What I evaluated and didn't use in the end:
- At first I tried to extend my former setup by just automounting the
Samba share. I didn't manage to do this - the (non)workings of init
scripts seem to be beyond me. If anyone is interested here are a few
pointers:
[1],
/etc/inittab,/etc/init.d/mountall.sh,/etc/init.d/mountnfs.sh. - I tried using
9p[2], [3] [4] which is built into QEMU and can be compiled into the kernel. Withmapped-xattrsecurity model it would be too cumbersome to create the rootfs, andpassthroughwould require root privileges. It is also very slow. There are also some problems with trying to use it as rootfs, maybe specific tolinux-kernel-labskernel version or config. Ask me if interested. [5] [6] [7] - QEMU has an option to setup the Samba share on its own, though I found a custom config (based on the QEMU one) to be easier - allows customization like multiple shares, unix extensions, different port, etc.
Signed-off-by: Michal Vlasák [email protected] Signed-off-by: Daniel Baluta [email protected]
deleted ping whisper.sh Last-night-my-boyfriend-and-I-got-into-a-figh80ac43deba094f05475057c703feb8be.jpg
poppy, A dog is the only thing on earth that loves you more than you are love yourself, A dog will teach you unconditional love. if you can have that in your life, things wont be too bad, Outside of a dog, a book is a mans best friend. Inside of a dog its too dark to read, A door is what a dog is perpetually on the wrong side of, How many leg does a dog have if you call his tail a leg? Four. Saying that a tail is a leg doesnt make it a leg
Begin a sloppy implementation; need a way to get different lumens per light range
Try building a special illumination data structure that can represent what we need for lights. In future, consider moving away from a plain list of individual illuminations, and build up a specialized global data structure
Fix lumens overlay so that it does not add to the lighting cache; in the future, these should be unified anyways, and the light renderer should not have to depend on whether or not something was previously cached in just the right way
Add bitset for controlling whether to render lights and lumens overlay
Instead of bitset, rely on AppState in ZoneRenderer
Multiply in extra alpha so light opacity can be managed
Beef up the lumens border
Textured tintable lights
Rework soft lighting to use black-background lights; alpha had some wierd artifacts as near the edge had a sharp darkness
Go back to trying alpha-based; it is better using pegtop soft lighting (as is used in GIMP), but still gets a bit dark
Commit to premultiplied alpha for soft lighting; interpret extraAlpha as a light boost instead of a transparency effect
MULTIPLY blend is not used; recognize that SCREEN blend is really used for building up lights rather than composing layers; make sure we know whether we are using premultiplied or not
Stick to premultiplied images, but support others as well via color converters; performances is much better at ~50ms worst case
Tweak soft light for premultiplied usage; allow map to shine through by alpha compositing the soft light result back onto the map; no more use for boosting in soft lighting
Render lumens overlay on top of lights instead of the other way around; map lumens=50 and lumens=100 to match 1.11.5 dim and bright lights for predefined 5e torches
Settle on overlay for blending light layer onto map
Clip the final light overlay render rather than each individual light; this is a perf win for player view where lots of screen space does not need to be passed through a software blender
Create a new graphics context for the light overlay, which frees us from having to restore state; remove unused view and overlayOpacity parameters from renderLightOverlay
Remove doc for old parameter
Make darkness a separate type from normal lights
Some handy todo notes
Need to include darkness in the lumens map
Some lumens map clean up; working towards a world where we have one data structure to represent the actual lighting in a zone
Reenable darkness rendering; required us to be able to control both the light blending and overlaying behaviour for renderLightOverlay
Make a bunch of progress towards coalesced calculation of lit areas and drawable lights; BIG PROBLEM is performance, as there is no way to turn off these sometimes expensive calculations; Solutions include adding proper caching per light source, unioning of Path2D instead of Area, an allowance for on-demand calculation of the individual components of global illumination, and ultimately a bespoke data structure that can dynamically adjust as lighting changes are made
Rewrite getIllumination coalesence loop to use Path2D for lumens areas
Actually cache the results of getIllumination()
Clear up some names in the loop, and don't unnecessarily copy areas
Remove all the old lighting calculations in ZoneView in favour of the new stuff that obsoletes it
Now make sure we can support personal lights and daylight by actually building a per-view illumination structure
Now get rid of the new methods that are no longer used
Remove unused ZoneView.Illumination
Add a treatise on where to go from here
Rework lumens map into a list of lumens levels, where each level is not guaranteed to be disjoint; note that individual lights for a light source will in practice be disjoint, but once lights start overlapping that statement does not generally hold true
TEMP Implement an Illuminator data structure for speeding up lumens updates; still need to be able to produce drawable lights
Finish the first step of the illuminator. Has parity with stuff from before this change, but still needs personal and daylight support
TODO Notes galore
More TODOs
TEMP Begin accounting for sight magnifiers; the returned GlobalIllumination will now permit overlapping ranges in this case, and will rely on the handling of the lumens map to display them correctly; still need to make sure DrawableLights work (they won't because now they overlay, and it's not clear which one should win) and need to make ZoneRenderer actually look up the correct sights; will also need to merge results together when multiple tokens are in the view
Use the first token's sight type; sufficient for now, until we start merging results
Instead of caching on Sight, and instead of caching on View, cache on a special SightIlluminationKey that can have properties independent of any actual sight. E.g., by taking the maximum magnification
Calculate illumination keys in ZoneRenderer; only getExposedArea(PlayerView) and getVisibleArea(PlayerView) even rely on views anymore; thinking this means the illumination stuff can go into its own illumination model or something, but that is extra work that does not need to happen
Remove obsolete notes about SightTypes since we now use IlluminationKeys
Simplify lumens shade calculation understanding we don't yet have generality
Add todo note about empty lumens areas, esp for darkness
Add a second shade level easier magnification edge case testing
Fix which area we use for light in the presence of magnification; added todo note about how we need to fix drawable lights
For light hole punching, sort the ranges' areas by lumens and make sure the stronger ranges beats out the weaker ranges without overlap
Cleanup; removed already-actioned TODOs and unneeded methods
Keep track of which tokens have contributed to the lighting; use that when flushing a token to determine if vision needs to be recalculated; flush the illuminationCache in that case
Factor out large main loop of getAndCacheIllumination so it works on a single light token at a time
Stop caching illumination results, and instead keep illuminators around; allow remove LitAreas from illuminators
Fixup light invalidation to work even when adding a light source to a token and not just removing / modifying one
Track contributing tokens on a per-illuminator basis; otherwise we (of course) found that one illuminator would prevent additions to others
Add timer specifically for filling the lights during rendering
Clear the illuminators on ZoneView.flush(); future improvement is definitely to be as precise as possible in what information to throw away
Some todo notes on flushing
Add notes about caching in ZoneView and how it makes no sense
Clarify the isEmpty check and how we should do it and whether we even need it
Only grab lights and darknesses when actually needed
When rendering the lumens overlay, clip the original g as well as newG
More notes
Split Illuminator.getIllumination() into getVisibleArea(), getLumensLevels(), getLightAreas() and getDarknessAreas()
Rework ZoneView methods to use the new decomposed Illuminator methods; saves calculating things like drawable lights even when those don't need to be rendered; also is much easier to follow and eliminates GlobalIllumination
Slightly better naming
Handle case of token having no vision according to FogUtil
Add notes about per-view caching and the need for flushing
Make the remainder of ZoneView's caches per-view
This boils down to changing ZoneView.getVisibleArea(Token) to ZoneView.getVisibleArea(Token, PlayerView), which
required updating several callers, mainly macro functions and FogUtil. This method also had a thin wrapper
ZoneRenderer.getVisibleArea(Token) which was hardly used and has been removed in favour of a direct call to
ZoneView.getVisibleArea(Token, PlayerView).
Now that ZoneView can cache everything for multiple PlayerViews at once, ZoneView.flush() only needs to be called
in the situations now mentioned in its documentation. It does not need to be called when the current PlayerView
changes (thanks to the above changes), and is also no longer called when the map viewport changes. This greatly reduces
the amount of recalculation, and the sight-heavy sunless citadel map can now fluently switch views.
Fix flush(Token) to remove from the nested map instead of a type-incorrect removal from the top-level map (thanks for nothing Java)
Link to fields in doc comments instead of via plain names; remove references to old fields no longer with us RIP
Get rid of a bunch of obsolete TODOs
Do a real isEmpty check rather than checking for a zero center of the bounding box
Change FogUtil.calculateVisibility to not transformed its areas; otherwise we sometimes have to copy areas just to translate it afterwards
Add another debugging hot key for showing single lumens levels
Clip both the light buffer and the underlying buffer when rendering lights, for performance
Do lumens map hole punching in ZoneRenderer
START Begin moving Illuminator away from direct knowledge of lights and light sources, instead only caring about lumens and areas
Render lumens overlay overtop light and darkness; only retrieve drawable lights when lighting is enabled (performance); change bright light to not be entirely clear, but still draw a nearly transparent white
No longer require disjoint lumens levels; begin move toward a single Illumination result type
Calculate visible area from returned Illuminations
Expand on the nature of darkness in our new lighting system
Calculate drawable light areas based on the illumination
Remove genericness of Illuminator as we no longer rely on the user data to associate lit areas with the originating lights
Remove reliance on IlluminationKey in ZoneRenderer, recognizing the results will generally depend on the entire PlayerView
Factor out per-view token selection logic
Encapsulate tokenVisibleAreaCachePerView so we can use it more freely
Include personal lights and daylight in the results used for drawable lights
Do not include non-renderable daylight in contributed personal lights
Include personal light and daylight in the lumens map
Put both light and darkness into each lumens level; TODO Make sure we don't unnecessarily work with empty areas to our detriment
Only use the sight's multiplier for personal lights; don't use the illumination key's multiplier
Fix the sign of personal darkness
Cache per-view illuminations
Clean up LitAreaUserData to reflect its new nature
From ZoneView remove completed todos or todos that have not aged well
Disable antialiasing in light overlay; it's less important with textured lights, and is the cause of some gapping or even slight overlapping that then makes really bright rings
Cache personal lights per-IlluminationKey instead of required stashing per-PlayerView
Calculate and cache token visible areas per-IlluminationKey instead of per-PlayerView
Do not cache token's personal lights or visible areas according to IlluminationKey, but solely according to Token since they don't actually depend on it
Regroup fields for clarity
Non-lights changes to get rid of DARKNESS
ZR changes for lumens level
Fix multi-range light hole punching when mixnig darkness and light
Update ZR for BC changes
Fix to not magnify darkness
Improve performance of calculateVisibleArea(PlayerView) by using the Illumination we already have
ZR changes now that light now longer has a getPaint()
ZR now uses tinted paint provided by LightSource
It's kinda annoying to see all the buttons open up a new tab all the time. That's why I suggest you take out that feature, except for the login button, and the exist button in the end screen, every other button shouldn't open a new tab in my opinion.
main game setup + shop!!
There's been a lot of progress since the last update that I am excited about :D The main part of the game is setup well with a woof and money counter and I have even setup the shop!!
It is looking very plain right now using just some random placeholder images and texts but the important thing is that it all is functioning properly!! It is using scriptable objects and arrays of item template prefabs, which means it is easily expandable.
I am planning to create a little inventory system before making the shop items purchasable so that I will have a place to send them already once I do get working on that.
Patch Notes:
- dimmed temporary background
- increased starting money for testing purposes
- added 'dev buttons' to add money quicker and reset to 100 money
- added shop and shop button!!
- made temporary layout of shop
- created a side scrolling shop interface where items/submenus will be held
- created item scriptable objects
- created script to handle adding created items to shop panels and display the appropriate information
- created script to hide extra unused shop panel templates
- setup item purchase buttons to be active or not active if the player has enough money to afford it
- text update script will now update the text in the shop to display the player's money
- started creating an inventory menu
well i think that is everything! I was thinking about doing some research on how I can improve these update notes to make them easier to read and maybe even more 'professional', but I am working by myself and I know as someone who loves playing games, I would completely enjoy more personal update notes from game developers. I love the genuine connection it gives, making you really feel that there's amazing people behind these games and not just some giant corporation trying to make money. I'm excited for the experience making this game will give me and I look forward to improving as a game developer!!
♟ The BLUNDER Speaks for Itself ♟ Let this match be a reminder to not celebrate too soon™, just because you are up in material.
✝❤️🧡💛💚💙💜🤍💜💙💚💛🧡❤️✝ We barely remember who or what came before this precious moment We are choosing to be here right now Hold on, stay inside... This holy reality, this holy experience Choosing to be here in... This body, this body holding me Be my reminder here that I am not alone in... This body, this body holding me, feeling eternal All this pain is an illusion ✝❤️🧡💛💚💙💜🤍💜💙💚💛🧡❤️✝
Over thinking, over analyzing, separates the body from the mind Withering my intuition, leaving opportunities behind
Feed my will to feel this moment Urging me to cross the line Reaching out to embrace the random Reaching out to embrace whatever may come ♟
Tell me exactly what am I supposed to do Now that I have allowed you to beat me Do you think that we could play another game? Maybe I can win this time 🥇
Add color support to Windows console output, properly
This adds color support to the output of the console on Windows. Now if you're using Windows 10 build 1511 or later (I think it's build 1511 anyway; they added more VT sequence support in later versions), you will see colors by default. This isn't due to Windows helping in any way; this commit has to specifically enable it with SetConsoleMode() because by default, Windows won't enable color support unless we enable it. (Or if it's enabled in the registry, but having to go through the registry to enable basic shit like that is completely fucking stupid.)
I tested this in my Windows 10 virtual machine and it's completely working.
🥇♟ The DECISIVE VICTORY Speaks for Itself ♟🥇 - The Duke of Death 💀
"Victory at all costs, victory in spite of all terror, victory however long and hard the road may be; for without victory there is no survival." ~ Winston Churchill
"Kill them all, God will recognise his own." ~ Arnaud Amaury, Abbot of Citeaux
"The strength of God will enable us, a small but faithful band, to overcome the multitude of the faithless." ~ Robert Guiscard
"War is delightful to those who have had no experience of it." ~ Erasmus
🎶 https://youtu.be/TJbTXtIt5ts?t=2766 🎶🎵
♟ https://youtu.be/2ISWn2ZbQdw?t=105 ♟
FUCK THIS FUCK THIS FUCK THIS FUCK THIS FUCK THIS
FUCK IT, NO MORE """CLEVER CODING""", NO MORE TRYING TO CHEAT THE SYSTEM.
FUCKING WARP DOORS DIDN'T WORK ANYMORE, SO YOU'RE JUST GONNA HAVE TO LIVE WITH SETTING isWarp YOURSELF, YOU LAZY ASS MOTHERFUCKERRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR!!!!!!!!!!!!!!!!!!!!!!!!!!!!
fucking my brain with brainfuck is fucking amazing. And so is reducing code clutter
http: support CURLOPT_PROTOCOLS_STR
The CURLOPT_PROTOCOLS (and matching CURLOPT_REDIR_PROTOCOLS) flag was deprecated in curl 7.85.0, and using it generate compiler warnings as of curl 7.87.0. The path forward is to use CURLOPT_PROTOCOLS_STR, but we can't just do so unilaterally, as it was only introduced less than a year ago in 7.85.0.
Until that version becomes ubiquitous, we have to either disable the deprecation warning or conditionally use the "STR" variant on newer versions of libcurl. This patch switches to the new variant, which is nice for two reasons:
-
we don't have to worry that silencing curl's deprecation warnings might cause us to miss other more useful ones
-
we'd eventually want to move to the new variant anyway, so this gets us set up (albeit with some extra ugly boilerplate for the conditional)
There are a lot of ways to split up the two cases. One way would be to abstract the storage type (strbuf versus a long), how to append (strbuf_addstr vs bitwise OR), how to initialize, which CURLOPT to use, and so on. But the resulting code looks pretty magical:
GIT_CURL_PROTOCOL_TYPE allowed = GIT_CURL_PROTOCOL_TYPE_INIT; if (...http is allowed...) GIT_CURL_PROTOCOL_APPEND(&allowed, "http", CURLOPT_HTTP);
and you end up with more "#define GIT_CURL_PROTOCOL_TYPE" macros than actual code.
On the other end of the spectrum, we could just implement two separate functions, one that handles a string list and one that handles bits. But then we end up repeating our list of protocols (http, https, ftp, ftp).
This patch takes the middle ground. The run-time code is always there to handle both types, and we just choose which one to feed to curl.
Signed-off-by: Jeff King [email protected] Signed-off-by: Junio C Hamano [email protected]
small fix(es)
Small fixes. Lots of them. Mostly rebalancing and half-dicking around the code - too lazy to write the items and abilities, so I decided to work on the interface a bit and maybe even optimise some code. Honestly, I should rewrite everything with one array for both gonlins and dwarves but at this point I might as well develop the game into state of usability and then redo it.
I promise to fix the multiplayer issue tomorrow or something. This is the last push before I tackle it - gonna mark a major rework of the data architecture. Mostly an insane amount of Ctrl + R and quality check if everything is working and looking good. There's gonna be blood.
♟ The SHEEP Speaks for Itself ♟ 🔪🐑
🎵🎶 https://youtu.be/v719eZmXRdE?t=270 🎶🎵
Tell me my life is about to begin Tell me that I am a hero, Promise me all of your violent dreams Light up your body with anger. Now, in this ugly world it is time to destroy all this evil. Now, when I give the word get ready to fight for your freedom Now -
Stand up and fight, for you know we are right We must strike at the lies That have spread like disease through our minds. Soon we'll have power, every soldier will rest And we'll spread out our kindness To all who our love now deserve. Some of you are going to die - Martyrs of course to the freedom that I shall provide.
I'll give you the names of those you must kill, All must die with their children. Carry their heads to the palace of old, Hang them high, let the blood flow. Now, in this ugly world break all the chains around us, Now, the crusade has begun give us a land fit for heroes...
Stupid me #facePalm . KSPe looks for the config file on <add-on-dir>/PluginData , not on <add-on-dir>/Plugins/PluginData! (and I wrote the damned thing…)
For net-lisias-ksp/DistantObject#25
[MIRROR] Refactors memories to be less painful to add and apply, moves memory detail / text to memory subtypes. Adds some new memories to demonstrate. [MDB IGNORE] (#18487)
- Refactors memories to be less painful to add and apply, moves memory detail / text to memory subtypes. Adds some new memories to demonstrate. (#72110)
So, a huge issue with memories and - what I personally believe is the reason why not many have been added since their inception is - they're very annoying to add!
Normally, adding subtypes of stuff like traumas or hallucinations are as easy as doing just that, adding a subtype.
But memories used this factory argument passing method combined with holding all their strings in a JSON file which made it just frustrating to add, debug, or just mess with.
It also made it much harder to organize new memories keep it clean for stuff like downstreams.
So I refactored it. Memories are now handled on a subtype by subtype
basis, instead of all memories being a /datum/memory.
Any variety of arguments can be passed into memories like addcomponent
(KWARGS) so each subtype can have their own new parameters.
This makes it much much easier to add a new memory. All you need to do is make your subtype and add it somewhere. Don't need to mess with jsons or defines or anything.
To demonstrate this, I added a few memories. Some existing memories had their story values tweak to compensate.
Makes it way simpler to add new memories. Maybe we'll get some more fun ones now?
🆑 Melbert add: Roundstart captains will now memorize the code to the spare ID safe. add: Traitors will now memorize the location and code to their uplink. add: Heads of staff winning a revolution will now get a memory of their success. add: Heads of staff and head revolutionaries who lose their respective sides of the revolution also get a memory of their failure. add: Completing a ritual of knowledge as a heretic grants you a quality memory. add: Successfully defusing a bomb now grants you a cool memory. Failing it will also grant you a memory, though you will likely not be alive to see it. add: Planting bombs now increase their memory quality depending on how cool the bomb is. refactor: Memories have been refactored to be much easier to add. /🆑
- Modular!
Co-authored-by: MrMelbert [email protected] Co-authored-by: Funce [email protected]