DarkknightXC

Yeah and the reason for that is the amount of time being spent on trying to get a spec 100% right first time. This is a common problem with open source/community based projects and in fact any project that has no deadline. Deadlines are often a pain up the arse, but OTOH they have the benefit of getting people to make a decision. I think that we can agree on the essential data required to fulfil the requirements of a 32-Bit map format and someone with the avaiable time - the other element in short supply for this type of project - should get knuckle down and just get on with coding up in their respective engine. I don't care what format the data is, so long as the content is there. It can revised later. Nobody here will ever be a 100% happy with the final result. So lets avoid that trap and get on with the business of producing something. I'd rather effort was wasted doing too much then doing nothing but talk for all eternity. Lets get moving and get this back on track.

Got to start somewhere. Work out what we can for ourselves. Forward on to editor developers for feedback. Port authors can construct our own data for testing so we can prove our idea and give the editor developers something to work with when further developing the spec.

Apologies if I've misdirected any praise/abuse (delete as appropriate). I support this effort as a whole and still want a room with a view :).

I see what you are saying, but Graf is doing the right thing by developing a specification in the public domain. Ultimately it is his decision what goes into the specification and it remains to the port authors as to whether they choose to implement it. In the same way that ajapted established a standard for nodes built for GL renderers, Graf is doing the same for an extended map format. We should support him in that process and I do not think there is a better way of doing this apart from sticking every port/editor author on a plane to his location, hiring out one hotel and a conference centre for us all. (Should Graf want to do the conference I'll have a room with a view please :).

Anyone else image of some grey bearded bloke thumping the ground with a staff and the earth shaking. OK, just me then.... (Ok yeah, Mapname restriction works for me).

I Agree. Just not sure on what :).

True. My issue is that the spec should not be vague on such matters. Either exclude the possibility of 8 character names or handle it without possiblity of error (IMHO).

I'm now confused. Why does a mapper care about the naming of their map within a WAD? So long as the application - be it editor or engine - knows where to source the data then the mapper should not have reason to care. I'm not fussed in how you its done - be it by mapname restriction or by remapping lump etc.. - but I would suggest that allowing for a known problem to exist in a spec, makes the spec bad. Having thought about it, only new maps will support this use this format so a limitation on the length of mapname is a simple answer.

It is possible to use 8 characters at the present time and it seems something of a backward step to not support that in the new spec. Rehashing a non-standard mapname is open to error. I think the spec should not define something that is quite so open to error as this. Therefore I am providing a way of working around that. Should we choose to restrict name length I think it preferable to restrict the format of the name also. Say MAPXX in all cases. Fudges - especially those in specs - rarely result in a good working solution. I suppose one could argue that the limitation of the wad format is at fault here and we could write a new one..... ;)

The extradata <-> map data association works if the mapname is a standard MAPXX format. The aliasing of non-standard names to the standard format means that the method of assocation is easy and unbroken. Its up to application to refer to the aliasing lump to get the proper standard mapname from the non-standard mapname. I think its best to solve the non-standard mapname problem as part of the spec as a whole.

I think we've trying to solve the wrong problem here. Rehashing an extended name has the problem of handling where two or more names clash. Perhaps we should have an alias mapname lump, so that all these custom names are remapping to a standard format. We shouldn't care so long as the name is unique in relation to other mapnames.

The major reason I suggested a hex number for the colour format is simple. You can parse it with the standard format specifier.

Work for me, although I would prefer for colour number format to be start with a '0x' to represent the hex format used. Gets around the '#' comment problem.

Ultimately, that is an implementation issue. ACS is one of many which would use such data. I think its makes sense for references to be strings for the reasons stated. Don't beat around the bush, do you? I'm making a suggestion, not writing gospel. No need to be quite some combative in your language. I think that record sizes should be fixed, so data maybe read as a block. Its more efficent and easier to navigate. I applaud the acceptance of implementation specific data, but I would have it positioned after the block of standard implementation data. The suggestion made was a potential solution. How would you tackle this problem? Fair point. I certainly not against text format maps - its just another parser to write that is all.

For all those who have had problems running EDGE 1.29 RC#3: http://sourceforge.net/forum/forum.php?thread_id=1368318&forum_id=6482

Agreed. Best to fix the bug in I_MUSStop and then handle the standard exceptions. Suggest to Joe that he disables music with '-nomusic'.

My 2pence worth: I would prefer to see that script references (the TID in Things for example) should actually be a string. This would much more informative for the people who build maps. Perhaps a string lump ("MAPSTR"?) should contain all the variable length strings including script references so that thing entries themselves would be easier to read. Therefore the TID entry would actually point to an entry in the string lump. I grant you that numeric IDs are efficent for comparision purposes, but it can be boiled down to that internally by the given source port or editor. I would suggest that extended information be handled in an additional lump for each type (one for things, lines, sectors etc...). Text format maps? Nice idea, be interested how big one of these would get with some of the bigger maps we have seen.

Having looked the debug output, the MUS error occured after an exception error was thrown. The ww-cash / doom 1 combination seems to be the one worth putting through the debugger.

When you say "don't work". Are we talking about freezing up ("hang-alive") or quitting unexpectedly ("crash-to-desktop")?

Have you tried using builds B or C?

BTW, an attempt to download this file gets: This file is hosted by Tripod, a Lycos®Network Site, and is not available for download. Please check out Tripod's Help system for more information about Remote Loading and our Remote Loading policy.

Revisiting my old hacks. I feel so proud :). BTW, might want to check your turkish translations. Looks like someone was taking the piss and their changes (look for hacker in d_turk.h) made their way into DOSDoom 0.61 and have been in every version of DOSDoom since!. Guess nobody plays with the turkish translations.

How did the teleports behave differently in the final doom exe?

Debug info received. Thanks.

Oh yeah: the last thing you do to a programmer who has completed a shedload of work is to point out something that questions his work and makes you sound ungrateful. Sure-fire way to upset the natives. (I would upset me no end :).