traverseda / pycraft Goto Github PK

I'm decoupling the view (drawing to canvas) from the world logic, but I'm finding that I need to either hand a 'world reference' to view, and a 'view reference' to world in main OR call functions on both of them from window, and hand data back and forth.

I'm after clean modularity, and down the line the possibility of running the world without a view. For that I think functions called by window would be better. But they both seem kinda kludgy.

Are there any pros and cons I'm missing?

By moving the mouse, the algorithm that makes the camera drive mapping seems to have excessive acceleration when the camera is on the horizon height causing the mouse stick it in the zenith or nadir view.

Not sure why but when I run pycraft i can barely move the cursor and the game freezes every second or so.

On windows 10 if that matters.

Any ideas?

hey guys, was trying to mod the game so it would use defaul textures and do better terrain gen (with like caves etc) and then i found this in world.py:
self._shown[coords] = self.batch.add( 24, GL_QUADS, self.texture_group[block.identifier], ('v3f/static', vertex_data), ('c3f/static', shade_data), ('t2f/static', texture_data))
this is the drawing of the world.
notice that it says "static". the world changes every frame and it should be "stream". after i changed terrain gen was so quick i couldnt see non-generated chunks anymore.... maybe something to add for ya guys :P

Items that aren't in any inventory.

We don't have to treat it like minecraft does. It might make more sense to add a "pile" chest-like object to tiles with loose objects.

Traceback (most recent call last): File "/usr/local/bin/pycraft", line 11, in load_entry_point('pycraft==0.1.0', 'console_scripts', 'pycraft')() File "/usr/local/lib/python3.5/dist-packages/pycraft-0.1.0-py3.5.egg/pycraft/main.py", line 28, in main pyglet.app.run() File "/usr/local/lib/python3.5/dist-packages/pyglet/app/init.py", line 143, in run event_loop.run() File "/usr/local/lib/python3.5/dist-packages/pyglet/app/base.py", line 136, in run self._run_estimated() File "/usr/local/lib/python3.5/dist-packages/pyglet/app/base.py", line 165, in _run_estimated timeout = self.idle() File "/usr/local/lib/python3.5/dist-packages/pyglet/app/base.py", line 274, in idle redraw_all = self.clock.call_scheduled_functions(dt) File "/usr/local/lib/python3.5/dist-packages/pyglet/clock.py", line 309, in call_scheduled_functions item.func(ts - item.last_ts, *item.args, **item.kwargs) File "/usr/local/lib/python3.5/dist-packages/pycraft-0.1.0-py3.5.egg/pycraft/window.py", line 127, in update self.gamestatemanager.peek().update(dt, self.ticks_per_second) File "/usr/local/lib/python3.5/dist-packages/pycraft-0.1.0-py3.5.egg/pycraft/gs_running.py", line 148, in update self.world.process_queue(ticks_per_second) File "/usr/local/lib/python3.5/dist-packages/pycraft-0.1.0-py3.5.egg/pycraft/world/world.py", line 172, in process_queue self._dequeue() File "/usr/local/lib/python3.5/dist-packages/pycraft-0.1.0-py3.5.egg/pycraft/world/world.py", line 160, in _dequeue self._show_block(coords, self.area.get_block(coords)) File "/usr/local/lib/python3.5/dist-packages/pycraft-0.1.0-py3.5.egg/pycraft/world/area.py", line 57, in get_block return self.blocks[coords] if self.blocks[coords] else None KeyError: (134, -1, -131)

just a quick bit for installing and running the game in the README would probably be a good addition to make the whole thing more approachable/lower the barrier to entry.

Licences printed by test ( little change to the test about not failing right away but test all of them and fails after, preparing PR).
!!!(failed, licence not found or not accepted) NAME_OF_MODULE : LICENCE

I am looking for help about individual licences, check if they are OK and each module with licence UNKNOWN need to be checked manually. Put everything in comments

matplotlib:BSD
PyYAML: MIT
numpy: BSD
MarkupSafe: BSD
pwquality: BSD or GPLv2+
Jinja2: BSD
!!! python-dmidecode: GPL-2
!!! lxml: UNKNOWN
!!! sepolicy: UNKNOWN
!!! python-systemd: LGPLv2+
!!! Brlapi: LGPL 2.1
!!! pycups: GPLv2+
!!! Pillow: Standard PIL License
!!! rpm-python: UNKNOWN
!!! pyparted: GPLv2+
!!! pygobject: GNU LGPL
!!! PyIscsi: UNKNOWN
!!! pygpgme: LGPL
!!! sosreport: GPLv2+
!!! openshot-qt: GNU GPL v.3
!!! devassistant: GPLv2+
!!! langtable: GPLv3+
!!! pid: ASL
!!! blivet: UNKNOWN
!!! python-augeas: UNKNOWN
javapackages: BSD
pytz: MIT
pyinotify: MIT License
urllib3: MIT
pyglet: BSD
requests-file: Apache 2.0
ntplib: MIT
requests-ftp: Apache 2.0
six: MIT
requests: Apache 2.0
future: MIT
cssselect: BSD
Mako: MIT
humanize: MIT
decorator: BSD License
Beaker: BSD
python-dateutil: Simplified BSD
httplib2: MIT
iniparse: MIT
IPy: BSD License
pyparsing: MIT License
progress: ISC
!!! setroubleshoot: GPLv3+
!!! dnf-langpacks: GPLv2+
!!! PyGithub: UNKNOWN
!!! python-meh: UNKNOWN
!!! slip.dbus: UNKNOWN
!!! cupshelpers: UNKNOWN
!!! chardet: LGPL
!!! slip: UNKNOWN
!!! seobject: GPLv2+
!!! initial-setup: GPLv2+
!!! pykickstart: UNKNOWN
!!! SSSDConfig: GPLv3+
!!! fros: GPLv2+
!!! pyxdg: UNKNOWN
!!! pyudev: LGPL 2.1+
!!! dapp: GPLv2+

Is this method correct? One give it tuple of 3 floats ant it round it and return as int? Round if i am correct means 5.4 = 5 and 5.5=6 and 5.8=6. Is that correct? If yes i am repairing that test
def normalize(position): x, y, z = position x, y, z = (int(round(x)), int(round(y)), int(round(z))) return x, y, z

I'm on Windows 10 (x64) and I use Python 3.6.1. I set the directory to this project's directory and used the following command:

pip install -e .

And I got an UnicodeDecodeError. But the following command is OK for me:

python setup.py develop

After using this command I can run Pycraft successfully.

Enhancement for #2

Right now, there are like 3 different places where we import/define textures.

It will involve some digging into pyglet, but we definitely need to de-duplicate that.

I'm imagining a "texture" object, that has textures for more then one block.

Blocks return coordinates and a reference to their texture in it.

I think heightmaps could lead to some very interesting effects, and in the future we might want to support dynamic textures (maps) or layered textures (signs).

But we don't need a perfect solution off the bat. Just a quick system for defining a texture in one place, and having the renderer read them.

If you switch to WeakStone and try to place the block it will causing KeyError.
I've tried debugging it, but the only solution I could come up with was not to use WeakStone at all and use Stone instead.

Last merge request (#72) seems to have messed something up.
Right click places two blocks instead of one, I don't know if that was intended or not.
Does anyone else have the same behavior?

Probably yaml.

Right now the world is responsible for part of the rendering. It shouldn't be. We want it to be as simple as possible to implement new worlds.

Is it just me or are all blocks black on the bottom now?

What are the intended target platforms for pycraft?

Are we just going to target Windows, Mac, and Linux PCs or are we going to Target smart devices powered by android and iOS as well?

Referencing #34 as this is worth talking about.

Do you think we could open up some sort of chat, that makes communication a bit easier?

The two places I'm in anyway:

• IRC (e.g. Freenode)
• Slack (devolio-devchat.slack.com)

Just thought I'd add this in here, as I'm currently working on it.

Having at least some of the more essential functionality unit tested will help immensely when we start adding more complexity.

There's still quite a lot of decoupling yet to be done that might go along with this.

It's a little hard to see in the image below, but fog doesn't work when building this project on Mac (more specifically, El Cap). Rather, blocks are visually truncated in the distance.

It might be nice to have a gitter room to help facilitate discussion beyond issues / pull requests. Thoughts?

There are a couple of different ways you can generate maps. The default, used for most stuff, if perlin noise.

There's also the possibility of chaining structures together to generate a city/village/dungeon/whatever.

Finally, there's custom coded generators.

We want to eventually be able to use all of them, but for now perlin noise is more then enough.

Pending PR #28 (and #17) - we'll have some (meager) unit tests and instructions for running them. With that, it'd be nice to have some Travis CI and Coveralls integration, along with a helpful badge in the readme for each.

We would like to do the client-server thing. Redis is likely to make that easier, but for the time being is going to make deployment on platforms other than linux harder.

Personally? I'd probably just accept that. But I'd like to get some feedback from the community first.

If you fly into a hidden area before the blocks get shown and try removing a block, keyerror.

Exact implementation details definitely need to be discussed. But I recommend a dead-simple implementation using python 3.5's async features, which #1 allows.

Should the currently selected block be displayed on the screen (perhaps the bottom left corner)?

https://youtu.be/50fAV9bYdJQ

The current queue for showing and hiding blocks is simply adding a show and hide functions to the queue when you enter a new sector, as a result, if you walk back and forth across the edge of a sector you can rapidly grow the queue, to the point where it lags enough that you can walk over to where it is showing and hiding sectors.

I'm working on a fix that involves either keeping track of the edge sectors, or using a set. Maybe both. I'm thinking there's a way to avoid the weirdness exhibited above.

I wish to open a discussion about modifying structurally the actual project to support game states such as: GamePlay, GameMenu etc.
Game states should deal with drawing, handle button presses, mouse clicks etc.

I was working on ways to speed up earlier versions of this project by way of Cython. When things stabilize a bit, I'll see about contributing some code in that vein, but if you don't want Cython to be a requirement, I can make it into a separately maintained fork.

This should make it a lot easier to implement networking features using python3.5's async stuff.

It should be pretty simple to create new blocks. Just define a new block, inheriting from "objects.base.block".

Off the top of my head, a few methods objects.base.block should implement.

delete() #Called when an object gets deleted
texture() #Called when the engine tries to draw a block. You can implement animated textures with it.
interact() #Called when a user tries to interact with an object
location() #returns the current blocks location.
uuid() #The unique ID of a block, if it should have one. This is for objects like chests.

Some of those should probably be attributes, then wen can make the properties.

Longer term, instantiating hundred of thousands of blocks is probably a bad plan.

I'd like to get into what goals people have for this project a bit more.

I'd like to see this project ultimately end up being the "django" for voxel/roguelike/tile games.

I'd like it if there was only one real client, and most of the customization happened "server"-side. In the backend, whether that's network transparent or not. I think asking people to do graphics programming to make a game is asking too much. They should be able to ignore most of that, and focus on gameplay.

I'd like to look into gurps for ideas on how our default world fundamentally works. How to handle hitpoints, stamina, etc. It has a proven record of letting multiple settings work well together.

I want people to be able to implement things like dwarf fortress. Incredibly realized worlds with amazing depth.

I'd like it if eventually we got to the point were you could do something like

INSTALLED_APPS = [
    'base',
    'base_worldgen',
    'cyberpunk',
    'spellwords',
    'fantasy_races',
    'industrial_cities',
]

To get something like the shadowrun campaign settings. Or any other combination. Find the medieval base, add in steampunk. Whatever.

If I had to shorten my vision, I'd say that we need to enable fully-realized worlds, and make it easy for people to mix and match them.

But I'd like to hear what other people want to get out of the project as well. That's only one approach.

The cube_vertices function in pycraft/util.py is manually doing addition to every element in a list. I'm about 60% sure that this needs to be happening in numpy or pyglet to be a reasonable speed.

If this get's fixed, the blocks could be moved over .5 and normalize swapped to using floor as described in #45 . This may cascade into other logic though, idk.

Hi All,

I am offering my assistance here towards this project as for a class assignment I have been tasked to contribute to an open-sourced project like this one. I have spoken with @traverseda about this and he said it would be a good idea to open an issue.

I have a short period of time to complete this (less than 4 weeks) and unfortunately I have no experience with Python coding and don't think I will have the time to learn it fluently enough to contribute in that area. I'm looking for any suggestions of basic and non-time-demanding tasks that would help this project and fulfil my requirement to contribute.

Any suggestions will be appreciated here.

Regards,
James

I'm working on writing some unit tests for some of the existing code and saw that the normalize() function in the util module is using round(). The documentation for the function says it returns the block containing the input position, so should this be using math.floor() instead?