Also, I'm glad that someone is working on a remake with such enthusiasm. Keep up the good work, qwerty!
Most of my enthusiasm comes from the community.
Ideas are important.
I've just started reading qwerty's source and I noticed that the breathing part is extremely detailed - and also hard to read, on that regard. Please keep in mind that this degree of accuracy isn't strictly necessary - from the player point of view, it's enough if it feels somewhere like that, but it need not work exactly like that. While realism to a certain degree is very nice, a well-abstracted representation that "works good enough in most cases" is preferable in my opinion, especially since the computer's resources are limited, even more so when building on an inefficient language like DM. Don't forget that DM was designed to create simple games and the designers never had extensive simulations or complex algorithms in mind.
In this case, you could for example remove the relation between the amount of blood and the amount of oxygen, which would probably greatly simplify the code, yet have little impact on the game play(when bleeding to death, you have other problems to deal with than suffocation anyway).
Of course, I can understand you enjoy researching and conceptualizing complex algorithms, so if that's your main motivation, you are free to make the game as complex as you want, but if you also want to make a fun game that is played by other people, you should take these considerations into account.
The player oxygen number acts as a buffer zone between oxygen and health loss.
Blood vs oxygen is basically a multiplier so that losing "only" 15% of your blood will make it harder to maintain oxygen levels. Naturally, you can compensate by reducing your oxygen use, mostly by stopping running everywhere, laying down, and maybe sleeping, this gives the medics time to heal you.
I already shifted some realism to fun: see that *40 in the oxygen gain? That was to match oxygen intake to use.
I agree that we dont want too many complex algorithms around to slow down the server, but just one or two wouldnt be too much of a problem, right?
Anyways, I'd like to propose something too: a standarized system for all machines to work on. What I mean by this, is that all machines use power in the same way (NOT same amount, same way as in we dont have one checking for wires while the other checks for APC in the area, etc...), and that they can somehow be made to communicate with each other (like, be able to connect a radio signaler to the communications pc so that sending a certain code on a certain frequency activates the communication computer to call the shuttle (if someone with necessary clearance is logged in on it, ofcourse), kind of like we already can do with airlocks). This would make for some INSANELY COOL contraptions IMO.
/obj/machinery/powered/door/airlockDoors are powered machinery.
To add such a feature, add it to machinery and all machinery, powered stuff, and doors will automatically work with it.
Depends on how often it is called. For example, calling a very complex algorithm every time someone moves, is.. bad. In general, it's just important to consider the effectiveness of the code.
All of the complex code is shifted into the once-per-second tick() (called from the world loop), when you move, it increments a counter of how active you have been recently. Then, when breathe() is called during the tick(), it takes your activity into account only when it needs it.
As for the old code, it would do a cosine for EVERY solar panel every time it or the sun moved.
The sun moved every 50 seconds, but with autotracking, each panel would move quite often.
Alright, since I really want bots in the game, I'm trying to add a skeleton to qwerty's source. However, it seems not to have been designed at all with something like that in mind, the /mob datum wholeheartedly assumes that every mob has hands, feet and organs. So you didn't plan to add jellyfish, qwerty? =(
All of the procs are defined on the mob.
When adding a bot, override the procs!
/mob/bot/tick() will override /mob/proc/tick(). you use active_item() elsewhere rather than active_hand().item or "mob.active_hand? mob.l_hand.item : mob.r_hand.item", so defining a bot to return current_tool can be done.
Qwerty, since you're basically creating a new SS13 from scratch, shouldn't we make it more dwarven?
Get rid of "Plasma" since Plasma is not a gas. It's a state of matter. (Blood plasma excluded. I have no idea why it's called plasma, but it isn't.) The blood plasma in medbay should be renamed as well. It should say blood plasma. Not just plasma.
I was thinking of replacing it with a "combustion mix" of generic hydrocarbons, optimized for combustion rather than using that ancient, crude, poorly mixed gasoline, or some futuristic substance that is unlikely to exist anymore(and doesn't right now anyway)
Also on the ideas-to-do list:
A materials reprocessing device.
It would be used to dispose of waste objects and break them down into their primary components for use in a more complex version of the autolathe.
This means that trash bins will be more common, you can access them like toolboxes and stuff, and it will be the janitor's duty to empty them into the materials reprocessing room(probably with the addition of wall-chutes, that could be used for purposes such as feeding prisioners and garbage disposal from within secured areas to maintainence areas.
It is also how you would properly discard scraps(that the autolathe will produce in bucketfulls as it works) and convert metal rods back into metal sheets.
Naturally it would be a bit of a power hog, less while idle.
Today's work(potential schedule):
-Full space-blocking windows
-one or more new equipment slot
-held item images?
-tile stacking and other multi-use objects
-putting multi-use objects base code into /obj/item
-regulating multi-use items with max_stack on the item's def
-certainly more.
Poll
67 (25.9%)
Author
Topic: Space Station 13 *READ RULES ON FIRST POST* (Read 824853 times)