Kobolds with a keyboard.

  • 5 Posts
  • 1.38K Comments
Joined 3 年前
cake
Cake day: 2023年6月5日

help-circle




  • I wouldn’t call myself a veteran by any sense, and it’d be helpful if you posted a screenshot of your scene tree so we can see what you’re working with. A few notes:

    Generally speaking it’s recommended to keep scenes and their associated scripts in the same directory. You can subdivide your /scenes directory further, as well, to organize things, but really your structure is up to you and whatever works for you is fine.

    Consider making one “Main Menu” scene, and adding all of the sub-menus as children. Rather than adding and removing children, you can just hide / show them as needed. The increased resource usage to keep them all in the scene tree at once is extremely minimal and should have exactly zero impact. This also makes it easier to, for example, show the menu over a paused level if the user presses Escape (or whatever button you use), and it makes it easier to assign references to the sub-menus, using exported variables.

    (If you add @export before a variable declaration, the variable shows up in the Godot editor when you select the node the script is attached to, and you can assign values there. This creates dynamic references to e.g. scenes, and if you move the scene in your folder structure or the scene tree later, it will automatically be updated. With the ‘hard coded’ paths you’re using currently, you’ll need to manually go and update those references any time your file structure changes.)

    I’d use a simple state machine to manage this. A very basic implementation is to have a “states” enum with your various states (e.g. MAIN_MENU, OPTIONS, LEVEL_SELECT, etc.), and a “current_state” variable. Make a ‘change_state’ function that has 3 components:

    1. ‘Exit’ the current state. This is where you run any code that needs to happen when a state ends - for example, when you exit Options, you want to hide the Options menu node, etc.
    2. Change the state, where you actually set the state variable to the new value
    3. ‘Enter’ the new state, where you include code related to the new state starting - for example, for Options, this is where you Show the window (and maybe run an initialization function inside the options menu script, if needed).

    It’s a very compact way to keep all of the code in one place and make it very easy to add new states or functionality later. For the project as a whole, you might want to consider a more robust state machine if it warrants it.

    Edit: here’s a quick and dirty example of what a (very basic) state machine might look like for a single thing like this:

    enum States {
    	NONE,
    	MAIN_MENU,
    	OPTIONS,
    	LEVEL_SELECT
    }
    var current_state = States.MAIN_MENU
    
    func change_state(new_state:int) -> void:
    	# Exit state
    	match current_state:
    		States.MAIN_MENU:
    			main_menu.hide()
    		States.OPTIONS:
    			options.hide()
    			options.save_options_to_disk()
    		States.LEVEL_SELECT:
    			level_select.hide()
    			set_next_level(level_select.chosen_level)
    	
    	# Set state
    	current_state = new_state
    	
    	# Enter state
    	match current_state:
    		States.MAIN_MENU:
    			main_menu.show()
    		States.OPTIONS:
    			options.show()
    		States.LEVEL_SELECT:
    			level_select.show()
    

    You can use a similar state machine to handle (for example) player actions - have states for Jumping, Running, Walking, Standing, Climbing, etc., and use the state machine to both start and stop animations as needed, and to gate input (to prevent, for instance, jumping while already jumping.)

    Edit #2: Without seeing the rest of your code it’s hard to say if this applies, but just as a note: If you’re removing scenes from the scene tree, then re-instantiating them the next time you need them, you’re potentially creating a memory leak. You either want to store references to the scenes after you remove them, and just re-add them to the scene tree, or you want to free them (via queue_free()) which actually removes them entirely and frees up the memory they were using, then reinstantiate them later. (Removing children doesn’t actually remove the scene from memory.)



  • Here’s a thought experiment: imagine Instagram, but every single post is a video of paint drying. Same infinite scroll. Same autoplay. Same algorithmic recommendations. Same notification systems. Is anyone addicted? Is anyone harmed? Is anyone suing?

    Of course not. Because infinite scroll is not inherently harmful. Autoplay is not inherently harmful. Algorithmic recommendations are not inherently harmful. These features only matter because of the content they deliver. The “addictive design” does nothing without the underlying user-generated content that makes people want to keep scrolling.

    This feels like an awful argument to make. It’s not the presence of those things that make Meta and co so shit, it’s the fact that they provably understood the risks and the effects that their design was having, knew that it was harming people, and continued to do it anyway. I don’t care if we’re talking about a little forum run by a Grandma and Grandpa talking about their jam recipes; if they know that they’re causing harm and don’t change their behavior, they should be liable.


  • KoboldCoterie@pawb.socialtolinuxmemes@lemmy.worldThe Minefield
    link
    fedilink
    English
    arrow-up
    74
    ·
    16 小时前

    Based on the responses in this thread, I feel like you could present this screenshot with a “I bet you couldn’t find your way out of this!” and a zip of the directory, and a significant number of users would voluntarily download it and extract it just to “prove that they could”.


  • No wonder why they have a higher rate of obesity

    To be fair, this isn’t just about portion sizes, it’s about what’s in those portions. We have a ton of heavily processed, wildly unhealthy food options, and they’re all the budget friendly ones. Getting things like fresh fruits and vegetables is much more expensive than it should be, so we have this weird situation where it’s possible for someone to be both food insecure and also overweight, just because the food they do get is so unhealthy and fattening.



  • I’m really not sure if this is just folks not understanding that there’s differences in how things are taught between countries, or if it’s just willful ignorance.

    My only familiarity with European school systems is what I’ve been told, so you can feel free to correct me if this is incorrect, but my understanding is that at the same grade level where Europeans are learning the European countries, Americans are learning the US states. It’s even roughly the same number of data points to learn. Just because the map you selected doesn’t show these particular lines on the map does not mean they don’t exist, and US states are, purely in terms of land area and population, about equivalent to European countries.

    To head off the objection before it comes, we also learn the counties and important cities in our own states, which would be the equivalent of learning subdivisions of European countries.






  • Being able to point out the US on a map is like pointing out Russia. You can just throw a dart in the general right direction and you have a pretty good chance of hitting it just because of how absurdly large it is. Even if all you know is the continent and nothing else, you have more or less a 1 in 3 chance if you just guess a random spot. Calling the location of the country in North America and the general location of the capital “knowing our local geography” is like me claiming to know European geography (which I certainly don’t) just because I can point to Russia, Italy, England and a few other rather distinct locations.


  • States are more important to Americans than European countries are, when it comes to knowing where things are, because Americans interact with other states with the same regularity that Europeans interact with other countries. The point that I’m trying to make, which seems to be being largely ignored, is that comparing American knowledge of European geography to European knowledge of European geography is just as disingenuous a comparison as comparing European knowledge of US states to American knowledge of US states.