Duke4.net Forums: User Map Maphacks - New EDuke32 / HRP Feature - Duke4.net Forums

Jump to content

  • 3 Pages +
  • 1
  • 2
  • 3
  • You cannot start a new topic
  • You cannot reply to this topic

User Map Maphacks - New EDuke32 / HRP Feature

User is offline   LeoD 

  • Duke4.net topic/3513

#1 Posted 23 November 2012 - 02:07 PM

Currently, maphacks are only loaded when they have the same file name as the map, and are located in the exact same path.
( -j / -game_dir locations won't work.)

My request is to add maphack handling to the HRP's DEF file system. Entries in maphacks.def could look like this:

maphack MAP_FILE.map { MAP_CHECKSUM_1 [MHK_PATH/]MAPHACK1.mhk } // original release
maphack MAP_FILE.map { MAP_CHECKSUM_2 [MHK_PATH/]MAPHACK2.mhk } // updated revision


Now if no matching maphack file exists in the exact location of the currently loaded [user] map, EDuke32 can check if a maphack with a matching checksum is defined in maphacks.def and use that one.

Purposes/Advantages:
-The HRP serves as central maphack container for user map maphacks, too
-Maphacks for Atomic, 1.3D, and shareware version can be provided in parallel
-Can deal with different circulating user map versions as well
-No more interference with episodes and mods and their own "E?L?.map" files
-HRP root directory cleanup

As an incentive I have made an initial bunch of user map maphacks ready to add, including the Roch series, and the latest map releases of 2012.
EDIT 1: For the time being this can simply be dropped into the autoload folder, until the user maphack system actually works. (But read the text below.)
Spoiler
Changelog:
Spoiler

EDIT 2: As of EDuke32 r4884 the UserMaphack system is implemented and working as requested (without bells and whistles). :P
EDIT 3: The HRP release 5.4 contains all UserMapHacks up to r5.3.672. You may only want a newer UserMapHacks pack to HRPlay maps which get added later on.

The download link has been moved to the "Cutting Edge" section of "my" thread.

This post has been edited by LeoD: 03 October 2016 - 12:39 PM

3

User is online   Hendricks266 

  • Weaponized Autism

  #2 Posted 23 November 2012 - 05:57 PM

Excellent idea! Internally, it will require some work:

  • parsing the def syntax
  • storing all the checksums and maphack file names in memory
  • checksumming every map that is loaded

My input is that defining a map file name is unnecessary. With a sufficient checksum algorithm, the benefit of disregarding a map's name far outweighs the infinitesimal chance of a checksum collision. On the other hand, if we want to use a weak checksum like CRC32, a filename could be a fallback tiebreaker.

This is worth persuing.
0

User is offline   Player Lin 

#3 Posted 24 November 2012 - 07:01 AM

View PostHendricks266, on 23 November 2012 - 05:57 PM, said:

On the other hand, if we want to use a weak checksum like CRC32, a filename could be a fallback tiebreaker.


How about MD5? Like ZDooM's Wad Compatibility Definition used that. It doesn't needed to check filename but as comments for maintaining propose.

This post has been edited by Player Lin: 24 November 2012 - 07:06 AM

0

User is offline   Helixhorned 

  • EDuke32 Developer

#4 Posted 24 November 2012 - 07:18 AM

MD4 seems like a good choice if we don't want to introduce additional dependencies. The RHash utility can compute them from the command line.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#5 Posted 24 November 2012 - 02:32 PM

View PostHendricks266, on 23 November 2012 - 05:57 PM, said:

My input is that defining a map file name is unnecessary.
While not absolutely mandatory this could help to inform/warn the user/maphack developer about maps with a known name but a different binary version. My second maphacks.def attempt looks like this:
// User Maps
maphack {
   mapfile  "CBP8.map"
   mapmd5   6c19caca74ac37f7e27fd3befd8b0920
   maptitle "Metropolitan Starlight"
   mhkfile  "maphacks/usermaps/CBP8.mhk"
}

Now if an updated CBP8 version should be released, EDuke32 could state that a non-matching maphack exists and "someone" could then look into this.
Using maptitle would make most old USER.CONs obsolete in conjunction with the HRP, because they don't do more than come up with a custom definelevelname entry.

This post has been edited by LeoD: 24 November 2012 - 02:32 PM

0

User is offline   Player Lin 

#6 Posted 25 November 2012 - 06:45 AM

View PostLeoD, on 24 November 2012 - 02:32 PM, said:

// User Maps
maphack {
   mapfile  "CBP8.map"
   mapmd5   6c19caca74ac37f7e27fd3befd8b0920
   maptitle "Metropolitan Starlight"
   mhkfile  "maphacks/usermaps/CBP8.mhk"
}



I wonder if someone changed the map name to other and it never works on that map because it still check the filename, unless it doesn't check file name at all. I may like this but it may poor for some reasons.

  // User Maps maphacks
   value "6c19caca74ac37f7e27fd3befd8b0920"
   {
   // "CBP8.map"
   maptitle "Metropolitan Starlight"
   mhkfile  "maphacks/usermaps/CBP8.mhk"
   }

   value <whatever MD5 value>
   {
   // "MAPFILE.map"
   maptitle "It's a MAP"
   mhkfile "maphacks/usermaps/MAPFILE.mhk"
   }
   
   ...


Also if the map updated, it still needed double check because the maphack may not totally works as intended on new version of map, so the file name still not really needed to check again.

I suggested MD5 is because it doesn't needed to check file name at all, and I don't think you need, the % of the same MD5 value of map is really so low, so just leave comments about the filename for maintaining.

This post has been edited by Player Lin: 25 November 2012 - 06:51 AM

0

User is offline   LeoD 

  • Duke4.net topic/3513

#7 Posted 25 November 2012 - 09:41 AM

View PostPlayer Lin, on 25 November 2012 - 06:45 AM, said:

I wonder if someone changed the map name to other and it never works on that map because it still check the filename, unless it doesn't check file name at all.
Based on my proposal this is how it's meant to work: (Note that the order of the entries in a maphack block is not relevant.)

1. All the maphack { * } blocks are parsed on startup:
- store the HRP MD4 list and related map file names and titles
- check if the defined mhkfiles actually exist
- multiple mapfile entries are allowed in one maphack block (e.g. demount.map/FM2X04.map)
[EDIT] - multiple mapmd4 entries are allowed in one maphack block

2. When loading a map:
- make MD4 sum and output it to the log file
- if a maphack file with the exact same base name and location exists: use it, but inform about a matching HRP MD4 entry if available
- else if a matching HRP MD4 entry exists: use the related HRP mhkfile (and the maptitle if available)
- else if a matching HRP map name exists*, but the HRP MD4 doesn't match: issue a warning
*:(ignoring E?L?.map file names)

The mapfile and maptitle entries are not essential but nice to have.

EDIT:

View PostPlayer Lin, on 25 November 2012 - 06:45 AM, said:

Also if the map updated, it still needed double check because the maphack may not totally works as intended on new version of map
Most likely it won't work at all because from what I've seen so far even small changes are likely to shift many or all sprite numbers.

EDIT2: MD5 changed to MD4

This post has been edited by LeoD: 18 October 2014 - 05:43 PM

0

User is offline   LeoD 

  • Duke4.net topic/3513

#8 Posted 16 December 2012 - 04:24 PM

More maphacks available, including Dogville (Extended 2012 Version) and Metropolitan Mayhem. See post #1.

If the maphack block syntax as described above is acceptable for the EDuke32 developers, I hereby ask to implement just ignoring it as a start. Because I'd like to have this stuff in the HRP repo before the next release, otherwise people might have to wait a loong time until the next HRP update. The maphacks subfolder in the pack shows how it's supposed to look like.

This post has been edited by LeoD: 16 December 2012 - 04:35 PM

0

User is online   Hendricks266 

  • Weaponized Autism

  #9 Posted 16 December 2012 - 06:47 PM

At present you just want the def parser to accept the syntax but do nothing so you can include the stuff in the next build? Great idea! I'm entering finals week so you can't expect much out of me during this time, but I'll make it happen. I'll probably make dummy ifdef polymost/polymer while I'm at it.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#10 Posted 17 December 2012 - 09:39 AM

View PostHendricks266, on 16 December 2012 - 06:47 PM, said:

At present you just want the def parser to accept the syntax but do nothing so you can include the stuff in the next build?
Exactly.

View PostHendricks266, on 16 December 2012 - 06:47 PM, said:

I'm entering finals week so you can't expect much out of me during this time, ...
Good luck!
1

User is online   Hendricks266 

  • Weaponized Autism

  #11 Posted 22 December 2012 - 05:50 PM

It looks like gears are aligning for a new HRP release. I ask that you hold off for a short time so I can implement these dummy tokens.

Dummy ifdef polymost/polymer won't happen now because they would need the blocks to be parsed anyway so it's not worth it.

As Helix suggested, it will use the MD4 (not MD5) hash algorithm.

I'll post more details when it's in.
0

User is online   Hendricks266 

  • Weaponized Autism

  #12 Posted 22 December 2012 - 07:13 PM

r3309 said:

Add "mapinfo" token to the def parser, pending implementation.

Sub-tokens: "mapfile", "maptitle", "mapmd4", "mhkfile"

1

User is offline   LeoD 

  • Duke4.net topic/3513

#13 Posted 23 December 2012 - 03:19 AM

View PostHendricks266, on 22 December 2012 - 05:50 PM, said:

It looks like gears are aligning for a new HRP release. I ask that you hold off for a short time so I can implement these dummy tokens.
Too late, unfortunately, r413 will be it. I should have contacted NightFright earlier. :)

View PostHendricks266, on 22 December 2012 - 05:50 PM, said:

As Helix suggested, it will use the MD4 (not MD5) hash algorithm.
Noobish me thought it was a typo ... :)

Quote

r3309 said:
Add "mapinfo" token to the def parser, pending implementation.

Sub-tokens: "mapfile", "maptitle", "mapmd4", "mhkfile"
Thanks! After MD5->MD4 conversion I'll upload the UserMaphacks stuff to the repo. All 2012 releases and updates are done (except IIT revisited, opblitz, and LORCH).
0

User is offline   NightFright 

  • The Truth is in here

#14 Posted 23 December 2012 - 04:36 PM

It's not a big deal, anyway. If it didn't make it into the pack this time, it will just be the next. ^^
0

User is offline   LeoD 

  • Duke4.net topic/3513

#15 Posted 24 December 2012 - 03:30 PM

2012 user map maphacks are complete (except IIT revisited), including LORCH: Abducted, Riverside Town, and Operation Blitzkrieg. See post #1.

Next on my list : IIT revisited, Billy Boy's maps, 2011. But RealLife will most likely slow me down soon.

This post has been edited by LeoD: 24 December 2012 - 04:44 PM

0

User is offline   LeoD 

  • Duke4.net topic/3513

#16 Posted 20 January 2013 - 08:47 AM

5.2.413-430 : Dharga, 1_bitch, Indiana Duke, and more -> post#1
I probably won't make a new post each time I update the UserMapHacks download.
If you're interested check post#1 every now and then.
Besides my own ever-changing agenda I'll try to follow the "Latest Map" entries on scent-88.com.
Hendricks266: Would you mind adding mapauthor to the accepted/ignored DEF entries? Might become useful in the long run.
0

User is online   Hendricks266 

  • Weaponized Autism

  #17 Posted 20 January 2013 - 09:41 AM

I'm not sure about mapauthor. Once we get around to map-text we can store all the metadata we want right in the map file. There is a reasonably good case for maptitle--it's shown on map load and in the automap. Compared to mapauthor, the potential commands partime, devtime, and musicfile are equally good candidates for addition to the def spec.

It's just a decision that requires thought, whether we should extend this structure, designed to house maphacks for the HRP, to be more of a map database, when ideally that information should come with the map instead.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#18 Posted 20 January 2013 - 11:57 AM

View PostHendricks266, on 20 January 2013 - 09:41 AM, said:

I'm not sure about mapauthor.
No prob, I'll keep the authors as comments, then.

View PostHendricks266, on 20 January 2013 - 09:41 AM, said:

Once we get around to map-text we can store all the metadata we want right in the map file.
Someone will have to do a BIG map conversion job :P ... and many custom map licenses might prohibit that.
0

User is online   Hendricks266 

  • Weaponized Autism

  #19 Posted 20 January 2013 - 03:16 PM

We won't be converting old maps. We would still support loading the old map format just the same (we have to play the original game after all) and Mapster32 would have compatibility old export functionality.
1

User is offline   Micky C 

  • Honored Donor

#20 Posted 20 January 2013 - 03:24 PM

View PostHendricks266, on 20 January 2013 - 09:41 AM, said:

I'm not sure about mapauthor. Once we get around to map-text we can store all the metadata we want right in the map file.


So we've finally decided to go with map-text instead of map-int? I hope it's still capable of achieving all the points that are listed under map-int, especially the TROR related things like 1:n redwalls.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#21 Posted 20 January 2013 - 03:35 PM

View PostMicky C, on 20 January 2013 - 03:24 PM, said:

So we've finally decided to go with map-text instead of map-int?
Why would they rule out each other?
0

User is online   Hendricks266 

  • Weaponized Autism

  #22 Posted 20 January 2013 - 06:45 PM

The two proposals are mutually inclusive. One refers to the on-disk file type, and the other refers to the internal representation.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#23 Posted 08 February 2013 - 04:13 PM

5.2.413-437 - Some comments seem appropriate this time:

Duke 12:12 - Polymost renderer/HRP recommended. Polymer will kill your frame rate outside for absolutely no benefit.

Anarchy City, Bank(superseding Banco), Overtime, and Twin Creeks 'borrow' tiles014.art from Duke in D.C., so put your dukedc_hrp.zip into autoload when playing.

Bank makes really nice use of Polymer lighting.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#24 Posted 03 March 2013 - 06:03 PM

5.2.413-477 - Yesterday's release: Hellish Doom,
Last Pissed Time (LPT), Last Train to Marsville (MARSBASE), EDF Computer Base, and others
0

User is offline   LeoD 

  • Duke4.net topic/3513

#25 Posted 11 May 2013 - 01:52 PM

5.2.413-497 - Many reviews (incl. Roch series) and new maphacks:
New Quantum Physics, KaiseR Land 1-3, BobSPX, WGCity, NBCBP, Oranges, and more.

View PostHendricks266, on 23 November 2012 - 05:57 PM, said:

Excellent idea! Internally, it will require some work
[...]
This is worth persuing.
Bump. ;)
1

User is offline   LeoD 

  • Duke4.net topic/3513

#26 Posted 08 June 2013 - 10:24 AM

5.2.413-506
Locked Up, MatH Pak Episode, Moonbase Accident TC, Prequel to Time Episode, WGRealms (use WG HRP), and more.
1

User is offline   mohsin 

#27 Posted 13 June 2013 - 08:24 PM

{{{{{{{{{{{{{{{{ This post is so nice and great and a very lovely }}}}}}}}}}}}}
0

User is offline   LeoD 

  • Duke4.net topic/3513

#28 Posted 24 July 2013 - 05:34 AM

5.2.413-536
A.dream, LORCH2, Nitefall, Ruin, Valves, and more. -> Post #1

This post has been edited by LeoD: 24 July 2013 - 06:03 AM

1

User is offline   LeoD 

  • Duke4.net topic/3513

#29 Posted 24 August 2013 - 01:45 PM

5.2.413-539
Mill Town Rampage, Slaughterfest, Duke Nukem Memorial Hospital aka brains2, The Base, Nuke Plant, DM-PACK: Antic Places
-> Post #1

I would have never expected to be unable to catch up with new releases, but this month they've got me. :P

This post has been edited by LeoD: 24 August 2013 - 01:54 PM

1

User is offline   TerminX 

  • el fundador

  #30 Posted 24 August 2013 - 01:49 PM

That's what this community needs, tons of new releases. :P
1

Share this topic:


  • 3 Pages +
  • 1
  • 2
  • 3
  • You cannot start a new topic
  • You cannot reply to this topic

All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password

Sign in options