Project

General

Profile

Actions
Copy link

Feature #2187

open

Main: load_ruleset_units(): allow spec_type to be NULL if no specialist entry

Added by Dean Brown about 2 months ago. Updated 8 days ago.

Status:
In Review
Priority:
Normal
Assignee:
Marko Lindqvist
Category:
General
Target version:
3.4.0
Start date:
08/30/2026
Due date:
% Done:

0%

Estimated time:

Description

Spun off from #1618.

Files

2187.patch (7.08 KB) 2187.patch Dean Brown, 10/06/2026 11:26 PM

Related issues 1 (1 open — 0 closed)

Blocks Feature #2334: city_add_unit(), handle spec_type either nullptr or notNew10/05/2026

Actions
Actions
Copy link
 #1

Updated by Dean Brown about 1 month ago

  • File 2187.patch added

Also added a bunch of checks/asserts to avoid a dereference of a nullptr. Hope I got them all.

When this done I will update/improve the 1618_Main.patch in #1618.

Actions
Copy link
 #2

Updated by Marko Lindqvist 20 days ago

  • Tracker changed from Task to Feature
  • Category changed from Rulesets to General
  • Target version set to 3.4.0
Actions
Copy link
 #3

Updated by Marko Lindqvist 20 days ago

In many of those changed places the nullptr check should actually replace old DEFAULT_SPECIALIST check, not add to it, i.e., we want Entertainers (DEFAULT_SPECIALIST) to work correctly too.

Is the requirements.c change even related? Seems wrong in any case, as it does turn invalid (nullptr) specialist in to a valid one (first one / number zero) with no clear justification of why just that one gets selected.

Actions
Copy link
 #4

Updated by Marko Lindqvist 13 days ago

  • Status changed from New to In Progress
  • Assignee set to Dean Brown
Actions
Copy link
 #5

Updated by Dean Brown 13 days ago

  • File deleted (2187.patch)
Actions
Copy link
 #6

Updated by Dean Brown 13 days ago

  • File 2187.patch added

Yes, requirements.c should not change. I got distracted by the " return 0;" at the end of universal_number() when "there's been an error.". 1 is actually a correct value to return from universal_number(), and is the returned value from specialist_number(source>value.specialist) when source->value.specialist is nullptr.

Might be nice to add a comment to universal_number() saying -1 is possible return value.

Actions
Copy link
 #7

Updated by Dean Brown 13 days ago

My comment got mangled by -1 being interpreted as strike-thru.

Actions
Copy link
 #8

Updated by Marko Lindqvist 12 days ago

Dean Brown wrote in #note-1:

When this done I will update/improve the 1618_Main.patch in #1618.

#1618 has been resolved already. Open a new ticket for the new change.

Actions
Copy link
 #9

Updated by Marko Lindqvist 12 days ago

  • Status changed from In Progress to In Review
  • Assignee changed from Dean Brown to Marko Lindqvist
Actions
Copy link
 #10

Updated by Marko Lindqvist 10 days ago

  • Blocks Feature #2334: city_add_unit(), handle spec_type either nullptr or not added
Actions
Copy link
 #11

Updated by Marko Lindqvist 8 days ago

When client connects, server says:
1: Trying to put -1 into 8 bits; it will result 255 at receiving side.

Debugging revealed that this comes from packets_gen.c line

    e |= DIO_PUT(uint8, &d_out, &field_addr, real_packet->spectype_id);

Actions
Copy link
 #12

Updated by Marko Lindqvist 8 days ago

  • Status changed from In Review to In Progress
  • Assignee changed from Marko Lindqvist to Dean Brown
Actions
Copy link
 #13

Updated by Marko Lindqvist 8 days ago

Likely it's possible to simply change the data type to be sint8 in the network protocol.

Actions
Copy link
 #14

Updated by Dean Brown 8 days ago

  • File deleted (2187.patch)
Actions
Copy link
 #15

Updated by Dean Brown 8 days ago

Added change in packets.def

Actions
Copy link
 #16

Updated by Dean Brown 8 days ago

Actions
Copy link
 #17

Updated by Marko Lindqvist 8 days ago

  • Status changed from In Progress to In Review
  • Assignee changed from Dean Brown to Marko Lindqvist
Actions
Copy link

Also available in: Atom PDF