Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Armok]

Yea, having to do this kind of thing is a pain for everyone, but it's a deeply unavoidable part of designing and complex mathematical structures (such as computer programs), and it happens to the best. All the time.

[SethCreiyd]

Spoiler: Update soon. (click to show/hide)

Systems for materials and liquids were added in, along with a method of constructing items from parts.  Containers hold up to a specific volume, and liquids take up a specific amount of space - a 500ml beaker will only hold 500ml of water before spilling over.  There are methods for displacement and liquid diffusion - I wanted to avoid a distinction between liquid items and actual liquids.  When liquids combine, the less voluminous liquid is stored as a 'solution' in the more voluminous liquid.

Items can be examined a bit more closely - more or less specific information will be displayed depending on what the player character knows about the item in question.  Parts now have inventories and can be filled with various items or liquids as needed.  There's also a method for registering separate parts as touching one another, which will be applied to appropriate character interactions as needed.

With luck, I'll have something to upload in the next few days, once a few more things are finished and tied together.

[Minstrel]

This is fantastic, playing the demo now.

[SethCreiyd]

Thanks Minstrel.  The next version will be very different in structure, though the general appearance of things will be about the same.

It's been a rough slog - right now, selecting an appropriate part for a given interaction between objects involves iterating over all the parts in their bodies and then iterating over each bodypart's type list.  It seems pretty clunky, and even something like picking up an object becomes a complicated mess of determining what part of the item to grab with which bodypart.

Fortunately, most of the groundwork for that is finished, and the finer tuned it gets the easier stuff will be to add.  The method for loading a bullet into a revolver is now the same method for putting a bottle of water into a bag; it's contextually implicit, and the inventory of the revolver's chamber is not functionally different than that of the bag, aside from capacity and such.

The firing of the bullet is now a matter of velocity, mass and force, and damage from impact will be calculated accordingly and applied to bodyparts instead of the current hit point setup.  The next big step, after this part/interaction work, is a priority queue for object actions, whereby objects take a turn more often as their speed increases.  Projectiles are now treated as ordinary objects in motion, so they'd be subject to the same queue, meaning that with enough speed, a character could outrun a bullet or bat it out of the air (though for creatures with normal speed, they'd appear to move instantly as they do now).

I won't have much time this weekend to work on it, but on Monday I'll try and get an update-worthy build finished.

[Vorthon]

Posting to watch. Because SCP goodness.

[Armok]

Sounds awesome! I don't see how the iterating is a problem, unless you need to do it thousands of times per turn, have hundreds of parts for each object, AND have hundreds of types per part. If you absolutely want to fix it, which I still think is unnecessary, making a list of types that ANY part of the object has, and using "[type] in [set]". Or maybe a dict with type as the key and links to the relevant part as the value.

[Wrex]

Something fast, as in SCP-72-1?


So how will you handle the SCP's with great speed, strength, and world bending powers?

[Person]

Glad to see this is still being worked on. Not much I can say until the next demo really other than keep it up.
Edit: As a side note demo .006 doesn't seem to work for me, although I am running windows 7 so that might be a factor. I tried to use the source code directly since I have python installed anyway, but when it didn't work I realized I didn't know which version you were coding in. I realized it was 2.6 after some code delving, and after downloading that I realized I'd probably have to fiddle with a lot of things given that I already have python, and gave up for now. Regardless, here's the error it generates as soon as I click the exe.
Traceback (most recent call last):
  File "site17.py", line 20, in <module>
  File "slib.pyc", line 142, in load_settings
UnboundLocalError: local variable 'file1' referenced before assignment

[SethCreiyd]

Spoiler (click to show/hide)

Sounds awesome! I don't see how the iterating is a problem, unless you need to do it thousands of times per turn, have hundreds of parts for each object, AND have hundreds of types per part. If you absolutely want to fix it, which I still think is unnecessary, making a list of types that ANY part of the object has, and using "[type] in [set]". Or maybe a dict with type as the key and links to the relevant part as the value.

Thanks Armok - I did add a few functions for filtering parts out of objects, specific coordinates, etc, mostly to cut down on repetitive type: 

(EDIT: bad code.  nevermind.)

_{Trouble is, different actions between objects have different requirements, and filter_parts isn't always applicable.  At any rate, the current implementation is a mess with lots of boilerplate, but I'd rather have it all working sooner and clean it up later.}

Part Equipment is a subclass of dict now, cause it's easier to work with them if they can have attributes assigned (though special keys in the dictionary itself could work too, so it might go that way too).  I was subclassing list for an Inventory class, but this ran into lots of problems, so instead I'm using composition for that:

Something fast, as in SCP-72-1?


So how will you handle the SCP's with great speed, strength, and world bending powers?

As they come, I suppose.  It's all relative, but ideally the code should be accommodating enough to account for super stats (for instance, you might never apply enough force naturally to knock down a hardened security door, but 682 certainly might).  Interactions between objects should occur naturally according to the properties of each: For instance, the difference in applied force between a cardboard box and a bookshelf each falling on something shouldn't be scripted, but a consequence of the mass and speed of each falling object in question.

Reality-bending is a different story, but there should be lots of ways to implement strange, world-altering effects.  Levitating objects, changing the map terrain, manifesting creatures and objects - these don't sound extremely difficult to achieve once more stuff is in place.

Glad to see this is still being worked on. Not much I can say until the next demo really other than keep it up.
Edit: As a side note demo .006 doesn't seem to work for me, although I am running windows 7 so that might be a factor. I tried to use the source code directly since I have python installed anyway, but when it didn't work I realized I didn't know which version you were coding in. I realized it was 2.6 after some code delving, and after downloading that I realized I'd probably have to fiddle with a lot of things given that I already have python, and gave up for now. Regardless, here's the error it generates as soon as I click the exe.
Traceback (most recent call last):
  File "site17.py", line 20, in <module>
  File "slib.pyc", line 142, in load_settings
UnboundLocalError: local variable 'file1' referenced before assignment

Definitely a bug, thanks for telling me.  The temp folder is missing, and .006 doesn't know to create one if it isn't there.  To fix it, you can create an empty folder named 'temp' in the game's folder (there's one in the .zip, but it's empty and nothing special), or you can add the following line to site17.py:

Code: [Select]

temp_path = os.path.join(os.getcwd(), "temp")
# print 'Temp path:',temp_path
if not os.path.isdir(temp_path): os.makedirs(temp_path) #<----- ** add this line **
settings = slib.load_settings('options.txt', 'options', temp_path)
slib.filter_settings(settings)
The load_settings function was cheap too.  In the next version it tells the player if the options file wasn't loaded, and defaults are used in place.


I'm still finishing up the code for storing/dropping items, and opening/closing containers, and throwing/shooting items needs to not crash.  I'll probably leave part-specific damage for after the speed priority-queue is done.

Update: Still working.  After struggling with concepts like factories and implementing dozens of poorly-chosen methods and turning the code into incomprehensible spaghetti, I took some time to grow more acquainted with Python.  The current code is in bad need of a major tuneup, but at least now I'm feeling up to the task.  Stay tuned, I've got to finish this update before I bring it to the SCP Wiki for their approval.