News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

pak doesn't appear in the list

Started by Iluvalar, October 24, 2012, 03:36:51 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Iluvalar

Hi everybody,


First I must say that the doc. for the pak making process seems scattered all around. Maybe the solution to my problem is already explained somewhere, but I can't find it.


I downloaded the pak64 source data folder and I'm trying to run makeobj on it. I'm on ubuntu 12.04.


The folder that is generated seems good, as far as I can tell, but the new pak is not listed at all in the game startup menu. Is there something simple I'm missing ?

An_dz

All pakset files (.pak files) must be inside one single folder inside Simutrans folder. Inside the pakset folder there must have a ground.Outside.pak file so it can show up in the startup, some .tab files inside a config folder are required too, probably only cityrules.tab is extremely necessary but it's better having them all.
Of course there are a lot of other required files for it to at least load.

I don't know why you want to compile pak64. It's better to get it compiled from sourceforge, and if you want with the latest changes you can download from nightly site.

kierongreen

Is the compiled pak directory in the simutrans game directory? If you are using the default debian version of simutrans then paks need to be in /usr/share/games/simutrans/<pakname>

Iluvalar

There is no "ground.Outside.pak" in my pak. Only a ".Outside.pak". When I rename it, the pak show in the start menu but crash right after I click it.


i dont want to compile a genuine pak64 lol, I plan to edit it a make changes (I'll open a topic about my objectives). Can someone help me ?

Combuijs

I don't know if this helps you, but this was my batch file for windows to compile pak64. I don't use it anymore, because I've made my own pak64 with its own directory structure, but it used to work until a year ago. I know you are on a different operating system, but you will get the meaning, I think. It was called makeobj64.bat, but I can't attach *.bat files...

It expects the following directory structure:

install (with this batch file and makeobj.exe in it)
install\pak64.combuijs (empty directory)
pak64 (with the whole source of pak64)

After running the batch file, you move the pak64.combuijs directory to your simutrans directory (the one with simutrans.exe in it). It worked for me, I hope you can make it work for you!


Bob Marley: No woman, no cry

Programmer: No user, no bugs



prissi

There is a standard unix makefile. Go tho the pak source folder and type make. Then copy the folder pak to the right location.

Iluvalar

Thanks prissi.

I tried to use make on the directory.  I still have the same problem... there is an ".Outside.pak" but no "ground.Outside.pak". When I rename it, the pak appear in the options but it crash with this message :


Reading object data from pak/...
Segmentation fault


Is this the good spot to download the pak btw ? :
http://simutrans.svn.sourceforge.net/viewvc/simutrans/pak64/

Dwachs

Yes, these are the official sources. You can download compiled pakset from sourceforge download section.
Parsley, sage, rosemary, and maggikraut.

Iluvalar

Ok , here is a big update :

When I copy the newly generated pack folder in the simutrans folder and ask to overwrite the previous working folder, it then work fine and my change are taken into account in the game. The only conclusion I can make is that the make do not create all the necessary files.

I suggest you guys try at home with a fresh brand new folder to see if you can reproduce my problem.

prissi

The file uploaded as the official pak is generated by this makefile. Same for the nightly. These are strong indications that the error is on your side.

VS


My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Iluvalar

by hand. Maybe I should use SVN  :D . But could that change the behavior ?

VS

Wait, I think I got it. There is no DAT file for "outside"... because it is generated by makefile!


vladimir@vladimir-ThinkPad-Edge-E330:~/SVN/pak64$ grep -i -r --include=*.dat -n outside *
Makefile:12:OUTSIDE :=
Makefile:13:OUTSIDE += ground
Makefile:44:DIRS := $(OUTSIDE) $(DIRS64) $(DIRS128)
Makefile:87:$(OUTSIDE):
Makefile:88: @echo "===> OUTSIDE with REVISION and grounds"
Makefile:90: @echo -e -n "Obj=ground\nName=Outside\ncopyright=pak64 112.0 r" >$@/outside.dat
Makefile:91: @svnversion >>$@/outside.dat
Makefile:92: @echo -e "Image[0][0]=outside.0.0\n-" >>$@/outside.dat
Makefile:94: @rm $@/outside.dat
vladimir@vladimir-ThinkPad-Edge-E330:~/SVN/pak64$


You will want to experiment with this infernal machine yourself ;)

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

kierongreen

Hi sorry to bump this but I ran into this problem myself when checking out latest svn. Fix was:

Index: Makefile
===================================================================
--- Makefile (revision 1467)
+++ Makefile (working copy)
@@ -89,9 +89,9 @@
@echo "===> Grounds calculations"
@echo "===> OUTSIDE with REVISION and grounds"
@mkdir -p $(PAKDIR)
- @echo -e -n "Obj=ground\nName=Outside\ncopyright=pak64 120.0 r" >$@/outside.dat
+ @/bin/echo -e -n "Obj=ground\nName=Outside\ncopyright=pak64 120.0 r" >$@/outside.dat
@svnversion >>$@/outside.dat
- @echo -e "Image[0][0]=outside.0.1\n-" >>$@/outside.dat
+ @/bin/echo -e "Image[0][0]=outside.0.1\n-" >>$@/outside.dat
@$(MAKEOBJ) PAK64 $(PAKDIR)/ $@/ > /dev/null
@rm $@/outside.dat

Ters

Is echo guaranteed to be in /bin? It seems a very odd problem to have to specify it, and why only for those lines when echo is used many other places? Has echo become an internal command in some version of make?

kierongreen

The problem may be specific to Ubuntu/Debian, however the issue is not with echo in general but when used with parameters -e or -n. Instead of interpreting these they are instead echo'd to the file. Hence outside.dat contains something like:
-e -n "Obj=ground
Name=Outside
copyright=pak64 120.0 r"
1467
-e "Image[0][0]=outside.0.1
-"

instead of

Obj=ground
Name=Outside
copyright=pak64 120.0 r1467
Image[0][0]=outside.0.1
-

Ters

What does which echo print on such a system? Seems like there must be a non-standard echo on the path. Maybe the echo command should be configurable like MAKEOBJ is, and CC & co is in the makefiles for Simutrans itself. On the other hand, I'd expect that such a non-standard echo implementation would cause problems for several other scripts as well, not just Simutrans' build scripts.

kierongreen

This seems to be a fairly common problem for make scripts running on certain systems and /bin/echo seems to be the solution other people have used also (google for echo make linux and the top result gives this solution for example).

Ters

Quote from: kierongreen on July 20, 2014, 03:59:22 PM
(google for echo make linux and the top result gives this solution for example).

According to that discussion (http://stackoverflow.com/questions/11675070/makefile-echo-n-not-working), it seems you don't have a Linux box, but a Mac. Or a Linux box that wants to be a Mac.

Seriously: From what I can gather from that somewhat confused discussion, make sends commands it don't understand to the users shell. I guess the problem is that you have a shell that is (unusually?) strict in it's built-in implementation of echo, while the scripts use what I guess is GNU echo extensions. I wonder if we can reliably expect that /bin/echo will support -n and -e. http://pubs.opengroup.org/onlinepubs/009695399/utilities/echo.html says that XSI-compliant echo implementations should not support any options at all, but always interpret backslash character sequences, which is almost the exact opposite of what GNU echo does. The man page for echo from GNU coreutils writes that one should rather use printf for portability.


Vladki

#19
Hi I have a similar problem with pak128 - downloaded with svn tool, on debian Linux.

There is a base.pak file instead of ground.outside.pak. There seems to be a commented section in the makefile for special treatment, but it points to old location of the relevant dat file.

Update - attahced is a fixed makefile for pak128. Also fixed generation of crossings.

Ters

Quote from: Vladki on July 21, 2014, 09:45:31 PM
Hi I have a similar problem with pak128 - downloaded with svn tool, on debian Linux.

There is a base.pak file instead of ground.outside.pak. There seems to be a commented section in the makefile for special treatment, but it points to old location of the relevant dat file.

Update - attahced is a fixed makefile for pak128. Also fixed generation of crossings.

I think this is a pak128 specific issue, and should be brought up there. It's makefile looks broken. Maybe it's not even built with make. Maybe this echo thing is pak64 specific, but it is a trick other pak sets might run into. Even core Simutrans itself may bump into it.

prissi

Anyway, changed pak64 and pak64.japan to printf